2026-09-15
Nural Choudhury
A connected experience breaks at the seam between teams, not between channels, so building one is an operating-model problem disguised as a design problem.
Most organisations already own the technology to carry a customer’s identity and progress across channels. What is usually missing is a single team, or a single number, that owns the journey across the boundary where it breaks.
A customer journey that keeps failing at the same handover, no matter how many times a team ships a fix inside its own channel, because the fix never touches the boundary where the customer loses their place.
Get two teams, each owning one channel, to design for a journey neither owns alone, and agree on the one measure that makes a fix in one channel count as a win only when it also helps the other channel.
A journey mapped by seam rather than by channel, an instrumented handover with a completion rate and a re-entry cost you can track, and a shared measure on both teams’ scorecards.
Map the customer’s journey across every channel and device it touches, then mark each point where the customer crosses from one to another. Mark it as a seam, not a channel boundary: a seam is the moment a customer’s context has to survive a handover.
A connected experience runs through four seams.
| Seam | What breaks here |
|---|---|
| Channel handover | The journey restarts because no session or task state travels with the customer from one channel to the next |
| Identity | The organisation cannot recognise the same customer across channels, because each channel holds its own identifier, so history, status and personalisation all reset |
| State | The customer’s progress, a saved basket, a submitted claim, a part-finished form, does not carry over, so a device or channel switch loses the position already reached |
| Operational ownership | Each team behind a channel optimises its own metric, so a fix that improves one channel’s number can create the exact gap the next channel then has to absorb |
Identity is the precondition the other three seams depend on. You must establish a stable identifier that survives a login, a device switch, and a channel change before any system downstream has somewhere to attach the customer’s context. Without it, state and handover both default to zero rather than to an exception.
Every channel entry point must carry a resume path, not only a start path. A returning customer arriving mid-journey needs a banner naming the last step reached, prefilled fields rather than blank ones, and a route back into the flow they left, not the generic homepage.
Log a stable, cross-channel identity-resolution event at every handover, not a channel-specific session ID alone. Track handover completion rate, the share of journeys that continue within a set window, such as thirty minutes, against those that abandon and restart. Track re-entry cost, how many fields, steps or pieces of context a customer has to repeat, and attribute drop-off to the seam it crossed rather than only to the channel that received the customer.
A channel-scoped funnel is blind to the seam itself, no matter how healthy each channel’s conversion rate looks.
Pick the single highest-volume seam in the journey, agree the one metric both teams behind it will share, and put it on both scorecards before redesigning a single screen. The organisational condition comes first, and the interface work follows it.
I do not open by asking the channel teams to work together. I open by asking each of them what they are measured on, because that answer, and not the org chart, is what stops the journey from being designed as one thing.
What I hand over is the seam map and the question of what breaks at each one. What I keep is the decision on which seam to fix first, because ceding that to whichever team argues loudest reproduces the same local optimisation the seam already suffers from.
I check the shared dashboard, not the team standups, because the shared numbers are the only place a fix that helps one channel and hurts the other becomes visible before it ships. If a team cannot tell me what its proposed fix does to the seam’s completion rate, it has not finished the work yet.
The conversation that goes wrong: two teams agree the seam is a problem, then each proposes a fix that improves its own number and quietly assumes the other side will absorb the cost. I ask one question before either team builds anything: what happens to your number if we ship the other team’s fix first? A team that cannot answer has agreed to discuss the seam, not to share it.
When the two teams’ metrics genuinely conflict- a deflection target on one side against a completion target on the other- I do not average them or invent a third number nobody recognises. I put the shared measure above both of them on the scorecard, so a local win that worsens the shared number reads as a loss even while the local metric still looks good.
I know a team has got it when it proposes a change to its own channel and, unprompted, names what that change does to the seam’s completion rate. That is when I can stop sitting in the room.
Take a customer who starts a return in an app, then phones support because the return has stalled. On the call, they have to re-explain what they already told the app, because the call centre’s system holds no record of it.
Mapped by seam rather than by channel, the failure sits at the handover between the app and the call centre, not inside either channel’s own design. The app team’s return-completion rate looks unaffected, and the call centre’s average handling time looks unaffected, so neither team’s own dashboard shows the loss.
Instrumented at the seam, the picture changes. A cross-channel identity-resolution event fires when the customer calls, a stalled-return flag from the app attaches to the call, and re-entry cost drops from four repeated fields to zero. Both teams now see the same completion figure for the return, instead of two separate, locally healthy ones.
A journey map that names every seam changes nothing on its own. I have watched a well-mapped journey sit in a slide deck for a year because naming a seam isn’t the same as moving ownership of the metric across it. The map is a diagnosis, not a fix.
Most connected-experience work covers the customer moving forward: browse, add to basket, check out on another device. It rarely covers the customer who cancels, complains or returns, because those paths cross more seams and expose more of the organisation’s fault lines. Continuity that only survives the happy path is not continuity; it is a demo.
A customer data platform or a new CRM is sold as the fix for fragmented identity, and it can genuinely close the identity seam. It cannot make two teams agree to share a metric, because that is an operating change, not a configuration option. I have seen the platform ship and the seam stay exactly where it was, because nobody changed who is accountable for the number on either side of it.
Omnichannel describes the strategy, integrating every channel around the customer. A connected experience is the outcome you can test for: whether the customer’s context survives the handover.
Is a connected experience the same as a consistent one? No. Consistency means channels look and sound alike. Continuity means a channel knows what happened on the previous one, and a journey can be visually consistent while still losing the customer at every handover.
Identity resolution. Without a stable identifier across channels, state and handover both fail by default, because nothing downstream has anything to attach the customer’s context to.
Track handover completion rate within a fixed window, re-entry cost in repeated fields or steps, and whether drop-off is attributed to the seam itself rather than only to the receiving channel.
Nobody, by default, which is the problem it exists to solve. It needs a shared measure that the teams on either side of each seam are judged against together, not a single owner layered on top of teams still measured separately.
| Fact | Detail |
|---|---|
| Origin of the term ‘omnichannel’ | Coined in an IDC Retail Insights report published September 2010; brought to a business audience by Darrell Rigby’s “The Future of Shopping”, Harvard Business Review, December 2011 |
| Omnichannel vs multichannel | Multichannel runs each channel as an independent, separately managed asset. Omnichannel integrates them so a customer’s context carries across one continuous journey |
| The expectation gap | 79 per cent of customers expect consistent interactions across channels and departments, yet 55 per cent say it feels like dealing with separate departments rather than one company (Salesforce, State of the Connected Customer, sixth edition, 2025) |
| Seam and boundary framing | Builds on the frontstage, backstage and boundary-line structure set out in Service Blueprints (Shostack, 1984; refined by Kingman-Brundage, and by Bitner, Ostrom and Morgan, 2008) |
A service blueprint is a diagram that maps what a customer experiences against the staff actions and systems that produce it, on one shared timeline.
Read it
Task analysis is the systematic study of how people currently perform a task, breaking it down into the steps, decisions and knowledge each one requires.
Read it
A team isn’t misaligned because it lacks a vision; it is misaligned because the cadence that surfaces disagreement before it hardens doesn’t exist.
Read it
Mobile-first design starts with the smallest, most constrained screen and builds upward, rather than shrinking a finished desktop design to fit.
Read it