Fiscalizei
← Notes from the factory

How much it costs to not have a centralized knowledge base in your Service-Desk

When a Service-Desk operation doesn't have a centralized knowledge base, the cost doesn't show up as a single line in the budget. It hides inside average resolution time, inside how long it takes a new analyst to become productive, inside an SLA that only gets met because one specific person happens to be on duty that day. It's a real cost, just a distributed one, which is why it's the kind of cost most companies never actually add up.

In 2023, Gartner published a direct survey on exactly this problem: 47% of digital workers report difficulty finding the information they need to do their own jobs. It's not a motivation or competence problem on the team's side, it's a problem of where the knowledge lives. When the right answer sits inside one specific analyst's head, or scattered across emails, chat threads and personal notes, it's only available when that person is available.

McKinsey Global Institute arrived at a similar number through a different lens: in research on knowledge worker productivity, it estimated that around 1.8 hours per workday, nearly 20% of the work week, is spent just searching for internal information or trying to track down a colleague who might know the answer. In practical terms, it's as if out of every five people hired for a role, one spends the entire day just looking for answers, without producing anything else.

In a Service-Desk operation, that lost time has a specific address: the analyst who gets a ticket similar to one resolved last week, with no way of knowing that, because the fix was never documented anywhere searchable. They reopen the investigation from scratch. They test hypotheses someone else already ruled out. Sometimes they escalate to N2 a problem the Service-Desk itself already knew how to fix, except that memory never lived anywhere beyond the head of whoever solved it last time.

This pattern gets worse at three predictable moments in any team's life: when a key analyst goes on vacation, when someone resigns, and when the company hires someone new. In none of these three moments does ticket volume drop, but resolution speed does, because the knowledge that was propping up the SLA temporarily left circulation. It's that gap, between constant ticket volume and variable resolution capacity, that usually shows up first as an SLA breach and only later gets traced back to its real root cause.

It's possible to estimate this cost with a handful of numbers any Service-Desk manager already has on hand: how many tickets arrive per month, how long a ticket takes to resolve on average, how many people handle support today, and what that team costs per hour. Multiplying that by the share of time spent reprocessing information that should already be available, instead of applying a fix that's already known, produces an annual figure, not just a feeling that "the team is overloaded."

The answer to this problem isn't asking the team to document more. Documentation treated as a side task, done after the ticket is already closed, is the first thing to stop happening the moment the queue gets tight, which is exactly why so many corporate knowledge bases turn into graveyards of outdated articles. The structural fix is making the knowledge record be born from the act of resolving the ticket itself, and staying available both to the next human analysts and to the AI agents handling first-line support, the model we call the Company Brain.

A quick way to see this number for your own operation, without needing a formal audit, is to run the math with data you already have. We published an open calculator for exactly that, using these same five variables, showing in real time how much an operation is losing per year to this kind of inefficiency, and what the projected savings would be from centralizing that knowledge.