The loudest-customer algorithm

Without a request queue, the loudest request gets served. Emails stack, walk-ups interrupt, and a quiet customer who asked politely on Tuesday is invisible by Friday. The least satisfied customers are often the least audible; they leave without complaining.

One door, one queue, one owner

The two failure modes of service desks

When organisations install a desk, they tend to over-correct into one of two modes. The bureaucratic desk demands ticket numbers before help. The performative desk shows satisfaction dashboards and a knowledge base nobody maintains. A desk exists to convert requests into a visible queue so staffing and priorities become measurable.

A desk makes the queue visible

Insight Care gives each request one ticket with one owner, whatever the channel; SLA timers visible to both sides; a knowledge base grown from resolved tickets; and workload reporting. In the allied-health case study, the queue became visible within a quarter and staffing decisions followed the data.

What to do about it, whatever you buy

Give every request one destination and one owner; two channels is one too many. Publish your service levels internally before externally — you cannot keep a promise you have not scheduled. Measure first-call resolution and queue age, not satisfaction theatre alone. And read your desk’s data monthly: it is the cheapest market research your organisation will ever run, arriving with its own timestamps.

When a desk is not needed

A five-person office that genuinely talks to itself may not need a desk. The threshold is the number of open requests nobody can list from memory. Once that number exists, the organisation already has a support desk in practice; the only question is whether it records anything.

Questions this view raises

Should the desk measure satisfaction or resolution?
Both, as different instruments. Resolution metrics — first-contact rate, queue age — tell you where the process is failing; satisfaction tells you whether the fixes are felt. Weighting satisfaction alone is the trap: it can be flattered by low expectations and poisoned by one bad week. Publish both together in the same report, and the desk gets a fair picture: what it fixed, and how the fixing was received.
How long before a knowledge base starts reducing tickets?
Two or three months of seeding: articles born from real resolved tickets, an owner and review date on each, and retirement for anything stale. The effect compounds — every ticket answered once is a draft article for the next person. Expect a curve rather than a cliff: volume falls gradually as the base grows, and the steepest drop comes once it covers the ten questions that made up half the queue.
Where this shows up in our software

Insight Care gives every request one owner and a visible service level. You can see these principles applied on the projects pages and throughout the InsightSuite module pages.