Live Chat Support Scripts: Customer Service Chat Examples and Templates

Live chat support scripts are prepared lines for the repeating moments in a text conversation: the opening, verifying who you are talking to, holding while you check something, transferring, apologizing, declining a request, nudging a silent customer, and closing. Chat scripts are not phone scripts retyped. Chat is written, timed, and visible, so silence reads as absence and every line you send is on the record.

Last updated: August 2026.

On a phone call, thinking time sounds like thinking. In a chat window it looks like you left. That single difference drives most of what makes a chat script different from a call script, and it is why teams that simply hand agents their phone scripts and point them at a chat widget end up with slow, stiff conversations that customers abandon halfway through.

What follows is a library you can copy, adapt, and put in your macros today. The phone-first versions of these moments live in our broader set of customer service scripts for calls and chat. This page is the chat-specific build: shorter lines, explicit time promises, and the handful of scripts that exist only in chat, like the idle nudge and the transcript close.

How chat scripts differ from phone scripts

Four things change when the conversation moves into a text box, and every script below is shaped by them.

Silence is ambiguous. A customer cannot tell whether you are researching their account or have wandered off. So chat scripts narrate. Every pause gets a sentence that says what you are doing and roughly how long it will take.

You are handling more than one conversation. Agents typically run several chats at once, which means the customer's real wait is longer than your typing speed suggests. Scripts that set an explicit expectation ("give me about two minutes") absorb that gap. Scripts that say "one moment" do not.

Everything is written down. The customer can screenshot it, paste it, and quote it back to you six months later. Chat scripts should be things you would be comfortable seeing in an email thread, because that is frequently where they end up.

Length works against you. A four-sentence paragraph that would be a natural spoken answer becomes a wall in a narrow chat window. Break replies into short messages. Send the direct answer first, then the detail.

What good live chat performance looks like

Scripts only matter inside a working operation, and the numbers below are the ones published 2026 benchmark guides consistently report for live chat. Treat them as orientation, not targets handed down from anywhere official, and measure your own baseline before chasing anyone else's figure.

The pattern across those sources is consistent and worth stating plainly: response speed predicts chat satisfaction more strongly than almost anything else in the interaction. That is a scripting problem as much as a staffing one, because the fastest possible first reply is a saved line an agent sends with one keystroke. If your first response time is drifting, the diagnosis usually starts with how first response time is measured and improved rather than with the agents.

Chat opening scripts

The opening does three jobs in about ten words: confirm a human arrived, give them a name, and ask one open question. Resist the urge to stack a greeting, a company mission statement, and a menu of options.

• Standard open: "Hi [Name], I'm Jordan. Happy to help. What's going on?"
• When they already typed the problem: "Hi [Name], I'm Jordan. I've read your message about the duplicate charge, so you don't need to repeat it. Let me pull up your account."
• Known or returning customer: "Hi [Name], good to see you again. I can see your account and your last ticket from March, so we can pick up from there."
• After a bot handoff: "Hi [Name], Jordan here, a human. I have the whole conversation above so we don't have to start over. Let's get this fixed."
• Queue was long: "Hi [Name], thanks for waiting, that queue was longer than it should have been. I'm Jordan and I'm with you now. What can I sort out?"

The second and fourth are the ones most teams are missing, and they are the highest-value lines on this page. Telling a customer you have already read what they typed removes the single most common chat frustration, which is being asked to explain the problem again to each new party. The same applies after an automated handoff. If your bot collected the details and the human then asks "how can I help you today?", the customer concludes the bot was theater. Handoff scripts that reference the prior conversation are what make an AI chatbot and human agent pairing feel like one team instead of two disconnected ones.

Verification scripts

Identity checks feel like an interrogation unless you explain why. One sentence of reason converts a hurdle into reassurance.

• Standard: "Before I open the billing details, I need to confirm it's really your account. Can you tell me the email on file and the last four digits of the card?"
• When they push back: "Completely fair to ask. It's the same check that stops someone else getting into your account. Just the billing zip code and I'm done."
• When verification fails: "That doesn't match what I have, which usually means the account is under a different email, often a work address. Want to try another one? I can't share account details until it matches."

Note what the last script does not do. It does not accuse anyone of anything, and it does not bend. Give the most likely innocent explanation, then hold the line.

Hold scripts for chat

This is the moment chat teams lose the most goodwill, and it is the easiest to fix. A phone hold has music, so the customer knows the line is alive. A chat hold has nothing. If you go quiet for ninety seconds to read an account, a meaningful share of customers will assume the chat dropped and either leave or start typing "hello?"

The fix is a three-part hold script: say what you are doing, give a time, then come back on time or check in before it expires.

• Asking for the hold: "I need about two minutes to look through your billing history properly. I'll stay right here, and I'll message you the moment I have it."
• Longer investigation: "This one needs me to check with our payments team. That's usually five to ten minutes. I'd rather do it now while you're here than email you later. Are you okay to wait, or should I follow up by email?"
• Check-in when it runs long: "Still with you, still digging. It's taking longer because the charge went through a second processor. Two more minutes."
• Coming back: "Thanks for waiting. Here's what I found: the charge on the 14th was an authorization hold, not a second payment, and it expired yesterday."

The check-in line is not optional. If you promised two minutes and you are at three, an unprompted message costs you five seconds and prevents the customer concluding you have forgotten them. Giving an honest range beats a cheerful underestimate every time, because a customer who was told ten minutes and waited six is delighted, and a customer who was told two and waited six is filing a complaint.

Transfer and escalation scripts

A cold transfer in chat is worse than on the phone. On the phone the customer at least hears the handoff happening. In chat they see a new name appear and immediately have to judge whether this person knows anything.

• Warm transfer: "Priya on our billing team can issue the credit directly, which I can't. I'm passing her the whole conversation and a summary, so you won't have to repeat any of it. She'll be with you in about a minute."
• The receiving agent's opening: "Hi [Name], I'm Priya. Jordan filled me in: duplicate charge on the 14th, you'd like it credited rather than refunded to the card. I can do that now."
• Escalating to a manager: "You've asked to speak to a manager and that's a reasonable ask. I'm bringing in Sam, our support lead. I've told them what happened, including the part where we got this wrong twice."
• No one is available: "The person who can approve this isn't online right now, and I don't want to make you wait in a chat window for an hour. I'll get you a written answer by [specific time] and email a copy. Does that work?"

The receiving agent's opening is where warm transfers succeed or fail. If Priya arrives and asks the customer what the problem is, the promise Jordan made was a lie and the interaction is now worse than a cold transfer would have been. That is an operational problem more than a scripting one: the handoff has to actually carry the context. Teams that route chats and tickets to the right specialist with the history attached, whether through their help desk or a dedicated layer for getting each request to the right person automatically, spend far less time on repeat explanations. Deciding who receives what, and when a chat becomes a manager's problem, is what an escalation matrix is for.

Apology and de-escalation scripts

Written apologies carry more weight than spoken ones because the customer can reread them. That cuts both ways: a vague apology looks even emptier in text.

• Specific apology: "I'm sorry. We charged you twice and then took four days to answer your email about it. Both of those are on us."
• Acknowledging the effort: "You've now explained this three times to three people. That shouldn't have happened, and I'm not passing you to a fourth."
• When they're angry: "You're right to be annoyed and I'm not going to argue with any of it. Give me two minutes to read the whole history and I'll come back with what I can actually do, not a policy quote."
• When you were wrong about the fix: "I told you yesterday this was resolved and it clearly isn't. I got that wrong. Here's what I'm doing differently this time."

Skip "I apologize for any inconvenience this may have caused." It names nothing, commits to nothing, and every customer has read it a hundred times. Name the actual failure. When a chat has moved past apology into genuine hostility, scripts stop being enough on their own and you need the longer approach in our guide to de-escalating difficult customers.

Saying no in chat

Declining in writing is harder than declining out loud, because tone does not carry and the customer can reread a blunt sentence until it sounds worse. The structure that survives rereading: acknowledge, decline plainly with one honest reason, then move immediately to what you can do.

• Outside the refund window: "I understand why you'd want the full refund. I can't refund past the ninety-day window, and I don't want to pretend I'm checking when I already know the answer. What I can do is issue a credit for the unused months, which is [amount]. Would that work?"
• Feature you don't have: "We don't do that today. I've logged it with the product team with your account attached so you'll hear if it ships. In the meantime most customers handle it by [workaround]."
• Discount you can't give: "I don't have authority to discount below the annual rate, and I'd rather say that than stall. If budget is the blocker, the annual plan drops the effective monthly cost by [x] percent. Want me to price that out?"

The phrase doing the work in all three is the honest reason. "I can't" invites an argument. "I can't, and here is precisely why, and here is the alternative" ends the negotiation and keeps the customer.

Idle chat scripts

This is the script that exists only in chat, and most teams have nothing for it. The customer stops replying. They took a call, opened another tab, or wandered off. Closing the chat instantly feels dismissive; leaving it open forever burns a concurrency slot.

• First nudge, around two minutes: "Still there, [Name]? No rush, I'm here."
• Second nudge, around five minutes: "I'll keep this chat open a few more minutes in case you're still around. If it's easier, I can email you what we've covered and you can reply whenever."
• Closing an abandoned chat: "I'm going to close this one so it doesn't sit open, but nothing is lost. I've emailed you the transcript and the next step, and if you reply to that email it comes straight to me."

The last script is the one that protects your reputation. A chat that closes with a transcript and a named route back is a paused conversation. A chat that closes with "Thank you for contacting us, goodbye" after a customer stepped away for four minutes is an abandonment they will remember.

Chat closing scripts

Close by confirming the problem is solved, not that you replied. In chat you have an advantage the phone does not offer: you can restate the outcome in writing and send it with them.

• Confirming resolution: "Before I let you go, is the duplicate charge sorted for you, or is anything still open?"
• Summary close: "To recap: the $89 charge from the 14th is being reversed, you'll see it in three to five business days, and I've noted the account so it can't happen again. Reference is CX-4821."
• Close with a real next step: "You'll get a confirmation email within the hour. I've also set myself a reminder to check on Thursday that the reversal actually landed, and I'll message you either way."
• Warm close: "Glad we got that sorted, and thanks for being patient with the back and forth. Anything else while I'm here?"

The summary close is the highest-value line in this entire library. It gives the customer a written record, it forces the agent to state the outcome explicitly (which catches the cases where nothing was actually resolved), and it is the single cheapest protection for your first contact resolution rate. Customers who leave a chat with a written summary come back to reopen it far less often.

A full chat example, annotated

Individual lines are easy. Stitching them into a conversation is the part teams struggle with, so here is a complete interaction using the scripts above.

Nine messages, one apology that names the actual failure, one honest limit, and a written summary. Nothing in it is clever. All of it is repeatable, which is the point.

What does a customer service script look like?

A customer service script is a short block of prepared language for one recurring situation, written the way an agent would actually speak, with brackets marking the parts that change. It is usually two to four sentences, not a page. Good scripts specify the moment they belong to (greeting, hold, decline, close), mark which lines must be delivered exactly for compliance, and leave the middle of the conversation free for the agent to respond to the actual person.

How do you start a chat with a customer?

Start with your first name, a short offer of help, and one open question, sent within a few seconds. If the customer already described the problem, reference it instead of asking them to repeat it. Skip long greetings, company slogans, and menus of options. The goal of the first message is to prove a human arrived and to get them talking, nothing else.

What should you not say in a customer service chat?

Avoid "I apologize for any inconvenience," "unfortunately, as per our policy," "you should have," and "calm down." Each either blames the customer or hides behind process. Also avoid unexplained silence longer than about a minute, which reads as abandonment, and avoid "one moment" without a time estimate. Replace all of them with a specific statement of what you are doing and what you can do.

How many chats can an agent handle at once?

Published 2026 benchmarks generally put new agents at one chat, experienced agents at two to three, and strong performers at four or more. The ceiling is set by how well your hold and idle scripts absorb waiting time, not by typing speed. Raising concurrency without those scripts in place mostly produces slower first replies and lower satisfaction, which is the opposite of the intent.

Where chat scripts fit in the wider operation

Scripts are a floor, not a ceiling. They give every agent the same reliable language for the moments that repeat, so the energy goes into the customer's actual problem rather than into composing a greeting for the nine-hundredth time. The teams that get the most out of them do three things beyond writing the words: they load the scripts into the help desk as one-keystroke macros (a script an agent has to find and paste is a script that goes unused), they review them each quarter against the conversations actually arriving in the queue, and they track whether the scripts are moving anything by watching the support metrics that matter rather than by asking agents whether the scripts feel good.

For the asynchronous side of the job, the written replies you send to an inbox or a ticket hours later, the equivalent library is our set of customer service response templates, which are built for a customer who is not sitting there watching. And if chat volume is climbing faster than you can staff it, the answer is rarely more macros. It is usually a mix of deflecting the repetitive contacts before they reach a queue and tightening how the shared inbox behind the chat widget is run. Scripts make each conversation better. They do not reduce how many of them arrive.