A service can be governed well and delivered badly at the same time. When it happens, the governance is usually the reason nobody notices.
A large European public-sector organisation asked for a current-state review of its outsourced internal IT service desk before going back to market. The question was what the current contract was producing and what would have to be written differently into the next one. The part of the arrangement the review found in good order had nothing to do with the service. It was the way the relationship was run. The meeting structure was sensible and the people in the room were the right seniority. Ownership of the desk sat with one named party. A written responsibility split covered service level monitoring, staff planning, service delivery, changes to the agreed service levels and ad hoc reporting, spread across the client-side and supplier-side managers. A standard reporting pack was delivered. A management dashboard was in build.
Two of those held up less well on inspection than they looked. The responsibility split was documented but nothing kept it current, and the review recorded that people were unclear what the entries meant in practice. The reporting pack came partly off the telephone switch and partly out of somebody's hands. Hold on to that second detail. It explains most of what follows.
What did not hold up at all was everything those forums existed to oversee.
The challenge
The contract scoreboard split cleanly into two halves, and the split is the finding. The line between them does not run between good numbers and bad ones. It runs between the measures that carried a number at all and the measures that carried none.
Everything the telephone switch counted on its own was reported for the quarter, and it was a mixed result. Average speed to answer ran at 17.42 seconds where the contract asked for under 25 and the industry average sat at 30. Service level, the share of calls picked up inside half a minute, came in at 94.9 percent where the contract asked for 78 or better. The call abandonment rate was 2.06 percent where the contract tolerated up to 8. Those three sat comfortably inside their terms. Two others did not: average talk time ran to 5 minutes 45 seconds where the contract asked for under 5 minutes, and average call abandonment time reached 1 minute 32 seconds where the contract asked for under a minute, against an industry comparator of 25 seconds. Callers were being kept on the line longer and giving up later, and the switch said so.
Everything that needed a human being to agree a definition first was reported thinly or not at all. One-call resolution stood at 47 percent, where the contract set a floor of 65 and the industry average was 75, and the review also recorded confusion about how one-call resolution was being counted in the first place. The extra minutes of talk time were not turning into resolutions.
Then the two measures that describe whether the organisation is being served at all. Incident acknowledgement time and incident resolution time were each laid out across five priority levels. The contract carried a resolution target at every one of those five and carried no acknowledgement target at any of them. In both tables, in every one of those ten three-month average cells, the entry read as no information available. Nobody could say how quickly an incident was acknowledged, or how quickly it was resolved, at any priority, for the quarter under review. The service management tool could not hold the priority scheme the contract described, so tickets were filed against a coarser one and close to 95 percent of them landed in the lowest band.
Around the blank cells sat plenty that was measurable. In a single month, 844 incidents escaped first line to second and third level groups, roughly one in five of everything logged. A technical knowledge test was repeated with the questions announced in advance, and over roughly half a year the number of correct answers barely moved. Interviewed users described tickets passed between teams two or three times a month, incidents closed on the desk's own say-so rather than the user's, and knowledge concentrated in so few hands that one person's leave produced a backlog in a whole application area. Service improvement initiatives existed, and the review recorded that they were being driven by the client rather than by the supplier.
Set that beside the reporting. A pack assembled partly from the telephone switch and partly by hand will always be detailed about answering and silent about resolving, because the switch counts what it does automatically and everything else needs a human definition that somebody has to agree, write down and maintain. The forums met with the right attendance over a pack that could tell them, to two decimal places, how fast a phone was picked up, and could not tell them whether a single incident had been closed inside the time the contract promised.
That is not a governance failure in the usual sense. Nothing was skipped. The calendar held. The escalation routes worked. What the structure measured was whether the right people convened, and by that measure it performed superbly, which is exactly why an underperforming service can sit inside it for years without anything moving. A meeting hierarchy is the most comfortable place in an organisation for a weak service to hide, because it is the one part of the operation whose health is visible without anyone having to define an outcome.
The approach
The recommendations followed from the gap rather than from the forums.
Put agent utilisation into the next contract as a measured commitment, because it is the productivity measure the current agreement never carried and the one that moves cost per incident. Separate the roles: a dedicated incident manager and a problem manager to work against the supplier's service desk manager, so the contract manager is freed to hold improvement and overall performance rather than day-to-day traffic. Add a knowledge owner, because the desk was running against two knowledge bases with no single party accountable for either. Add an audit function to check process and service-level adherence on a regular basis, since the review found no quality checks and no accountability attached to an individual incident. Rebuild the responsibility matrix on the processes the next contract will run rather than the ones the last one described, and put it inside the contract rather than beside it.
None of those were implemented in this phase. They are recommendations written into a re-tender, and the honest description of what the engagement produced is a set of findings and a shopping list for the next negotiation.
The part worth carrying forward is what would replace the hand-assembled pack. The ticket system already holds an event for every state a ticket passed through: raised, categorised, assigned, reassigned, escalated, resolved, closed, reopened. Process mining over that log answers most of the questions the pack could not. How long a ticket waits before anyone touches it. How many hops it takes before it lands with someone who can close it. Which categories reopen. The ratio of tickets closed by the desk to tickets closed after a return trip. None of that requires a new definition to be agreed in a meeting. It requires reading data the tool is already writing, with lineage back to the ticket so any figure in the pack can be opened and challenged.
That is the difference between a pack and an instrument. A pack is a claim. An instrument is a claim with its records attached, and it changes the character of the meeting: the forum stops receiving a summary and starts interrogating a source. The Platform work we do starts at exactly that point, because the cheapest improvement available to most outsourced service relationships is not a new supplier, it is making the existing one's own event data legible to both sides.
The outcome
The review delivered findings, a target operating model and design principles for a new agreement. No service level moved during it. Anyone reading a percentage above should read it as a measurement of the state the desk was in, not as an improvement anybody achieved.
The lesson generalises past IT service management. Wherever an organisation buys an outcome and manages it through a committee, the committee's health and the outcome's health are separate variables, and only one of them is easy to observe. Attendance, cadence, minutes and escalation paths can all be excellent while the thing being overseen degrades quietly, and the better the forum functions the longer that can continue, because a well-run meeting feels like control.
The test is slightly rude. Take the last four packs your forum received and ask what changed because of any of them. If the honest answer is that they were noted, the forum is a reporting ritual in a decision-making costume, and its excellence is a cost rather than a comfort. Our Consult engagements open with that question before anything technical, because the answer decides whether better data gets used or merely filed.