An IT service desk is a retrieval problem wearing a headset. Somebody calls, an agent has a short window to find the answer a colleague already wrote down somewhere, and almost every number the desk is measured on is downstream of whether that lookup works. Handle time, first-line resolution, escalation volume, the caller's opinion of the whole IT function: all of it is decided in the moment the agent goes looking.
A large European public-sector organisation asked for a review of the internal IT service desk it had outsourced. Performance, process, governance, tooling and maturity were all in scope. The finding that outlasted the rest was the smallest item on the page.
There were two knowledge bases in use, and neither of them was authoritative. The supplier ran its own, the one its agents were trained on and reached for by habit. It was not being updated frequently and the review recorded it as outdated. The organisation had started keeping a second one, maintained by its extended user support team, updated regularly, open to every agent on the desk both to read from and to add to. That one was current, and the supplier was not using it frequently enough. It lived on the organisation's own document store, and it was not integrated with the service management tool.
So the agent on the call had a stale store, a fresh store nobody had built the habit of opening, and a ticket tool that pointed at neither.
The challenge
The cost of that arrangement is visible in the escalation figures. In one month inside the review window, 844 incidents were passed from the service desk to second and third level groups, roughly 20 percent of everything the desk logged that month. One contact in five left first line. Some of that is genuine specialist work. A material part of it is an agent who could not find, inside the time the caller would tolerate, an answer that existed in writing somewhere in the estate.
Two of the escalation patterns say the same thing from different angles. Monitoring-related incidents were routed almost as a class to the monitoring group, which reads less like triage than like a missing standing channel between that team and the desk. And a separately contracted second-level tier for the organisation's own applications, meant to absorb exactly this traffic, was assessed in the review as not having been effective.
The contract had anticipated the problem. It said the supplier would use the organisation's knowledge base to record the details of incidents and problems already resolved, and that this store would be maintained by the desk and made available to every resolver across the IT management organisation. That is the right design written down in advance. What the review found was two stores drifting apart, because a contract clause is a statement of intent and a knowledge base is a daily habit, and nothing in the tooling made the intended habit the easier one.
The organisation had also been running quizzes to lift agent knowledge of its own applications. Scores moved, barely, over roughly six months, even though the questions repeated and had been circulated beforehand. The review read this as a motivation problem and a local management problem, and both readings hold. There is a third. A quiz measures what an agent carries in their head, and agents carry things in their head in exact proportion to how badly the systems in front of them retrieve.
Underneath the knowledge stores, the same fragmentation ran through everything else. Only some incident models were present in the service management toolset, so classification leaned on the individual agent's judgement with suggestive assistance from the tool rather than on a rule everyone shared. Standard operating procedures existed as documents rather than as steps inside the tool. Some second and third level groups kept their own separate toolsets in parallel. Reporting came partly out of the telephony system and partly from documents assembled by hand, alongside a separate automated pull the organisation ran from the ticket tool itself. And the desk could be reached only by telephone or a group email address inside business hours, so every status question came back as another contact, answered by a person reading from whichever store they happened to trust.
Add it up and the record of how this organisation actually fixes things sat across a supplier store, an organisation store, a ticket tool, several parallel trackers and a set of hand-built reports. No one of those was wrong. Together they meant no query could be answered from one place.
The approach
The recommendation was deliberately unglamorous: one window for the agent. Integrate the organisation's knowledge base with the service management tool so that a ticket and the knowledge attached to it open together. Retire the ambiguity by making one store the place of record and getting the supplier to use it and update it, rather than asking two populations to keep two stores in step by goodwill. Move standard operating procedures and incident models out of documents and into the tool, so the process is executed rather than remembered.
Governance was recommended to match. A named knowledge manager, because a knowledge base with no owner decays exactly the way the supplier's had. An audit function checking process and service level adherence regularly rather than at contract review. A responsibility map drawn against the intended process and written into the next contract, so the ownership question has an answer before the next dispute rather than after it.
None of that is exciting, and all of it is the precondition for everything that came later. The current interest in machine learning inside service operations, including the early and cautious language-model pilots now being run on ticket deflection and answer suggestion, assumes a corpus. Point a retrieval-grounded assistant at this estate and it will confidently return the stale store, because the stale store is larger, older, better formatted and more thoroughly indexed than the accurate one. The model has no way to know which of two contradicting documents the organisation currently stands behind. That is not a model quality question. It is a data readiness question, and it is answered by ownership, lineage and integration rather than by a better retriever.
The same holds for the measurement. The escalation figure above came from a manual pull covering one month. Process mining over the ticket events gives that number continuously, alongside the thing the review could only infer: which categories consume the search time, which ones bounce back from second line, and which knowledge articles are opened immediately before a resolution rather than merely existing. That is the same event stream any later model deployment would train and be evaluated on. Our Platform work starts here, with the event trail and the ownership map, because a support assistant built without them inherits every ambiguity the desk already has and adds latency to it.
The outcome
What this engagement produced was a review: a current-state assessment, findings, and recommendations for the next contract and the next operating model. No integration was built in this phase, no store was merged, and the escalation share quoted here measures the problem rather than a fix. The organisation's own knowledge base was the better of the two on the day we looked at it, and being better is not the same as being authoritative.
The pattern generalises further than the desk it came from. Every organisation now planning to put a language model in front of its support knowledge has some version of this substrate underneath: a vendor corpus and an internal corpus that disagree, a ticket system joined to neither, specialist teams keeping private records, and no owner whose job it is to declare which document wins. The pilots that disappoint are not usually failing at language. They are answering correctly from the wrong store.
One window for the agent was the right recommendation then and it is the right precondition now, because the assistant is just another agent at the same desk, with the same short window, looking in the same places.