Short answer: Write a customer service script by listing the ten situations your team actually handles most, drafting each one out loud in the words a good agent already uses, then marking every line as either fixed (compliance, disclosures, closings) or flexible (everything about the customer's specific problem). Test each draft on twenty real interactions and cut whatever makes agents sound stiff. The template below gives you the structure; your call recordings give you the language.
Last updated: August 2026.
Most customer service scripts fail the same way. Someone writes them in a document, alone, in written English rather than spoken English, covering situations that sound plausible rather than the ones that fill the queue. The team reads them once, finds they do not fit any real call, and quietly goes back to improvising. The document stays in the shared drive as evidence that scripts were tried and did not work.
The method below fixes that by inverting the order: language first, structure second. If you want finished scripts to copy rather than a method for writing your own, we have a library of customer service scripts and call center scripts for greetings, holds, transfers, and closings, plus a separate set of live chat support scripts for text channels.
How do you write a customer service script?
Write a customer service script in five passes. Pull the ten highest-volume situations from your ticket data. Listen to how your best agent already handles each one and transcribe their actual words. Shape that transcript into a structure of opening, diagnosis, action, and close. Mark every line fixed or flexible. Then test it live for two weeks and cut what makes people sound recited.
The order matters more than any individual step. Teams that start from structure produce scripts nobody can say out loud. Teams that start from what a good agent already says produce scripts that sound like the team, because they are the team.
1. Pick the situations from data, not memory
Export your last quarter of contacts grouped by issue type and take the top ten by volume. Almost every team is surprised by this list. The situations people remember are the dramatic ones, the escalation and the furious customer, but the situations that consume the hours are password resets, "where is my order," and billing questions about a charge the customer forgot they authorized. Script the volume, not the drama. You can add the hard edge cases later.
2. Transcribe your best agent instead of drafting from scratch
Find the person on your team whose interactions you would happily show a customer, pull five of their recordings or transcripts for the situation you are scripting, and write down what they actually say. This is the step nearly everyone skips and it is the one that makes the difference. You will get contractions, half-sentences, and small acknowledgments ("okay, I see it") that no one would ever type into a script document but that make the difference between a person and a recording.
3. Give it a spine: open, diagnose, act, close
Once you have the raw language, shape it. Nearly every service interaction has the same four movements: establish who you are and invite the problem, ask the questions that narrow it down, state what you are going to do, and confirm the customer is satisfied before ending. Slot your transcribed language into those four, and you will usually find one movement is missing entirely. It is almost always the close, which is why so many interactions end with an awkward trailing off.
4. Mark every line fixed or flexible
This is the single most useful thing you can do for the people who have to use the script. A line is fixed if getting it wrong creates legal or brand risk: recorded-line notices, identity verification, refund policy wording, regulatory disclosures. Everything else is flexible, which means the agent is expected to say it in their own words. Use bold, a colored background, anything visual. Without this marking, agents treat the entire document as either mandatory (and sound robotic) or optional (and skip the disclosure).
5. Test on twenty real interactions before rolling out
Give the draft to two or three agents and ask them to use it for a week, marking any line they found themselves rewording. Those rewordings are your edits. If three different people all rephrase the same sentence, that sentence is written and not spoken, and it goes. Two weeks of this removes roughly a third of a typical first draft.
Customer service script template
Copy this structure per situation. It fits on one screen on purpose: a script an agent has to scroll through is a script they will not use while a customer is talking.
| Section | What goes here | Fixed or flexible |
|---|---|---|
| Situation | The trigger, in the customer's words, not yours ("my card was charged twice") | Label only |
| Opening | Greeting, your name, invitation to explain. Any recorded-line or disclosure language | Fixed |
| Verify | The minimum identity check for this situation. Keep it short and say why you are asking | Fixed |
| Diagnose | Two or three questions that narrow the cause, in order from broadest to most specific | Flexible |
| Acknowledge | One sentence naming the impact on them before you talk about the fix | Flexible |
| Action | What you are doing, and the timeline. State it as a commitment, not a possibility | Flexible wording, fixed commitments |
| If you cannot help | The honest no, the reason, and the nearest alternative you can offer | Flexible |
| Close | Confirm resolution, state any follow-up, thank them, end cleanly | Fixed |
| Escalate when | The specific conditions that end this script and start a handoff | Fixed |
The "escalate when" row is the part teams leave out and then regret. A script without an exit condition leaves agents grinding through a conversation that stopped being winnable four minutes ago, because nothing told them they were allowed to stop.
What does a customer service script look like?
A finished customer service script looks like a short, labeled page of spoken sentences with the mandatory lines visually marked, not a paragraph of prose. Here is the duplicate-charge situation written out in full, so you can hold it next to your own draft.
Situation: Customer says they were charged twice.
Opening (fixed): "Thanks for calling [Company], this is Daniel. Just so you know, this call may be recorded for quality. What can I help you with today?"
Verify (fixed): "I can pull that up. To protect the account, can you confirm the email on file and the last four digits of the card?"
Diagnose (flexible): "Got it, I see both charges. Can you tell me the date you were expecting the charge? ... And did you get two confirmation emails, or just one?"
Acknowledge (flexible): "Okay, that is money out of your account that should not be, and I understand why you want it sorted today."
Action (flexible wording, fixed commitment): "Here is what I am doing. I am refunding the duplicate now. It leaves us today, and your bank typically posts it in three to five business days. I will email you the confirmation before we hang up so you have it in writing."
If you cannot help (flexible): "I am not able to speed up your bank's posting time, and I do not want to promise you something I do not control. What I can do is send the refund confirmation now so you have proof of the reversal if you need to call them."
Close (fixed): "So: refund issued today, confirmation to your email in the next few minutes. Is there anything else open for you before I let you go? Thanks for catching this."
Escalate when (fixed): Three or more duplicate charges, any charge over $500, or the customer states they have already disputed it with their bank. If a dispute is already open, do not refund; route to billing, because a refund on top of an open dispute creates a double credit. The distinction between those two paths is worth understanding before you write this script, and we cover it in chargeback vs refund vs dispute.
Notice how much of it is short. Spoken sentences run about half the length of written ones, and any line longer than about fifteen words will get shortened by the agent anyway.
What makes a good customer service script?
A good customer service script is short enough to hold on one screen, written in spoken rather than written English, explicit about which lines are mandatory, built from situations that actually occur in volume, and revised on a schedule. Scripts that fail almost always fail on one of those five, and usually on the second.
A few specifics that separate the ones agents use from the ones they ignore:
- It survives being read aloud. Read every line out loud before it ships. If you would not say it to someone standing in front of you, rewrite it. "We apologize for any inconvenience this may have caused" fails this test immediately.
- It names the impact before the fix. One sentence acknowledging what the problem cost the customer does more for satisfaction than a faster resolution delivered flatly.
- It contains a real no. Most scripts cover the happy path and abandon the agent at the exact moment they need help. Write the refusal, the reason, and the alternative.
- It gets a review date. A script written against last year's product describes a company that no longer exists. Put a quarterly review in the calendar and check each one against what is currently in the queue.
- It leaves room. The middle of the conversation belongs to the agent. If your script tries to specify it, you have written a call flow, not a script, and the customer will hear the difference.
How to roll scripts out without making the team sound recited
How you introduce a script determines whether it helps. Hand it over as a compliance document and you get flat, recited delivery. Introduce it as a floor that guarantees nobody freezes on the hard moments, and agents treat it as support rather than surveillance.
Three things make the rollout work. Involve the agents whose language you transcribed and say publicly that the script came from them, because it did. Practice the fixed lines until they are automatic, since those are the only ones that need to be word for word, and an agent who has to read a disclosure will always sound like they are reading it. And build the scripts into onboarding rather than sending them around as a file, so new hires learn them alongside the systems and policies they connect to; teams running a shared training and certification program for new agents tend to get consistent delivery far faster than teams distributing documents and hoping, mostly because someone can actually see who has practiced what.
Then measure whether it worked. Script quality shows up in first contact resolution and in satisfaction on the specific issue types you scripted, not in average handle time, which will often get slightly worse at first as agents stop skipping the acknowledgment step. Watch the numbers you already collect in your customer service metrics for the scripted issue types specifically, since a blended average will hide the effect entirely.
When not to write a script
Scripts solve inconsistency and hesitation. They do not solve a broken process, and using them to paper over one makes things worse. If agents are struggling because the refund policy is genuinely unfair, or because they cannot see the customer's order history, no wording will fix it; you will simply have trained people to deliver bad news more smoothly, which customers read as evasion.
The test is to ask what the agent needs at the moment they are struggling. If the answer is "the right words," write a script. If the answer is "the authority to issue the credit" or "a system that shows me what they bought," the problem sits upstream in the process, and that is customer experience operations work rather than a writing job. Fixing the upstream problem usually removes the situation from your top-ten list entirely, which is the best possible outcome for a script.
Frequently asked questions
How long should a customer service script be?
One screen per situation, roughly 150 to 250 words. Anything longer will not be read during a live conversation, and agents will fall back on memory, which defeats the purpose. If a situation genuinely needs more, it is usually two situations wearing a trench coat and should be split.
Should agents read the script word for word?
Only the lines you have marked fixed: disclosures, verification, refund policy wording, and closings. Everything else should be delivered in the agent's own words. Requiring word-for-word delivery of the whole script is the most common cause of the robotic tone teams then blame the script for.
How often should customer service scripts be updated?
Quarterly, and immediately after any product, pricing, or policy change. The practical trigger is your ticket data: if your top ten issue types have shifted since the scripts were written, the scripts are describing a queue you no longer have.
Do scripts work for email and chat too?
The method transfers, the language does not. Written channels need shorter sentences, no filler acknowledgments, and different pacing, because the customer sees silence rather than hearing it. Start from the channel-specific versions instead of adapting a phone script: response templates for email and tickets, and chat scripts for live widgets.
Start with one situation. Take your highest-volume issue type, transcribe how your best agent handles it, run it through the template above, and test it for two weeks. One script that agents actually use beats a complete library nobody opens, and the second one takes half as long to write because you will have learned what your team's spoken voice looks like on the page.