Interaction Continuity
A customer gives their account number to the IVR. Ninety seconds later, the agent asks for it again.
That’s not a training problem. That’s not an agent being lazy. That’s two systems that never talked to each other, both doing exactly what they were built to do, in isolation.
I want to name the thing that’s actually broken here: Interaction Continuity.
What it means
Every touchpoint in a CX journey does two jobs. It has to accept information coming in, and it has to produce information going out. The IVR takes an account number in. It needs to hand that account number out, to the agent desktop, to the chatbot, to whatever comes next in the journey. Skip either half and the journey breaks.
Most CX design only thinks about the first half. Build the IVR to collect what it needs to do its job, ship it, move to the next project. Nobody asks what the IVR owes the next system in line. So the information dies at the handoff, and the customer becomes the integration layer. They carry their own account number, their own issue description, their own frustration level from system to system, because nothing else will.
Why this is expensive
Every repeated question is a tax. A customer who has to repeat themselves has just learned the company doesn’t know who they are. That’s worse than a slow resolution. A slow resolution feels like a hard problem. A repeated question feels like nobody was listening the first time. Contact centers already measure the damage without naming the cause: first contact resolution drops, handle time climbs while the agent reconstructs a conversation that already happened somewhere else, and CSAT eats the loss at the end.
The two-way test
The check I’d apply to any system in a CX stack: what does it consume, and what does it produce. An IVR that captures account context but doesn’t pass it downstream isn’t finished, it’s half a system pretending to be a whole one. A CRM that stores history but doesn’t expose it to the channel the customer is in right now is a filing cabinet, not part of the journey.
Where this gets hard: deterministic versus conversational
For an IVR, continuity is a solved design problem. The system is deterministic. Every path is known in advance. You can enumerate exactly what it takes in (account number, DTMF selections, an intent code from a menu tree) and exactly what it owes the next system, because someone wrote the menu. There’s a finite list. You build it once and it’s correct or it isn’t.
Get Mryanaz’s stories in your inbox
Join Medium for free to get updates from this writer.
An AI agent breaks that assumption completely. The customer isn’t picking from a menu, they’re talking. They might give their account number in the first sentence or the fifth. They might mention a second issue halfway through that has nothing to do with why they called. The agent has to extract meaning from open, unstructured conversation, and there’s no fixed schema telling it what’s coming in.
That means someone has to decide, on purpose, what’s critical to carry forward. Not everything said in a five-minute conversation matters to the human agent who picks it up next. Some of it is critical: the resolved issue, the promised follow-up, the thing that made the customer angry. Some of it is noise. An IVR never has to make that judgment call because the call was made for it at design time, in a menu tree. An AI agent has to make it live, on every single conversation, and get it right every time. That’s not a configuration task. That’s a design problem with real stakes, and it doesn’t stay solved just because it worked in yesterday’s test set.
The handoff summary problem
Say the AI agent gets it right and identifies what matters. There’s a second problem right behind it: how does that information actually reach the human agent or the next AI agent in a form they can use in the four seconds they have before picking up the call?
Dump the full transcript and you’ve handed the agent a wall of text to skim while the customer is already talking, which recreates the exact friction continuity was supposed to remove. Over-compress it into a one-line summary and you’ve thrown away the detail that mattered, the thing the customer already explained once and now has to explain again anyway. The summary itself is a design surface, not an afterthought. Concise, but not lossy. Fast to read, but not stripped of the one fact that made this call different from a thousand others.
This is the part almost nobody budgets for. Building the AI agent gets the attention. Deciding what it hands off, and how that handoff gets displayed to the next human in the chain, gets treated as a UI detail instead of the thing that determines whether the customer actually feels continuity or just watched it fail one step later.
Why this is a testing problem, not just a design one
An IVR’s handoff is a finite list, so you can test it exhaustively and be done. An AI agent’s handoff is combinatorial: a different set of critical facts every conversation, extracted live, summarized live, handed off live. There’s no fixed path to walk once and mark complete. That’s the same coverage gap that shows up everywhere else AI meets CX: manual testing catches the handoffs your team thought to check and misses the ones nobody imagined, which is most of them. Automated testing that involves the widest possible set of critical facts means hundreds of scenarios need to be tested. Potentially thousands.
Designing systems to share the right information and proving they actually do it, on every conversation, after every model update, are two different jobs. Most companies have only done the first one, and only for the easy, deterministic half of their stack.
The point
A customer shouldn’t be the thing holding a CX journey together. The systems should be. Every interaction owes the next one what it learned, and until someone tests that the handoff actually happens, that’s a hope, not a design.
