Conversational Design and CX Strategy
The design work that decides whether people use an assistant a second time: what it covers, what it says when it fails, when it hands over, and how you will know whether any of it worked.
Almost every conversational deployment we review has the same shape of problem, and almost none of it is the model. The scope is too broad, the failure language is defensive, escalation is buried, and nobody agreed in advance what success would look like. Those are design decisions, and they can be fixed without rebuilding anything.
Conversational design is the discipline of deciding what an assistant should cover, how it should behave when it cannot help, how it recovers from misunderstanding, when and how it hands over to a person, what it sounds like, and which measures will be used to judge whether it is working.
The four decisions that determine whether it works
- Scope. Which intents are in, which are explicitly out, and what happens at the boundary. Broad shallow coverage reliably loses to narrow deep coverage.
- Failure behaviour. What it says when it does not understand, when it does not know, and when it has failed twice. This is the copy people actually remember.
- Escalation. When it hands over, how quickly, and what travels with the conversation. Buried escalation raises abandonment, not containment.
- Measurement. Which numbers define success before launch, so the quarterly review is not an argument about impressions.
We work through these with the people who own the channel, and the output is a written specification that a build team can implement and a stakeholder can hold us to.
What the engagement covers
Transcript review, not opinion
We read real conversations, including the ones where people gave up, and identify the exact turn at which each failed. This produces a failure taxonomy for your assistant rather than a generic best-practice list, and it usually contradicts at least one thing everyone believed.
Scope and boundary design
Intents ranked by volume and answerability, with an explicit out-of-scope list. Saying clearly what the assistant does not do, at the moment it is asked, is more useful than attempting an answer and being wrong, and it costs nothing but the willingness to write it down.
Failure and recovery copy
The words for not understanding, not knowing, having failed twice, and the systems being down. Written to be plain and to offer a route onward rather than to apologise at length. This copy is reviewed with your brand and support teams because it will be read more often than your marketing.
Escalation design
Triggers, timing, what is passed to the person, and what the customer is told. We design so the handover feels like a continuation rather than a restart, which is the difference between a rescued conversation and a complaint.
Tone that survives contact
A voice specification with examples of what to say and what never to say, tested against difficult situations rather than happy paths. Personality is cheap to add and expensive to defend when someone is angry, so we specify restraint deliberately.
The measurement framework
Which numbers matter, how they are captured, what the baseline is, and which combinations count as regression. Typically resolution, escalation reasons, unanswered questions, satisfaction and abandonment, reported together so containment cannot be gamed.
This works on assistants we did not build
A large share of these engagements are on systems built in-house or by another supplier. The design specification is implementation-independent, and in most cases it improves the existing assistant substantially without a rebuild, which is a considerably cheaper answer than starting again.
What comes out of it
| Artefact | Used by | Why it matters |
|---|---|---|
| Intent scope and boundary list | Product and build team | Stops scope creep and defines the out-of-scope response |
| Failure taxonomy from real transcripts | Everyone | Turns 'it is not very good' into a ranked list of defects |
| Conversation copy set | Build team, brand, support | The language customers actually encounter most |
| Escalation specification | Support operations | Handover that does not restart the conversation |
| Voice and tone guide | Anyone writing for the assistant | Consistency as more people contribute |
| Measurement framework | Leadership | Agreed definition of success before launch |
How the engagement runs
Short, evidence-led and implementation-independent, whoever built the assistant.
Transcript and analytics review
Real conversations read and classified, failures located by turn, current measures collected as a baseline.
Scope and boundary workshop
Intents ranked with the channel owners, in-scope and out-of-scope agreed, escalation triggers defined.
Copy, tone and escalation design
Failure and recovery language written, voice specification produced, handover payload and messaging designed.
Measurement framework and handover
Success measures, capture method and regression definitions agreed, with a working session for the build team.
What you receive
A specification a build team can implement and a stakeholder can hold you to.
Failure taxonomy
Where real conversations break, by turn and by cause, ranked by volume.
Scope specification
In-scope intents, explicit out-of-scope list and the boundary response.
Conversation copy set
Greeting, misunderstanding, unknown, repeated failure, outage and closing language.
Escalation design
Triggers, timing, handover payload and customer-facing messaging.
Voice and tone guide
With examples, including what never to say, tested against difficult cases.
Measurement framework
Success measures, baselines, capture method and what counts as a regression.
Is this the right engagement?
Worth being direct. Conversational Design and CX Strategy is the wrong spend in some situations, and those are listed rather than buried.
Good fit if
- An assistant is live and underperforming, and nobody can say precisely why.
- You are about to build one and want the design settled before engineering starts.
- Escalation is a source of complaints.
- Different teams are writing conversation copy with no shared standard.
- Leadership and the delivery team disagree about what success means.
Choose something else if
- The underlying content is missing or wrong. No design fixes an empty knowledge base.
- You want implementation rather than specification, in which case this folds into the build.
- Nobody has authority to agree scope, which is the decision the engagement exists to force.
- There are no transcripts and no traffic, so there is no evidence to work from.
Frequently asked questions
Marked up with FAQPage schema so these answers can surface directly in search results and inside AI assistant responses.
What does conversational design actually cover?
Scope and boundaries, failure and recovery language, escalation triggers and handover, voice and tone, and the measurement framework. It is the set of decisions that determine whether people use an assistant twice, and it is largely independent of which technology sits underneath.
Can you do this for an assistant we already have?
Yes, and most of these engagements are exactly that. The specification is implementation-independent, and in our experience it improves an existing assistant substantially without a rebuild, which is a far cheaper answer than starting again.
Why is failure language so important?
Because it is what people encounter most in the sessions that matter. A clear, brief admission with a route onward keeps a customer; a long apology that loops keeps nobody. This copy is read more often than your marketing and is usually written last by whoever was free.
How do you decide what should be out of scope?
By volume and answerability, then by risk. Anything the assistant cannot answer reliably from content that exists, or that carries consequence if answered wrongly, is out of scope and said so plainly at the moment it is asked.
What should we measure?
Resolution, escalation reasons, unanswered questions, satisfaction and abandonment, reported together. Containment on its own is dangerous because it improves whenever you make reaching a person harder, which is the opposite of what you want.
Often paired with this
Most clients combine two or three engagements from the Conversational AI pillar. These are the ones that most often run immediately before or after.
AI Chatbot Development
A chatbot grounded in your own content, measured on resolution and satisfaction rather than on messages handled.
Read more →Voice Bot and IVR Modernisation
Menu trees replaced with natural speech, intent-based routing and a fast path to a person.
Read more →Contact Centre AI and Call Analytics
Every conversation analysed: automated QA, live agent assist, wrap-up and the reasons behind your contact volume.
Read more →Is this the right engagement?
Tell us what you are trying to build. If a different service fits better, or if you do not need us at all, we will say so.