The portal was live. It had been live long enough to have a replacement version on the way. In the month the review counted, it took fifteen contacts.
The same month, the telephone took 3,666. Email took 862. Someone walked over to a user's desk 23 times. A fifth route, a web channel used mostly by people outside the organisation, took 54. Roughly 4,620 contacts in total, and 98.9% of them came from inside. Self-service was 0.3% of the month, which rounds to nothing and reports as a channel.
That is the finding, and it is worth being precise about what it means. A channel that exists and is not used is not a channel. It is a line item: something with a name in a service catalogue, an owner, a roadmap slot and a replacement project, and no traffic. Every governance conversation treats it as one of five ways in. Every user treats it as none of them.
The challenge
The reason written on the slide was usability. The portal was not user friendly, a new version with more functionality was expected, and the plan was to promote it to users once it was ready. Build, then market. That sequence assumes the channel failed on its own terms.
It did not. It failed against the alternative. On the same set of service levels, the desk answered the telephone in 17.42 seconds on a three-month average, against a contractual target of under 25 seconds. A user with a broken laptop is choosing between typing a description of a problem they cannot describe, and pressing one button to reach a person in under twenty seconds. The portal is not competing with its own previous version. It is competing with seventeen seconds.
Behind the portal there has to be something to answer with, and that is where the review is most useful. The desk was running two knowledge bases at once. The supplier kept its own, which was not being updated often and was out of date. The organisation kept a second one, maintained by a separate support team, held in a document site and not connected to the service management tool. The supplier's agents were not using the organisation's base frequently enough, and the review recommended integrating it with the ticket tool so an agent would have a single window rather than two.
Read that as a self-service question rather than an agent question. Self-service is a knowledge product with the agent removed. If the people paid to consult the knowledge, sitting in front of a screen all day, do not consult it, a user under pressure will not find it, trust it or follow it. There is a related signal in the same review: knowledge quizzes were run for the desk agents, and their scores took close to six months to show a small improvement even though the questions were repeated. The knowledge problem was real and it was measured.
The second precondition is status. A portal beats a phone queue at exactly one thing, which is telling you where your ticket is without asking anyone. The review records that users were not told the expected response time or the target resolution time when they logged an incident, and were not told when the ticket subsequently changed. The portal did carry an online status check, and users rang the desk for status anyway. A status view with no committed time behind it, and no message when the state changes, answers a question nobody asked. The question is when. Underneath, prioritisation was largely automatic, the tool suggested a priority from impact, and close to 95% of incidents were logged low. A ticket that carries no commitment back to the person who filed it is a form, not a channel.
The approach
The review read the desk through performance, processes, governance and reporting, and it set every service level against three references rather than one: the market, the contract, and what was measured. The recommendation on channels followed the usual line, that heavier use of the portal along with a chat option would bring phone volumes down. That is a direction, and the review states it as one.
Our reading of the same evidence is narrower and it is a build, not a slide. A channel becomes real when three things are true at once, and the review shows all three failing together. There has to be something to answer with, which is a knowledge base with one owner, connected to the ticket tool rather than sitting beside it. There has to be something to show, which is a status a user can see without ringing to ask. And there has to be something to gain, which means the self-service path has to be faster than the alternative for the specific request types it covers, not on average.
That last point decides the scope. Not everything should be self-served. The month's volume needs to be cut by request type before anyone designs a page, and the material for that cut already existed in the ticket log. Process mining over the incident and request records gives the repeat categories, their true handling cost and their rework rate, without a workshop and without asking anyone to estimate. Password resets, access requests and standard changes were already named in the contract as request types the desk handled. Those are the candidates for straight-through processing, and they are also the ones where a portal that fails halfway is worse than a phone call.
The rest of the pipeline follows from there. Ticket text is the training data for routing and for repeat detection, which means the model deployment question is really a data readiness question: whether the closure categories are consistent enough to learn from, and whether lineage from an article back to the incidents it closed can be reconstructed at all. The current wave of cautious language-model pilots in support is aimed at drafting knowledge articles from resolved tickets, and it is worth running, but only behind a human approval step and only once one knowledge base has been declared the real one. A drafting model pointed at two competing bases will produce two competing answers faster.
There was more work the desk itself could not absorb. In the same counted month, 844 incidents went to second and third line, roughly 20% of those logged, and one-call resolution was reported at 47% against a contractual floor above 65%. A portal does not deflect work that the desk itself cannot resolve. It deflects the narrow, repeated, well-specified band underneath that, and the size of that band is a measurement nobody had taken.
The outcome
What this engagement produced was a review: a counted baseline, a set of findings and a set of recommendations, feeding a re-procurement. No portal was rebuilt, no knowledge base was merged, no request type was automated in this phase. The channel numbers are one month. The service levels are a three-month window. The trend charts around them are published as pictures whose values cannot be read back, so the counts here are the counts, and nothing has been interpolated between them.
What would be done differently now is mostly instrumentation. The 0.3% was found by counting a month by hand. It should be a standing measurement, alongside the cost of each channel per contact and the completion rate of anyone who starts a self-service journey and gives up partway. That last number is the one nobody had. Fifteen successful self-service contacts tells you what happened. It does not tell you how many people opened the portal, tried, and reached for the phone, and the difference between those two numbers is the entire design brief.
Our Platform work starts at that measurement, because a channel funded without it is a channel funded on hope. The cheapest finding in this whole review was free: the count was already in the tool, and nobody had put the five rows next to each other.