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

The WhatsApp chatbot edge cases that matter are the ones where a wrong response does damage: a person in distress, a person being abusive, a person who is not the customer, a situation that sounds dangerous, and a person who has said stop. Handle these five first. Odd inputs such as an emoji-only reply or a very long message are a tidy-up job.

Key takeaways

• Rank edge cases by consequence, not by frequency: harm first, then damage, then friction.
• When someone is distressed, stop the flow, acknowledge simply and route to a person.
• A bot can ask, escalate and repeat published safety guidance, but it must never judge that a situation is safe.
• Apply a "stop" request across every automation, confirm it once and then send nothing more.
• Write failure messages that say what happens next and offer a route to a person who exists.

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

Sort edge cases into three tiers and set your effort by consequence, not by how often each case occurs.

Tier	Cost of a wrong response	Examples
Harm	Someone is hurt, a legal duty is broken, or a person goes without help they needed	Distress, safeguarding concerns, anything unsafe, anything medical
Damage	The customer or the money is lost	Abuse handled badly, a complaint answered automatically, a wrong price, a wrong appointment confirmation
Friction	The reply is annoying	Off-topic questions, emoji, very long messages, unexpected phrasing

Most published advice covers the friction tier because it is easy to write about. Spend your effort on the harm tier first.

Distress, which needs a person

When a customer shows distress, stop automating and get a person there quickly. People may message a business at the worst moment of their week: a bereavement behind a cancellation, a domestic situation behind an urgent lock change, or a statement that suggests they are not safe. Three rules apply.

• Do not attempt comfort. Sympathy that the reader recognises as automated reads as dismissal.
• Do not continue the flow. Asking a bereaved person to confirm their postcode is the failure everyone remembers.
• Acknowledge simply and hand over. For example: "Thank you for telling me. I am getting a person to pick this up now." Then make it happen.

If someone says something that suggests a risk of harm, route to a person immediately and include appropriate signposting to help, not anything improvised. A business is not a support service and should not pretend to be one. Decide in advance who picks these up and how fast, and check that the alert reaches a real person.

Abuse, and what the bot should do

When a customer is abusive, the bot should acknowledge and escalate. It should not argue. Abuse usually reaches businesses that have already got something wrong.

• Do not argue or moralise. "Please be respectful" from a machine inflames the situation.
• Say little. "I am getting somebody to look at this now" is usually enough.
• Log the thread intact. The person who picks it up needs the history, and a pattern matters.
• Protect staff. Give them a defined route to end a conversation, written as policy, so nobody decides it while being shouted at.

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

Anything that sounds dangerous

When a message describes a possible danger, such as a gas smell, a burning smell, water near electrics, a possible carbon monoxide symptom or an allergic reaction, send the recognised safety advice for that situation immediately and bring in a person. An automated system can ask questions, escalate and repeat published safety guidance. It cannot assess, reassure or judge severity, and it must never conclude that something is probably fine.

Do not offer a booking slot, a diagnostic conversation or a question about the model number. Write these responses in advance with a qualified person, store them as fixed text, and test them with the phrasings customers use. People write "there's a funny smell", not the technical term.

Building it with CodeWords

You build these escalations in CodeWords by describing each case, its fixed wording and its alert route to Cody, the automation builder. CodeWords connects to 3,000+ integrations (CodeWords pricing page, 2026), 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 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, because here 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 available.

You describe the outcome; Cody builds it, connects it, and deploys it. The Free plan costs $0 and covers light use, Pro is $39 per month ($33 billed yearly) and Business is $100 per month (CodeWords pricing page, 2026). Details are on the pricing page.

When it is not the customer

A phone number is not a person, so the sender is sometimes not the customer. Examples include 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, and an employee still using a company phone after leaving. Two rules follow.

• Do not volunteer stored details unprompted. Greeting whoever messages with the previous person's name, address or appointment is a disclosure.
• Confirm identity before anything consequential, particularly money, addresses or cancellations.

Someone who acts for another person is normal, and the flow should record that arrangement instead of treating the sender as the customer.

"Stop", and honouring it properly

Honour a "stop" request in three ways, and most implementations miss the second and third.

• Recognise it however it is phrased. People write "unsubscribe", "don't message me again" or "no thanks, take me off this", not the keyword you expected.
• Apply it everywhere, not only to the automation that sent the last message. Being removed from reminders and still receiving offers generates complaints.
• Confirm it once, then send nothing further. Anything after the confirmation breaches what the person asked for.

Then test it: ask to be removed yourself and see what arrives afterwards. This is the cheapest test in the article, and few teams run it.

Admitting it cannot help

A good failure message does three things: it says plainly that it cannot help, it says what happens next with a timescale, and it offers a route to a person who exists. "I'm sorry, I didn't understand that" does none of these. It implies the customer wrote something wrong, offers nothing, and invites another attempt into the same wall.

Two supporting habits help. Fail after one unsuccessful clarification, not three, because repeated misunderstanding is where people give up on the business, not just on the bot. And log every failure with the message that caused it, because that log is your best list for improving the flow.

The ordinary ones, briefly

• Off-topic questions: answer briefly if the answer is trivial, otherwise redirect without stiffness.
• Ambiguity: ask, because a wrong guess that the bot acts on costs more than one clarifying question.
• Very long messages: extract what you need and confirm it. Do not summarise anything that works as an instruction.
• Emoji only: treat as acknowledgement. Count a thumbs-up as a yes only where the yes is unambiguous and nothing consequential follows.
• An unsupported language: say so in that language if you can, and offer the route you have.
• Silence mid-flow: follow up once, keep the partial progress, then stop.

Making it survive

• Test escalations quarterly with real customer phrasing.
• Check that alerts arrive at someone who is available.
• Test your own opt-out and see what still arrives.
• 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. It can only escalate.
• Escalation needs someone to escalate to. Out of hours, give an honest answer, not a promise.
• Recognising distress is imperfect, so err towards involving a person.
• Handling abuse well does not make it acceptable. Staff wellbeing is a policy question, not a design one.
• Some conversations should never have been automated. Noticing that is a legitimate outcome.

What to build first

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

Two habits make the difference. Write a failure message that says what happens next and offers a person who exists. And test your own opt-out regularly, because being ignored after asking to be left alone turns mild irritation into a complaint.

Frequently asked questions

Which edge cases actually matter?

The edge cases that matter are those where a wrong response does harm or loses the customer: distress, abuse, anything unsafe, a sender 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 continue asking routine questions such as a postcode. Decide in advance who picks these up and how fast.

How should abusive messages be handled?

Do not argue or moralise. Acknowledge, escalate, log the thread intact and give staff a defined route to end the conversation. Anger about a legitimate complaint is not abuse, and that customer needs a good person quickly.

Can a bot decide whether something is dangerous?

No. A bot can ask questions, escalate and repeat published safety guidance. It must never conclude that a situation is probably fine, because it cannot judge severity. Send fixed safety advice and bring in a person.

What if the person messaging is not the customer?

This is common. Do not volunteer stored details unprompted, and confirm identity before anything consequential. Someone acting on another person's behalf is normal, and the flow should be able to record that arrangement.

How should an opt-out be handled?

Recognise the request however it is phrased, apply it across every automation, confirm it once and then send nothing more. Test it yourself periodically by asking to be removed and checking what arrives afterwards.

What makes a good failure message?

A good failure message says plainly that the bot cannot help, says what happens next with a timescale, and offers a route to a real person. "I didn't understand that" does none of those and invites the customer to try again.

How many times should a bot try to clarify?

Once. Repeated misunderstanding is where people give up on the business, not only on the bot. After one failed clarification, say what happens next and offer a person.

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, ask for confirmation in words.

How do I know the escalations work?

Test them quarterly with the phrasings customers use, and check that each alert reaches someone who is 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