It is ten past eleven at night and a customer types: "My package never arrived." The assistant answers: "Sorry, I didn't understand that." The customer tries again, gets a menu with three options that don't fit, and types the only thing left: "Can I talk to a person?" The assistant answers: "Sorry, I didn't understand that."
The US Consumer Financial Protection Bureau has a name for this. It calls it a doom loop: automated responses that lead customers "in continuous loops of repetitive, unhelpful jargon or legalese without an offramp to a human customer service representative." What strikes me every time I see one is that the model behind it is usually fine. The language understanding works. What failed is everything around it: nobody decided what the assistant was for, where it should stop, or what it should do when it got lost.
I'm a technical project manager at Blits.ai. Most of my week goes into building and testing conversational AI for banks and large enterprises, in English, Arabic dialects and Turkish, across chat and voice. This article collects what we have learned about designing conversations that hold up with real customers, organised around the questions teams ask us most.
Conversational AI design is the practice of shaping how chatbots, voice agents and AI assistants understand people, guide a conversation, respond in the right tone and recover when something goes wrong. It covers goals, boundaries, wording, fallback paths and the handoff to a human. It is not the same as writing a prompt.
The distinction matters because customers judge the experience, not the model. Gartner found that 64 percent of customers would prefer companies didn't use AI in customer service, and their biggest worry was that it would become harder to reach a person. Customers are reacting to the design they meet, whatever model sits behind it.
A customer who cannot reach a person will blame the AI, whatever the model is.
Start with the job the customer is trying to get done, not with what the AI can do. "Reschedule a delivery", "block my card" and "check my claim" are jobs. "Our bot can answer questions" is not.
For every priority job, we map the conversation from the customer's side before anyone writes a prompt. The map starts with the goal, meaning the outcome the person wants and not only the topic they mention, and the information the assistant must collect to complete or route the request. It then describes the happy path, the shortest version of the conversation when everything is clear, and the unhappy paths: missing details, vague answers, emotional language, requests outside scope and system errors. Decision points mark where the assistant must choose between answering, asking, escalating or stopping. The last entry is the risk level: is this action trivial, sensitive, regulated, financial or impossible to undo?
The risk level is where banking teaches you humility. "What is my balance?" and "block my card" can arrive in the same chat, a minute apart, from the same anxious customer. They need completely different designs. The map forces product, compliance, operations and engineering to agree on that before the assistant goes live, instead of after the first complaint.
Every conversational interface has three layers: understanding what the person means, steering the dialogue forward, and shaping the response. If any one of them fails, the whole experience feels broken, however powerful the model is.
Understanding means recognising intent, not matching keywords. "I never got it", "my package is missing" and "it says delivered but it isn't here" are the same problem. A good system uses context, account data and earlier turns to see that, and knows when it is not confident enough to act.
Understanding also means being grounded in approved sources: product documentation, policies, account data. An assistant without grounding sounds fluent while being wrong, and the company owns every word. When Air Canada's chatbot gave a passenger the wrong bereavement fare policy, the airline argued that the bot was "a separate legal entity that is responsible for its own actions." The tribunal disagreed and held Air Canada liable.
Your chatbot is your company talking. Whatever it says, you said.
Dialogue decides how the conversation moves: when to let the person explain freely and when to follow a fixed sequence. Response covers what the assistant says and how: tone, length, structure and clarity, in chat and in voice.
Let the AI reason freely when the customer is exploring or describing a problem. Make it propose and confirm before it changes anything. And make it follow a controlled flow for identity checks, payments, consent and anything regulated or impossible to undo.
We call these decision boundaries, and we draw them per task before writing a single prompt. The same assistant can move through all three zones in one conversation. Someone describes a problem in their own words (flexible), agrees to move a delivery (confirm first) and then asks for a refund to a new account (scripted). The design decides when the assistant switches, not the model's mood that day.
For the middle zone we use a simple pattern that customers find natural:
- Recognise the intent: "It sounds like you want to reschedule your delivery."
- Confirm when unsure: "Is that right?"
- Ask only for what's missing: "Which day works better for you?"
- Explain the action: "I can move it to Thursday afternoon."
- Confirm before committing: "Shall I make that change?"
- Close with the result: "Done. Your delivery is now scheduled for Thursday afternoon."
A fallback should always give the customer a way forward, and a handoff should pass the full context to the human so nobody has to start over. "I didn't understand" on its own gives the customer nothing to do next.
Nielsen Norman Group's research on chatbots said it plainly years ago: be honest about not understanding, and offer an escape hatch in the form of a real human, a phone number or another channel. We design fallback as a ladder: clarify, suggest what the assistant can do, ask the customer to rephrase, stop safely at a risk boundary, and hand over. When the customer repeats themselves, uses urgent language or reaches a risk boundary, we skip straight to the top.
Klarna learned the cost of getting this wrong in public. After a year of promoting its AI assistant, its chief executive told Bloomberg in May 2025 that the company was hiring human agents again, and that it is critical "that you are clear to your customer that there will always be a human if you want."
The handoff itself is where many designs fail. The human agent should receive the intent, a summary of the conversation, the details already collected, the steps already tried and any relevant system status. If the customer has to repeat everything, the AI has saved almost nothing. And for requests that run over days, the handoff is not the end of the conversation but one step in a case, which is why a conversation is not a case.
The opening message should tell the customer they are talking to an AI assistant, what it can help with, and how to start. Short, honest and concrete beats warm and vague.
"Hi, how can I help?" invites anything, including everything the assistant cannot do. Compare:
| Use case | Opening line |
|---|
| Customer support | "Hi, I'm the virtual assistant. I can track orders, start returns, change delivery details or connect you with a colleague." |
| Appointments | "I can book, move or cancel an appointment. What would you like to do?" |
| Troubleshooting | "Describe what's going wrong and I'll suggest the next step. If we can't fix it here, I'll route you to the right team." |
Saying it is AI is no longer just good manners. Article 50 of the EU AI Act requires that people are informed that they are interacting with an AI system, and that obligation applies from 2 August 2026. The Nielsen Norman Group advice from the same research still holds as well: clearly tell people what tasks the bot can do, and don't create false expectations.
Persona sets expectations about how the assistant communicates. It is not a quirky character. The right tone depends on the task and on the customer's state: calm and precise for billing, encouraging for troubleshooting, careful and never joking for health, money or security.
A useful persona guide describes how the assistant sounds when things go well, and how it sounds when the customer is confused, angry, worried or in a hurry. It also lists what the assistant never does: exaggerated enthusiasm, false certainty, humour in sensitive moments, or claims to feelings it doesn't have.
Language adds a layer most guides skip. In Arabic speaking markets, a perfectly correct answer in formal Modern Standard Arabic can still feel wrong to a customer who expects the way people in their own city speak. Register and dialect are part of the persona, and we test them with native speakers, not only with automatic scores. We wrote more about that in the voice quality gap.
Chat can show options, links and summaries that the customer can read back. Voice cannot, so voice needs shorter turns, fewer choices and confirmation of critical details one at a time.
A voice agent might say: "I found two options: Thursday morning or Friday afternoon. Which do you prefer?" The same assistant in chat can show both as buttons. Long numbers are the classic voice trap: an account number read back in one breath is impossible to check. Read it in groups, and confirm it.
Measure whether customers get their task done, not only whether they avoided a human. Containment is a useful number, but on its own it rewards exactly the doom loop this article started with.
Across the public deployments in our AI Use Case Library, the median reported containment rate is 61.5 percent across 28 organisations, and 16 of those 28 values come from vendors. It is a fair benchmark, but it tells you nothing about the customers who gave up halfway.
The metrics we watch alongside containment: task completion, first contact resolution, repeat contacts within a few days, fallback rate, escalation quality, abandonment points and how often customers have to correct the assistant. And we read transcripts. The moments where people rephrase, repeat themselves or go quiet show design problems that no dashboard reveals.
Testing needs messy input: typos, slang, vague requests, angry messages, contradictory details. And it needs repeating whenever a prompt, policy, model or knowledge source changes, because conversational systems drift.
Someone has to own every flow, prompt, knowledge source and metric, or the assistant slowly starts contradicting itself. Good governance keeps it coherent as products, policies and customers change.
That means named owners for flows and prompts, for the knowledge the assistant draws on, for compliance review and for quality assurance, with version control for all of it. It also means accessibility from the start: plain language, screen reader support, no meaning carried by colour alone, and room for people who need more time or simpler words. Designing for them makes the assistant better for everyone.
- Start from the customer's task, not from the technology.
- Tell customers they are talking to AI, and what it can do.
- Ask one clear question at a time.
- Confirm before anything sensitive or irreversible.
- Ground every answer in approved sources.
- Draw the boundaries: flexible, confirm first, scripted.
- Design fallback as a ladder that ends with a human.
- Pass the full context in every handoff.
- Match tone, register and dialect to the customer and the risk.
- Measure task completion and read transcripts, not only containment.
- Retest whenever prompts, policies, models or knowledge sources change.
None of this makes a bot sound cleverer. It makes it useful, which is all the customer at ten past eleven wanted in the first place. If you are designing or rescuing an assistant and would like a second pair of eyes on the conversation, you can review your flows with us.
