The customer is not annoyed by one slow step. They are annoyed by having to ask twice.
Customer experience breaks at the joins: between channels, between systems, and between the person who took the request and the person who fulfils it.
The context did not travel with it.
Shape of a request's history, illustrative. Nothing on this page is read off this drawing.
Four failures the customer actually notices.
None of these is fixed by a better front end. Each is a break between a customer-facing surface and the operation behind it.
They have to repeat themselves
The request arrived by one channel and is being handled in another, and the context did not travel with it.
Nobody tells them anything until it is done
The work is progressing normally. From outside it looks like silence, and silence reads as neglect.
The answer depends on who they reach
Two people give two answers, both acting in good faith from different information.
A promise is made that the operation cannot see
Someone commits to a date, the commitment lives in a message, and the team fulfilling it never receives it.
Three costs, and one of them is invisible in your own reporting.
Two of these three land in figures somebody in your organisation already reads. The third is drawn below that line, because it does not.
Repeat contacts inflate everything
The same request arrives three times. Volume looks like demand, and the team is sized for a problem the process created.
Recovery costs more than doing it right
A discount or a goodwill gesture to fix an experience failure is the most expensive way to resolve something that was working correctly underneath.
Your own numbers look fine
Each department hits its target while the end-to-end journey fails, because nobody measures the join.
The complaint is about trust, not speed
Once a customer has been told two different things, they check everything, which is permanently more expensive to serve. That behaviour does not reverse when the underlying process is fixed, which is why the cost of this failure outlasts the failure itself.
The journey afterwards.
Five moments in one request, each drawn twice. On the left is what the customer meets today. On the right is what they meet instead, in the same order.
- Context stops at the channel boundary.
- The customer chases for status.
- Answers vary by who is asked.
- Commitments live in messages.
- Each team measures its own step.
- The request carries its history, whichever channel it moves to.
- Status is pushed at the points where waiting begins, not on request.
- One authoritative source per question, so the answer is the same from anyone.
- A promise creates a visible obligation in the system that has to fulfil it.
- The end-to-end journey is measured, so the join is visible.
Where to intervene, judged by what the customer notices.
The temptation is to start with the most visible surface, because that is what gets complained about. The joins behind it are usually cheaper to fix and produce more of the improvement.
- What you could fix
Context not travelling between channels
What the customer noticesHaving to repeat themselves, which is the most common complaint in this category
- Cost to fix
- Moderate. An integration and a shared record
- Order
- First
- What you could fix
No proactive status at waiting points
What the customer noticesSilence, which they interpret as nothing happening
- Cost to fix
- Low. A trigger and a message
- Order
- First, often the cheapest visible win
- What you could fix
Inconsistent answers between people
What the customer noticesThat your organisation does not know its own position
- Cost to fix
- Moderate. Source ownership, not technology
- Order
- Second
- What you could fix
Commitments invisible to the fulfilling team
What the customer noticesA missed promise, which costs the most trust
- Cost to fix
- Moderate to high, depending on the systems
- Order
- Second
- What you could fix
Redesigning the customer-facing interface
What the customer noticesA nicer experience of the same underlying problem
- Cost to fix
- High
- Order
- Last, and often unnecessary once the joins work
The final row is where these projects usually start. It is the most expensive intervention and the one most likely to leave the actual complaint unaddressed.
How the work runs, step by step
Follow one real request end to end
One actual case, across every system and person that touched it. The map that matters is the one including the phone call nobody logged.
Find where context is dropped
Every point where a person re-establishes something the organisation already knew. Those are the joins.
Fix the cheapest visible failure first
Usually proactive status at a waiting point. It is small, the customer notices immediately, and it buys credibility for the larger work.
Make context travel
A shared record the customer-facing surfaces read from and write to, so the history moves with the request.
Measure the journey, not the steps
End to end, from the customer's first contact to resolution. Departmental measures will keep looking healthy either way.
What this connects to, and who builds it
Five pages sit next to this one, and each of them owns a different part of the same problem.
- Answering the question itselfCustomer Support AutomationA repeated question with a known answer is customer support automation.
- Making systems exchange contextAI IntegrationThe shared record and the connections into it is AI integration.
- Orchestrating the sequenceAI Workflow AutomationTriggers, status and handoffs across systems is AI workflow automation.
- The customer-facing surfaceUI/UX and Product DesignWhere the interface itself genuinely is the constraint, that is UI/UX and product design, and this page argues it is rarely first.
- If the promise is missed in the fieldField and Fleet OperationsWhere the commitment fails because a technician is running late, that is field and fleet operations.
Where this work has been done
Customer-facing product work and time-critical coordination are the two disciplines this depends on, and both are in delivered Viithiisys work.
Conscious Chemist, a customer-facing product experience
A documented 38% faster product-question response, in a product real customers use every day.
Relevant here because it concerns a real customer interaction rather than an internal process: the question arrives, the answer has to be right, and the person asking is deciding whether to buy while they wait.
Milo, coordination under time pressure
A driver-facing system where a coordination delay has an immediate operational cost.
Relevant to fixing joins rather than surfaces.
Vizitor, in daily multi-site use
In production at scale: 500+ workplaces across 15+ countries.
Questions we are actually asked
Pick a topic, or ask us directly. We answer every inbound within one business day.
Still have questions?
Talk to a senior engineer, not a bot.
Pick one recent complaint and follow it backwards.
Whatever the customer said, the cause is usually a join rather than a step. Tell us the case and we will tell you whether this is a journey problem, a support problem or a product problem.