Learn · track
Conversations, journeys and AI
One customer across many channels: journeys that branch, support as a system, automation and AI agents that actually resolve things.
- 1Omnichannel is an identity problem, not a channel countThe difference between multichannel and omnichannel is not how many channels you support. It is whether the customer has to repeat themselves — and that depends on how you recognise one person across many addresses.
- Model each customer as one record that owns several identifiers — emails, phone numbers, app IDs — each with its own verification and consent state.
- Link records with recorded evidence and a way to undo it; never merge two people on a fuzzy match.
- Count repeat contacts about the same issue on a different channel. That number shows how often customers must start again.
- 2Conversational marketing, minus the hypeA useful definition has to exclude something. This one — the customer's reply changes what happens next — excludes most of what gets sold under the name, and tells you how to staff and measure the rest.
- Call it conversational only if a customer's reply changes what happens next. Otherwise it is a broadcast; measure it as one.
- Before launch, decide who answers, in which hours, how fast, and what customers are told outside those hours.
- Set a frequency cap across all journeys, never mix promotions into service messages, and say clearly when a customer is talking to AI.
- 3Designing a journey that actually branchesMost 'journeys' are sequences with a delay between steps. Four decisions, made before any copy is written, turn one into something that responds to what the customer actually does.
- Define what ends the journey — success, complaint, opt-out, handover — and make every exit cancel messages already queued.
- Give silence explicit branches: undelivered, unread and read-without-action each need a different next step.
- Set one frequency cap per person across all journeys, owned by someone above the teams that build them.
- 4The support queue as a system, not an inboxOwnership, state, two clocks, routing that survives staff changes, and the ways messaging channels break email-era ticketing — the machinery that separates a support function from a shared mailbox.
- Track work items — one per customer problem — rather than messages, and give each exactly one visible owner.
- Keep two clocks, the customer's and the team's, and report both alongside time to resolution.
- Measure repeat contact within seven days of 'resolved' to learn whether resolved actually means solved.
- 5Containment is not resolution, and optimising the first destroys the secondA support agent can post excellent containment numbers while making customers angrier. The metric that separates the two is uncomfortable and worth adopting.
- Never report containment alone. Pair it with resolution: contained conversations where the customer did not return within a set window.
- Offer a human early and hand over the full conversation, so nobody has to repeat themselves.
- If the real goal is saving money, say so and measure cost per resolved issue, not per contained chat.
- 6Measuring a conversational programme without fooling yourselfA method: choose one outcome, build a permanent holdout, instrument the funnel, and be honest about what the numbers cannot settle.
- Pick one business outcome — paid, booked, renewed or resolved — and judge the programme on that alone.
- Before launch, randomly hold back a small share of eligible people who get nothing, and keep that holdout permanently.
- Report outcomes against messages sent, not delivered, and watch unsubscribes, reply tone and repeat contacts every week.