Behaviour Specs
A behaviour spec is where Adaptive CX becomes real. It's the document that stops you shipping "AI vibes" and starts shipping clear, testable service behaviour.
From journey maps to behaviour specs
Journey maps have been the primary artefact of customer experience design for over a decade. They describe what happens: the stages a customer moves through, the emotions they feel, the touchpoints they encounter. This is useful for alignment and empathy, but it stops short of the question that matters most for delivery teams: what should the service actually do?
A behaviour spec answers that question. It takes a single moment — not a whole journey — and specifies the service response in detail. What signals trigger it. What truth it relies on. What it does, what it never does, when it escalates, and how you prove it worked. This is the artefact that bridges design and delivery — the document that a product team, an agent trainer and a platform engineer can all work from without translation.
What a behaviour spec answers
For one moment, it makes these decisions explicit:
- 1.What situation are we in?
- 2.What should the service do to help?
- 3.What must it never do?
- 4.When does it escalate?
- 5.How do we know it worked?
Behaviour spec sections (recommended)
Moment definition
What's happening, and why it matters.
Triggers & signals
What evidence we use to detect it.
Truth contract references
Which facts we rely on, and confidence/freshness.
Intended behaviour
What the service should do (per channel, if needed).
Boundaries & stop rules
What we do not automate. When we hand over.
Fallbacks
What happens when data is missing, policy conflicts, or the customer is stuck.
Escalation
Who takes over, and what context gets passed.
Proof hooks
What we measure (moment outcome, not vanity metrics).
Why behaviour specs work where journey maps fail
Journey maps fail at the point of delivery because they describe without deciding. They show that a customer "feels frustrated" at stage three, but they never specify what the service should do about it under different conditions. Should it offer compensation? Route to a specialist? Show a self-serve option? What if the data is uncertain? Journey maps leave these questions to whoever happens to be closest to the platform at the time.
Behaviour specs succeed because they are testable. You can review a behaviour spec and ask: if signal X is present and truth Y is reliable, does the service do Z? If truth is missing, does it fall back correctly? If the customer is in a high-risk situation, does it escalate? These are questions you can answer before anything goes live — and questions you can audit afterwards through the four gates. That testability is what makes behaviour specs the natural artefact for cross-functional teams designing adaptive CX.
Example behaviours
Moment: Delivery delay
Behaviour: Acknowledge, give honest status with confidence, offer next-best actions (reschedule, compensation rules, escalation), don't overpromise.
Moment: Downgrade decision
Behaviour: Show options clearly, explain eligibility, simulate impact, allow self-serve, don't force a call.
Behaviour specs in practice
Teams use behaviour specs in three ways. In sprint planning, they replace ambiguous user stories with precise decision specifications — reducing rework and misinterpretation. In agent training, they provide clear guidance on what the service should do in specific moments, including escalation triggers and boundaries that agents can follow with confidence. In platform briefing, they give engineers and integration teams a spec they can work from directly, without waiting for design to translate a journey map into requirements.
The result is faster, safer delivery. Teams stop debating what the service "should probably do" and start working from a shared, testable agreement. As you progress up the adaptation hierarchy, behaviour specs become increasingly important — because the higher the autonomy, the more precise the specification needs to be.