How a bot should sound: the specific tells, and what to write instead

"Make it sound more natural" is the least actionable instruction in this field. Naturalness is not a quality you add; it is what is left when you remove the specific things that make writing feel machine-generated, and those things are identifiable and fixable one at a time.

It is also worth being clear that sounding human is not the goal. People messaging a business want their question answered, and a bot that is warm, wrong and slow is worse than one that is plain, right and immediate. The aim is writing that does not get in the way.

What we'll cover

• Length, and the medium you are in
• The first message
• The tells, specifically
• Apologies, which are overused
• Building it with CodeWords
• How to say no
• Questions people can answer
• Confirmations that are worth reading
• Personality is usually the wrong fix
• Writing for somebody who is annoyed
• Making it survive
• Limits worth knowing about
• What to fix first
• Frequently asked questions

Length, and the medium you are in

Messaging is not email, and the most common failure is writing email in a messaging app.

One idea per message. A message containing a confirmation, a price and a question gets one of the three answered.

Two or three lines. Anything longer is scrolled past on a phone, which is where every one of these is read.

No opening pleasantry before the content. "I hope this message finds you well" belongs to a different medium entirely.

Break up sequences. Two short messages read better than one long one, within reason. Five in a row reads as spam.

The test is whether it can be read at a glance while walking. If it needs attention to parse, it needs cutting.

The first message

It does more work than anything else and it is usually written last.

Four things, briefly: who you are, that this is an automated assistant, what it can do, and how to reach a person. Then stop.

Say it is automated. Businesses worry this is off-putting; the alternative is a customer who works it out later and feels handled, which is considerably worse. Being straightforward about it buys a great deal of patience when something goes wrong.

What to leave out: a menu of nine options, a paragraph about your values, and any claim about being intelligent. Ask what they need and let them say it.

The tells, specifically

Nine things that make writing read as machine-generated. Removing them does more than any instruction about tone.

Restating the question before answering it. "You asked about our opening hours. Our opening hours are…" Answer it.

Over-signposting. "Great question!", "I'd be happy to help with that!", "Let me look into that for you." None of it carries information.

Excessive enthusiasm. Exclamation marks, "Perfect!", "Absolutely!" in response to a postcode.

Symmetrical structure every time. Acknowledge, answer, offer more help, every message, identically. The rhythm is what people notice even when the content is fine.

Hedging. "It may be possible that", "typically", "in some cases", where a direct answer exists.

Formal register that nobody uses. "Kindly advise", "please be informed", "at your earliest convenience."

Repeating the customer's name. Once at the start is warm. Three times is unsettling.

Explaining its own process. "I'm now checking our system." Just check it.

The unprompted offer to help further, on every message, which is filler.

Most bot copy improves substantially from deleting these and changing nothing else.

Apologies, which are overused

"I'm sorry, I didn't understand that" is probably the most damaging sentence in conversational design, and the apology is the smallest part of the problem.

It blames the customer for phrasing, it offers nothing, and it invites them to try again into the same wall. Two of those in a row is where people give up on the business rather than on the bot.

Write failure as information instead. "I can't help with that one. I've sent it to the team and someone will reply by 9am tomorrow." Says what happened, what is next, and when.

Save real apologies for real failures. A business that apologises constantly for trivia sounds insincere when something actually goes wrong, and by then the word has stopped meaning anything.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder, including how you want it to sound and what it should never say.
3. Authorize the connections to your existing systems and your WhatsApp Business Platform account.
4. Describe the exceptions in the tone you want them handled: how to decline, how to escalate, what to say when something is wrong.
5. Read the first fortnight of real conversations aloud, because problems with how writing sounds are audible long before they are visible.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

How to say no

The most-used and least-written message type. A good no has four parts and fits in three lines.

The answer, first. "We don't cover Sheffield, I'm afraid."

The reason, if it helps. One clause, not a paragraph.

An alternative, if you have one. The name of somebody who does, or a date when you could.

Nothing else. No apology paragraph, no invitation to get in touch about something else.

Businesses agonise over declining and customers mostly do not mind, provided it is quick and clear. What they mind is being left to work it out from three vague messages.

Questions people can answer

Half of what reads as a stupid bot is a badly formed question.

One question at a time, unless you are deliberately asking for a short list, in which case say how many.

Say the format when it matters. "What's the reg?" beats "could you provide vehicle identification details".

Give an example for anything unusual.

Never ask what you already have, which is the complaint people make most.

Ask for the thing you need, not the thing your system stores. If the field is a category, ask the human question and map it yourself.

Make optional questions obviously optional, or people abandon rather than answer.

Confirmations that are worth reading

Underrated, and the place where wording prevents real cost.

State back what will actually happen, in the customer's terms, with the details they would check. "Thursday 14 May, 9am, at yours, brake pads and discs, £180 including VAT." Not "your booking has been confirmed."

Two rules. Put the things people get wrong first, which is usually the date and the price. And make the correction route obvious in the same message, since the whole point of a confirmation is catching a mistake while it is cheap.

Personality is usually the wrong fix

When a bot feels bad, the instinct is to add character. It is nearly always the wrong move.

Jokes age, and they read terribly to somebody who is annoyed or worried. A distinctive voice makes every failure more jarring, because the gap between the persona and the unhelpfulness is wider. And a persona is another thing to maintain across every message and every language.

What makes a bot feel good is being right, being fast, being clear about what it cannot do, and handing over cleanly. Those are the same things that make a person feel good to deal with.

Warmth is fine, and warmth is mostly brevity, directness and not wasting anybody's time. If you want one stylistic instruction, it is to write the way the best person in your business talks, which is usually plainer than what gets written down.

Writing for somebody who is annoyed

Most bot copy is written imagining a calm customer with a simple question. A good proportion of the people reading it are neither, and copy that works for the first reads badly to the second.

Four adjustments, and they cost nothing.

Drop the warmth, keep the clarity. Friendliness aimed at somebody who is frustrated reads as not listening. Plain and direct reads as competent.

Answer before acknowledging. "We can get somebody out tomorrow morning" lands better than a sentence of sympathy followed by the same information.

Never explain why the problem happened unless they asked. Explanation reads as excuse to somebody who wants a resolution.

Offer the person immediately. Somebody annoyed enough to say so should not have to work out how to reach a human.

Worth writing your key messages twice, once for each reader, and checking that the annoyed version does not make things worse. The failure message, the decline and the delay notice are the three where this matters most, because those are the ones that reach people at their least patient.

Making it survive

Read conversations aloud, monthly. It is the fastest diagnostic there is.

Keep a list of banned phrases, starting with the nine tells.

Rewrite the failure message whenever you see it land badly.

Check the declines, since they are the most-used messages and the least reviewed.

Get somebody outside the business to read it, because you have stopped hearing your own copy.

Limits worth knowing about

Good writing cannot rescue a wrong answer.

Tone does not travel between languages, and a register that works in one reads differently in another.

Customers vary, and what one finds warm another finds familiar.

Consistency matters more than perfection, because the rhythm is what people notice.

You cannot hear your own copy after the third read.

What to fix first

The failure message. It is the one customers see when they are already not getting what they wanted, it is almost always written as an apology that blames them for phrasing, and rewriting it into what happens next and when takes ten minutes.

Two habits make the difference. Delete the nine tells and change nothing else, because most bot copy improves more from that than from any rewrite. And read the conversations aloud once a month, since everything wrong with how writing sounds is obvious when spoken and invisible on a screen.

Frequently asked questions

How long should a bot's messages be?

Two or three lines, one idea each. Anything that needs attention to parse on a phone needs cutting, and a message carrying a confirmation, a price and a question gets one of them answered.

Should a bot say it is a bot?

Yes, in the first message. A customer who works it out later feels handled, and being straightforward buys real patience when something goes wrong.

What makes writing sound machine-generated?

Restating the question, over-signposting, excessive enthusiasm, identical structure every time, hedging, stiff formality, repeating the name, explaining its own process, and offering further help on every message.

What is wrong with "I'm sorry, I didn't understand"?

It blames the customer for phrasing, offers nothing and invites another attempt at the same wall. Write what happened, what is next and when instead.

How should a bot decline?

The answer first, a one-clause reason if it helps, an alternative if you have one, and nothing else. Customers mind vagueness far more than they mind a no.

Why do customers give unhelpful answers?

Usually because the question was badly formed. Ask one thing at a time, say the format when it matters, give an example for anything unusual, and never ask for something you already have.

What should a confirmation contain?

What will actually happen, in the customer's terms, with the date and price first, and an obvious way to correct it. Not "your booking has been confirmed."

Should a bot have a personality?

Rarely. Jokes age, read badly to annoyed customers, and widen the gap when something fails. Being right, fast and clear is what makes a bot feel good.

How do I review the writing?

Read conversations aloud monthly, keep a banned-phrase list, check the decline messages specifically, and get somebody outside the business to read it.

Does tone translate?

No. Register varies by language and by country within a language, so a tone decision has to be made per language with somebody who speaks it.

Related reading

• Buttons, lists and free text
• The smallest version worth launching
• The edge cases that actually matter