The edge cases that matter: distress, abuse, and saying you cannot help

Most writing about chatbot edge cases is a list of amusing inputs: the emoji-only reply, the two-thousand-word message, somebody asking for a poem. Those are worth handling and they are not what should worry you.

The edge cases that matter are the ones where a wrong response does damage: somebody in genuine distress, somebody being abusive, somebody who is not the person you think, somebody describing a situation that is dangerous, and somebody who has said stop. Get those right and the emoji replies become a tidy-up job.

What we'll cover

• Sorting edge cases by consequence
• Distress, which needs a person
• Abuse, and what the bot should do
• Anything that sounds dangerous
• Building it with CodeWords
• When it is not the customer
• "Stop", and honouring it properly
• Admitting it cannot help
• The ordinary ones, briefly
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Sorting edge cases by consequence

Three tiers, and the effort should follow the consequence rather than the frequency.

Harm. A wrong response could hurt somebody, break a legal duty, or leave a person without help they needed. Distress, safeguarding concerns, anything unsafe, anything medical.

Damage. A wrong response loses the customer or the money. Abuse handled badly, a complaint answered automatically, a price given wrongly, somebody told their appointment is fine when it is not.

Friction. A wrong response is merely annoying. Off-topic questions, emoji, very long messages, unexpected phrasing.

Most published advice spends its time on the third tier because it is easy to write about. Spend yours on the first.

Distress, which needs a person

Somebody may message a business at the worst moment of their week. A bereavement that explains a cancellation. A domestic situation behind an urgent lock change. A customer who is frightened about money. A person who says something that suggests they are not safe.

The correct response is the same in all of them: stop automating and get a person there, quickly.

Three rules.

Do not attempt comfort. An automated expression of sympathy, once recognised as automated, reads as dismissal and makes things worse.

Do not continue the flow. Asking somebody who has just mentioned a bereavement to confirm their postcode is the failure everybody remembers.

Acknowledge simply and hand over. "Thank you for telling me. I am getting a person to pick this up now." Short, honest, and then it actually happens.

Where somebody says something suggesting they are at risk of harm, that routes to a person immediately and the response includes appropriate signposting to help rather than anything improvised. A business is not a support service and it should not pretend to be one, but it also should not carry on asking about a boiler.

Decide in advance who picks these up and how fast, and check that the alert actually reaches somebody.

Abuse, and what the bot should do

It happens, usually to businesses that have already got something wrong.

Do not argue. An automated system trading responses with an angry person is both undignified and ineffective.

Do not respond in kind or moralise. "Please be respectful" from a machine inflames rather than calms.

Acknowledge and escalate. "I am getting somebody to look at this now" is usually all the bot should say.

Log it, with the thread intact, because the person picking it up needs the history and because a pattern matters.

Protect staff. Whoever handles these should have a defined route to end a conversation, and that should be policy rather than a judgement made while being shouted at.

Worth separating anger from abuse. A furious customer with a legitimate complaint needs a good person quickly, and treating them as abusive is its own mistake. The distinction is behaviour, not volume.

Anything that sounds dangerous

A customer describing a smell of gas, a burning smell, water near electrics, a symptom that could be carbon monoxide, an allergic reaction.

One rule, and it does not bend: an automated system can ask, escalate and repeat published safety guidance, and it cannot assess, reassure or judge severity. No automated exchange should ever conclude that something is probably fine.

So the response is the recognised advice for that situation, immediately, plus a person. Not a booking slot, not a diagnostic conversation, not a question about the model number.

Write these responses in advance with somebody qualified, store them as fixed text, and test them with the phrasings customers actually use rather than the ones you would use. "There's a funny smell" is what people write.

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: the escalation cases first, what each one says, who it alerts, and what stops the rest of the flow.
3. Authorize the connections to wherever conversations and alerts need to land, and your WhatsApp Business Platform account.
4. Describe the exceptions in detail, since in this area the exceptions are the design: distress, abuse, anything unsafe, a third party, an opt-out, a question you cannot answer.
5. Test the escalations quarterly with real phrasing, and check that the alert reaches a person who is actually available.

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.

When it is not the customer

A number is not a person, and several common situations put somebody else at the other end.

A partner using the same handset. An adult child arranging something for a parent. A tenant messaging about a landlord's property. A new owner of a recycled number. An employee using a company phone after leaving.

Two consequences. Do not volunteer stored details unprompted, because greeting whoever messages with the last person's name, address or appointment is a disclosure. And where something consequential is being changed, confirm identity rather than assuming, particularly for anything involving money, addresses or cancellations.

Where somebody is clearly acting on another person's behalf, that is normal and fine, and the flow should be able to record it rather than treating the caller as the customer.

"Stop", and honouring it properly

Somebody says stop, or unsubscribe, or "don't message me again", or just "no thanks, take me off this".

Three requirements, and most implementations fail the second and third.

Recognise it however it is phrased. People do not write the keyword you were expecting.

Apply it everywhere, not only to the automation that happened to send the last message. Being removed from reminders and still receiving offers is the version that generates complaints.

Confirm it, once, then say nothing further. A confirmation is a courtesy; anything after it is a breach of what they just asked for.

Then check it actually works, periodically, by asking to be removed yourself and seeing what arrives afterwards. This is the cheapest test in this article and almost nobody runs it.

Admitting it cannot help

The single most underrated message in conversational design, and usually the worst written.

A good failure message does three things. It says plainly that it cannot help with this. It says what happens next, with a timescale. And it offers a route to a person that actually exists.

"I'm sorry, I didn't understand that" does none of those. It implies the customer wrote something wrong, offers nothing, and invites them to try again into the same wall.

Two supporting habits. Fail after one unsuccessful attempt at clarification rather than three, because repeated misunderstanding is where people give up on the business rather than on the bot. And log every failure with the message that caused it, since that log is the most useful list you will have for improving anything.

The ordinary ones, briefly

Off-topic questions. Answer briefly if trivially answerable, otherwise redirect without being stiff about it.

Ambiguity. Ask rather than guessing. A wrong guess acted on is more expensive than one clarifying question.

Very long messages. Extract what you need, confirm it, and do not summarise anything that functions as an instruction.

Emoji only. Usually acknowledgement. Treat a thumbs-up as a yes only where a yes is unambiguous and nothing consequential follows.

A language you do not support. Say so in that language if you can, and offer the route you do have.

Silence mid-flow. Follow up once, keep the partial, then stop.

Making it survive

Test escalations quarterly with real customer phrasing.

Check the alerts arrive at somebody who is available.

Test your own opt-out and see what still comes.

Read the failure log weekly for the first few months.

Give staff a defined route to end an abusive conversation.

Limits worth knowing about

A bot cannot judge whether a situation is safe, only escalate.

Escalation requires somebody to escalate to, and out of hours that has to be an honest answer rather than a promise.

Recognising distress is imperfect, so err towards involving a person.

Handling abuse well does not make it acceptable, and staff wellbeing is a policy question rather than a design one.

Some conversations should never have been automated, and noticing that is a legitimate outcome.

What to build first

The escalation list: distress, abuse, anything unsafe, and "stop". Write what each one triggers, who it reaches, and how quickly, then test all four with the words customers actually use. The emoji handling can wait a month; these cannot.

Two habits make the difference. Write a failure message that says what happens next and offers a person who exists, because "I didn't understand" is where customers decide the business is not worth the effort. And test your own opt-out every so often, since being ignored after asking to be left alone is the one failure that turns a mild irritation into a complaint.

Frequently asked questions

Which edge cases actually matter?

The ones where a wrong response does harm or loses the customer: distress, abuse, anything unsafe, somebody who is not the customer, and an ignored opt-out. Emoji and off-topic questions are tidy-up work.

What should happen when a customer is clearly distressed?

Stop the flow, acknowledge simply, and get a person there quickly. Do not attempt automated comfort and do not carry on asking for a postcode.

How should abusive messages be handled?

Do not argue, do not moralise, acknowledge and escalate, log the thread intact, and give staff a defined route to end the conversation. Anger with a legitimate complaint is not the same as abuse.

Can a bot decide whether something is dangerous?

No. It can ask, escalate and repeat published safety guidance. It must never conclude that a situation is probably fine.

What if the person messaging is not the customer?

Common. Do not volunteer stored details unprompted, and confirm identity before anything consequential. Somebody acting on another person's behalf is normal and should be recordable.

How should an opt-out be handled?

Recognised however it is phrased, applied across every automation rather than the one that sent the last message, confirmed once, and then silence. Test it yourself periodically.

What makes a good failure message?

Saying plainly it cannot help, saying what happens next with a timescale, and offering a route to a person that exists. "I didn't understand that" does none of those.

How many times should a bot try to clarify?

Once. Repeated misunderstanding is where people give up on the business rather than on the bot.

Should a thumbs-up count as a yes?

Only where a yes is unambiguous and nothing consequential follows. For anything that costs money or moves an appointment, confirm in words.

How do I know the escalations work?

Test them quarterly with the phrasings customers really use, and check the alert reaches somebody who is actually available. An escalation into an unwatched inbox is not an escalation.

Related reading

• Multi-stage flows and keeping state
• Voice messages and lossy transcription
• Data protection for a messaging bot