Every self-service business case I am asked to review has the same arithmetic in it. Contacts per month, multiplied by a deflection percentage, multiplied by a cost per contact. Two of those numbers come out of a system and are hard to argue with. The middle one is assumed, and the middle one is the entire case.
The assumption underneath it is that people use a channel because it exists. It is cheap to make, it survives most business cases because nobody measures it afterwards, and it is wrong in a repeatable way.
I keep a current-state review of an outsourced IT service desk at a large European public-sector organisation for this argument, because the organisation had already run the experiment. The channel had been built and made available. People carried on ringing the desk.
The channel that existed and the channel people used
Contact with this desk arrived by telephone and by a group email address, staffed during business hours. Alongside that, a self-service portal let a user look up the status of their own incident without speaking to anyone. That is what a deflection model books a saving against: a status enquiry is the cheapest, most repetitive, most obviously automatable contact a service desk handles, and the first thing anybody proposes to take off the phones.
It was available. It was not adopted. The review says so in one line, without drama, as a description of current state: the online status check exists, and users prefer to call. They were not being difficult. The two channels were not answering the same question.
A status page answers where the ticket is. It renders a state value some system wrote: received, assigned, in progress, pending. A telephone call, in the mind of the person making it, asks a different question, which is when this ends and whether anybody competent is on it. The portal returned the first answer to a population that wanted the second.
You can see the gap in what the people running the service asked for when invited to design a replacement. Their list for an online tracking system reads: the current status, the team investigating, reassurance that the incident is actually being worked, notification when more information is needed, and whether the fault is hitting more people than just them. One ranked it, putting who is working on it first and when it will be fixed second. Another said such tracking would be useful in the way courier tracking is useful, then qualified it: more than a simple status like "in progress", because people want to know where it has landed in case the situation needs escalating.
Only the first of those is a state field. Every one of the others is a commitment.
The same failure, three more times, in the same building
The email address existed. Stakeholders rated it low and were precise about why: response time was poor, and a user's description of a fault sometimes did not match its cause, so the exchange became a chain of clarifying messages and a slow resolution. Adding an asynchronous channel to a process that needs clarification does not deflect the contact. It stretches it.
The satisfaction survey existed. It went out after closure and came back from about one user in ten in the area that quoted a figure, which the stakeholder who quoted it dismissed as too thin to shape either a positive or a negative view. The suggested fixes are instructive: one asked for a direct call to the user instead, another said it would work only as one click and one question, with a reason if the answer was no. Both reduce what the channel asks of the user rather than advertising it harder.
The knowledge base existed, maintained, updated regularly, open to every agent for both looking up and adding, and it was not being used often enough by the people it was built for. It sat on a separate document site with no integration into the ticketing tool, so an agent with a caller on the line had to leave the ticket and search elsewhere. That cost, measured in seconds, determined adoption. Nothing about the content did.
Three channels, three sets of disappointing usage, and in each case the explanation sits in the design of the interaction rather than in the awareness of the user.
Why this matters more when you are automating than when you were not
All of that would be an ordinary service design observation if we were still only building portals. We are not. The straight-through processing cases crossing my desk this year, and the first cautious language-model pilots alongside them, propose to answer the user directly and count the contacts that never reach a human. The deflection percentage has moved from a line in a business case to the primary benefit of the programme. That makes the distinction load-bearing in three places.
The first is the target. If you point an automated responder at status enquiries because they are the highest-volume, lowest-complexity contact you have, you have chosen the contacts most likely to bounce. The user rings anyway, the automated response has cost you a step, and measured deflection comes in under the modelled figure. The contacts worth automating are the ones where a complete answer exists and can be given, not the ones where a state value exists and can be displayed.
The second is the training data, and this is the part that quietly ruins the model. Tickets record what the desk did, not what the user wanted. Here, incidents were categorised on the judgment of whoever took the call, with no quality checks or audits running on them at all, and tickets were misrouted between teams two or three times a month by each group. Any classifier learning from that field learns the desk's guesses rather than the user's need.
The third is measurement. Process mining over the actual contact paths would have shown this organisation what no dashboard did: how many status calls arrived after that same user had already opened the portal, how long they waited between the last update pushed to them and the next time they rang in. That is the honest baseline for a deflection case. The count of channels you offer is not a baseline. It is an inventory.
- Around 10%
- Response rate quoted for post-closure satisfaction surveys in one area
- 2 to 3 times a month
- Tickets misrouted between teams, by each team
- Not often enough
- Agent use of the knowledge base built for them
- Prefer to call
- User behaviour where an online status check already existed
What the users were telling us
The portal was there and the phone was there, and people chose the phone. They were not being irrational. Only one of the two could tell them when their problem would end.
The stakeholder who summed it up best was not talking about technology. Asked which channels the future desk should carry, they said to give the user options, because different generations prefer the telephone, instant messaging or email, and to let the user decide initially, moving them elsewhere only when it makes more sense.
That inverts the usual sequence. A deflection programme starts from the channel it wants people to use and works backwards to persuasion. This runs the other way: start from what people do, work out what the chosen channel supplies that the others do not, then supply that thing everywhere.
Applied here, the answer is not difficult. What the phone supplied was a person who could be asked when, and pressed if the answer was unsatisfactory. Give the caller an expected resolution time and hold yourself to it. Push updates outwards on a schedule rather than waiting to be asked. Name the group that has the ticket. Say when the next update comes. Each is a commitment the organisation has to be willing to make, which is why they are harder than building the portal was, and why the portal got built first.
A self-service channel is a promise about answers, not a location for information. Where an organisation will not make the promise, no amount of availability substitutes, and any model of adoption built on availability alone will overstate itself.
The test I would run before signing the case
Take the top contact types by volume. For each, write the question the caller is asking in their words rather than yours. Then ask whether the proposed channel can answer it completely, without a handover, and whether the organisation is prepared to be held to the answer. Anything failing either test stays in the human queue and out of the savings line.
That is cheap, it needs no data science, and it is the first thing we do on a RealAI Platform engagement before a single automated response is designed. It usually cuts the deflection number in the draft case, and it makes the remainder one you can defend after go-live, a trade most sponsors take once they have watched a portal go quiet.
Observations are as recorded in a current-state review of an outsourced IT service desk at a large European public-sector organisation, drawn from its current-state analysis and the stakeholder interviews run alongside it. That review produced findings and recommendations ahead of a re-sourcing decision, not delivered results. Reading them as a lesson about channel adoption is ours.
“The portal was there and the phone was there, and people chose the phone. They were not being irrational. Only one of the two could tell them when their problem would end.”
Get in touch
Put RealAI’s applied-AI team on your hardest data problem.
We help enterprises move from pilots to production: sovereign models, governed data, and agents you can audit. Start with a value-first assessment.