AI Customer Service Tone of Voice: Persona, Formality, Limits

AI Customer Service Tone of Voice: Persona, Formality, Limits

The tone of voice of an AI customer service agent comes down to four written decisions: who is speaking (the persona), how formally, with which words, and how far the agent can go. Instead of telling the model to “be friendly,” write rules that someone can test against real messages and mark as right or wrong. That is how you avoid slang, false intimacy and promises the company cannot keep.

Key takeaways

• Tone of voice is a set of written rules, not an adjective. “Courteous and professional” on its own guides no one.
• Define the persona by its function (who answers, for whom, what it does and what it does not do), not by an invented personality.
• Pick one default level of formality and write down when it goes up, for example in complaints, sensitive topics or when the customer asks for a more formal register.
• List preferred and banned words and expressions, and test everything with difficult messages before you open the channel.
• Tone does not replace limits: the agent must say clearly what it cannot do and hand the conversation to a person.

Why tone of voice needs written rules

A language model tends to mirror the register of whoever writes to it. If the customer sends “hey, what's up?”, an agent without instructions may answer “Hey buddy!” If the customer writes in a curt, irritated way, it may respond with text that is far too effusive. The result is a service that changes personality with the mood of the person asking, and customers read that as inconsistency on the company's part.

There is also a less visible risk. Phrases of false intimacy, such as “leave it with me, I'll sort it out today” or “I know exactly how you feel,” sound like commitments. The agent feels nothing and often does not control the deadline. Tone and promises go together: every expression that is too warm is a chance to take on something the operation does not deliver.

That is why we treat tone as part of the service design, alongside scope and handoff rules. For the overall structure of the instructions, read How to Write Instructions for an AI Support Agent: 5 Blocks. Here the focus is only on the voice layer.

How to define the persona without inventing a character

In customer service, a persona is a professional role. It does not need a human name, an age, hobbies or a personal story. The more the agent pretends to be a person, the harder the illusion is to sustain, and the more likely the customer is to feel deceived on realizing they were talking to a machine. The transparency principle in Brazil's data protection law (LGPD) points the same way: make it clear that the service is automated. For the regulatory overview, the website of Brazil's data protection authority (ANPD) is the place to start.

A useful persona fits in a few fields:

• Role: “virtual assistant for company X, handling questions about orders, scheduling and quotes.”
• Audience: who usually writes in (end consumers, businesses, patients, students) and what they tend to want.
• Posture: objective, patient, in no hurry to close the conversation, no sales pressure.
• What it never pretends: to be human, to feel emotion, to have authority to approve exceptions, to know the customer's life.
• Assistant name: optional, as long as the first message says it is a virtual assistant.

Notice that posture is described through behavior. “Patient” becomes “if the customer repeats the question, answer again in different words, without pointing out that it was already answered.” That is the kind of sentence you can check in a test conversation.

Formality: choose a default and write down when it changes

There is no correct level of formality in the abstract. A clinic, a law firm and a skate shop have different expectations. What exists is formality that fits the brand and the channel. On WhatsApp, a professional but approachable register generally works, but that is your decision, not the model's.

A simple decision guide you can adapt:

• Default: speak to the customer directly, use short sentences, no slang, no softeners such as “just a quickie” or “one tiny second.”
• Goes up: use a title and surname (or “sir” and “ma'am”) when the customer does so, when the subject is legal, medical or financial, or when there is a formal complaint. If your agent runs in Portuguese, this is the shift from “você” to “o senhor” or “a senhora.”
• Never goes down: the agent does not mirror the customer's slang, swearing, heavy abbreviations or sarcasm. It can be lighter, but it stays within the brand standard.
• Emojis: an explicit rule. For example, none in complaints or sensitive topics, and at most one in simple confirmations, if the brand uses them.
• Regional expressions: avoid local idioms if the company serves the whole country. What sounds natural in one region can sound odd in another.
• Greeting: once per conversation, adjusted to the time of day, not repeated in every message.

The “never goes down” rule prevents the most problems. Mirroring the customer feels friendly, but it pulls the agent into a register the company did not choose.

Brand vocabulary: words to use and words to avoid

Vocabulary is where tone becomes concrete text. Start by looking at how the human team actually writes in its best conversations and at what the website and company materials call things. If you use real conversations as examples, remove personal data before putting them in instructions or test sets.

Build two short lists.

Preferred words and constructions:

• The official names of products, services and steps (for example, “proposal” or “quote,” but not both as if they meant the same thing).
• Verbs with clear action: “I'll check,” “I'll forward this,” “I can tell you.”
• Simple explanations for technical terms, the first time they appear.

Banned words and constructions:

• Nicknames and terms of endearment: “buddy,” “dear,” “sweetheart,” “boss.”
• Slang and interjections: “cool,” “gotcha,” “no worries,” “let's roll.”
• Empty promises: “absolutely,” “guaranteed,” “no problem” when there may be a problem.
• Fake empathy: “I completely understand what you're going through.” Prefer “I understand this caused a disruption” only when the fact is confirmed.
• Internal jargon the customer does not know, such as system acronyms.

The banned list also helps with review. If a banned term shows up in tests, you know exactly what to adjust.

Step by step: turning tone into testable instructions

The central rule: every tone instruction must be verifiable by reading the reply. If two people disagree about whether the rule was followed, it is still too vague.

• Gather examples: a few replies that represent the brand well and a few that are wrong, with the reason for each.
• Write the persona in a few sentences, using the fields from the section above.
• Swap adjectives for behaviors. “Courteous” becomes “greets once, thanks the customer for getting in touch, uses the name only if the customer provided it.”
• Write prohibitions specifically, with the list of terms and the emoji rule.
• Give a short example of a good reply for each frequent situation (simple question, request for a deadline, complaint, out-of-scope request).
• Build a test set of difficult messages: a customer using slang, a rude customer, pressure for a promise, an out-of-scope question, an emotional request, a transcribed voice message with errors.
• Define simple pass criteria with yes or no answers: did it address the customer directly? Did it avoid slang? Did it promise a deadline without data? Did it offer a handoff when it should have?
• Run the tests, adjust the instruction and run again. Repeat whenever you change the instruction text, the model or the knowledge base.

A well-written instruction is usually short and positive:

Address the customer directly, keep sentences to two lines, use no slang, softeners or emojis in complaints, and never state a deadline that is not in the system.

On evaluation method, OpenAI's documentation on evals and Anthropic's writing on how to evaluate AI agents show how to organize test cases and criteria. For keeping instructions lean and useful, Anthropic's material on context engineering is worth reading.

One important caution: a tone instruction is guidance, not a guarantee. For rules that cannot fail, such as banned terms or deadline promises, add a check on the reply before it is sent. This is what we describe in Guardrails for AI Agents: Input, Output and Action Controls.

Illustrative scenario: delivery date at a furniture store

Imagine, as a fictional example, a custom furniture store whose AI agent has access to order status. The customer writes:

hey man, what's up? are you guys actually delivering my wardrobe or just stalling?

A reply that fails the tests:

Hey man! Chill, it'll be there real soon, leave it with me!

The problems are clear and verifiable: it mirrored the slang, used an overly familiar address, and promised delivery without checking any data. A reply that passes:

Hello! I'm the store's virtual assistant. I understand the delivery date matters. Could you share your order number so I can check the status?

If the system returns no confirmed date, the follow-up passes the criteria like this:

I can't confirm the delivery date here. I'll forward your case to the delivery team, who will reply during service hours.

In the test set, this conversation becomes three checks: did not mirror slang, did not promise a deadline without data, offered a handoff when there was no information. Tone and limits were tested together, which is exactly the goal.

The limits of tone and how we apply the method

Tone has boundaries that are worth writing as rules of their own:

• Apologizing for the inconvenience is allowed. Admitting fault, promising compensation or negotiating an exception is not the agent's role.
• In conversations involving anger, urgency or distress, the tone becomes more sober, with no humor and no emojis, and the handoff to a person comes early. See Sentiment Analysis in Customer Support AI: When to Hand Off to a Human.
• The agent does not give opinions on out-of-scope subjects (politics, health, law). It only says it cannot help and points to the right path.
• Messages sent on the company's initiative follow the same vocabulary, but have their own rules on templates and consent, described in WhatsApp Outbound Messages: Templates, Opt-In and Best Practices.

In our method, this is organized in four moves. Map: survey how the team handles service today, which conversations are good and which create rework, and record that baseline. Limit: define what the agent can say and do, with the vocabulary lists and the prohibitions. Pilot: run one real flow, with conversations logged and a success criterion agreed before starting. Hand off: make sure the transfer to a person carries the conversation context, and decide at the end whether to expand, adjust or stop.

Frequently asked questions

Can I let the chatbot use emojis and the customer's name to seem closer? Yes, if it is a brand decision and it is written down. Define where they fit (for example, simple confirmations) and where they do not (complaints, collections, health). Use the name only when the customer has provided it, and avoid repeating it in every message.

Should the chatbot introduce itself as a virtual assistant? Yes, we recommend it. Saying in the first message that the service is automated prevents frustration, aligns with the LGPD transparency principle and lets the customer ask for a person when they prefer. It does not prevent a warm, professional tone.

Do I need to train my own model to get the brand's tone? In many cases, not to start. Clear instructions, short examples and a test set are usually enough for the voice register, and they are easier to adjust. Consider additional training only after measuring that the instructions do not solve the problem, because it requires more data and more maintenance.

How often should I review the tone? Review whenever you change the instruction, the model, the knowledge base or a campaign, and run the test set again. In addition, read a sample of real conversations at regular intervals, with care for personal data, to find expressions nobody anticipated.

Sources

• Anthropic: Demystifying evals for AI agents
• OpenAI: evals guide
• Anthropic: Effective context engineering for AI agents
• ANPD: Autoridade Nacional de Proteção de Dados