A service catalogue with five ways in tells you an organisation offers five ways in. The contract underneath it tells you which of the five it promised anything about. In this review those were not the same list, and the traffic followed the second one.
The desk counted a single month by channel. The telephone carried 3,666 contacts. Email carried 862. Someone walked over to a user's desk 23 times. A web route used mostly by people outside the organisation carried 54. The self-service portal, live the whole time and already scheduled for replacement, carried 15. Roughly 4,620 contacts in total, and three in a thousand arrived through the channel built for exactly that purpose.
The explanation written on the slide was usability: the portal was not user friendly, a better version was coming, and it would be promoted once ready. That reads the count as a verdict on an interface. Read the contract instead and it becomes a verdict on what the organisation had agreed to be held to.
The challenge
Six service levels were reported month by month, and five of them measure the telephone: speed to answer, talk time, abandonment time, abandonment rate, and the share of calls picked up inside thirty seconds. Three of the six were met and three were missed. Calls were answered in 17.42 seconds against a target of under 25. Talk time ran at 5 minutes 45 against a target under 5 minutes. Abandonment time ran at 1 minute 32 against a target under a minute. The sixth service level, one-call resolution, measures whether the call worked rather than how quickly it was picked up, and it sat at 47% against a contractual floor above 65%.
Email carried one commitment: an acknowledgement inside an hour for internal users, and thirty minutes for contacts from outside the organisation. No acknowledgement target existed for any other route in, at any priority band.
The portal carried nothing.
There were resolution targets, and they were channel-neutral: an hour at the top priority, then four hours, a day, a week, a fortnight. No figure was reported against any of them. Both trend panels carry a stamp instead of a line, saying no information is available. The reason is printed on the same page. The contract had been written against five priority levels and the ticket tool could hold three, so the only commitment that applied to every channel equally was the one nobody could measure.
The promise structure ran five, one, zero. The traffic came back 79.4%, 18.7%, 0.3%. A user with a broken laptop does not read a service catalogue; they pick the route that has historically produced an answer, and answering is a promise plus the machinery to keep it. The telephone had both. The portal had a page.
That is a design finding rather than a preference finding, and the same review contains the brief nobody acted on. Asked what an online view of their ticket would need to contain, the stakeholders interviewed ranked it themselves. First, who is working on it. Second, when it will be fixed. They rejected a bare status of "in progress", on the grounds that what they needed was to know where the ticket had landed so they could judge whether to escalate, and they asked to be told whether the fault affected anyone besides themselves. Every one of those is a commitment with a clock behind it, and none existed. Users were not told an expected response time or a target resolution time when they logged an incident, and were not told when their ticket changed.
Underneath, prioritisation was largely automatic: pre-set models in the tool suggested a priority from impact, and close to 95% of incidents came out low. A portal built on that record can display a status field honestly, and it will read the same for almost every ticket in the estate.
One detail makes that harder to argue with. The assisted desk was contracted to be open 53.5 hours in a week of 168, with no weekend cover, so for two thirds of the week the portal was the only door in the building that was open. It still took three contacts in a thousand.
The approach
The review's recommendation on channels ran the way these usually do: promote the new portal, add chat, and phone volumes will come down. It is stated as a direction and it is fair as one. Our reading is narrower, and it is a build rather than a slide.
Write the commitment before the interface. The contract already named four request types the desk was paid to fulfil: information or advice, a standard change, access to an application, and a password reset. Each has a definable finish line. Attach a time to each that the self-service path can actually hold, publish it, and report it beside the telephone numbers. A channel with no promise attached is a form with a queue behind it.
Then make status answer the question that was actually asked: who has it, whether work has started, whether anyone else is affected. The last of those means correlating an incoming ticket against every other open ticket, which is also how a major incident gets spotted early, and stakeholders here had separately complained that major incidents were not detected quickly enough. One capability, two problems.
Then fix the substrate, because none of it survives without that. The desk ran two knowledge bases in parallel. The supplier kept its own and worked from it, rather than from the one the contract named. The organisation kept that second base on a document site, maintained by a different support team, updated regularly and not connected to the ticket tool, and the supplier's agents were not reaching for it often enough. The review's own root cause for repeat escalation sits beside that: the known-error base was updated irregularly, so similar incidents kept going to the same second and third line queues. The interviewed group named text search across incident tickets as its first technology complaint. Every resolved ticket sat in a store whose text could not be searched.
This is where a review turns into something we sell. Retrieval-augmented generation over a store of resolved tickets is the least speculative thing anyone can do in support, and it needs no autonomy at all. It does need preconditions this estate lacked: one knowledge base declared authoritative, closure categories consistent enough to learn from, and lineage from an answer back to the incidents that produced it. The Platform work we do starts at data readiness rather than at a model, because a retrieval layer pointed at two competing stores returns two competing answers faster.
The assistants currently being sold into support are aimed at drafting knowledge articles from resolved tickets, and that is worth running here behind a human approval step, against an evaluation set built from the questions the desk actually receives. What makes one of them useful is records management, and that was overdue on its own merits.
The outcome
What this engagement produced was a review feeding a re-procurement: a counted baseline, a set of findings, a set of recommendations. No commitment was written, no portal rebuilt, no knowledge base merged, no request type automated in this phase.
The evidence deserves its caveats. The channel split is one month. The service levels are a three-month window, and two of the six headline figures do not survive their own label: one-call resolution is printed as a three-month average and then annotated as a single later month, and the share of calls answered inside thirty seconds is printed at 94.9% above a chart whose highest month in that window is 94.4%. Two exhibits on the same page report two different totals for the same nominal month, roughly 4,620 contacts in the channel table and 5,784 incidents in the volume chart beside it, and a third further on describes 844 escalations as roughly a fifth of the incidents logged, which implies a base nearer 4,200. Nothing separates a contact from a ticket from an incident, so every rate in the section rests on a denominator nobody wrote down.
None of that touches the ratio. Fifteen against 3,666 survives any denominator you choose, and the count was free: five rows already sat in the tool and nobody had put them next to each other. What the count measures is not enthusiasm. It is the order in which an organisation decided to be accountable, read back in traffic, one channel at a time.