A Lean walk through your service desk: what one hour of observation reveals

Before you buy, watch

When service desk performance is disappointing, the instinct is usually to look at the tooling. Maybe the platform is outdated, or the reports are not showing the right data, or the self-service portal needs a redesign. Sometimes tooling is the problem. But before spending budget on a new platform or a migration, it is worth spending one hour watching how work actually moves through the desk. What you see will almost certainly surprise you, and it may change what you decide to buy.

What to look for

Lean practice uses a concept called a "gemba walk": going to where the work happens and observing it without trying to change it. For a service desk, this means sitting with an analyst as they work through their queue, watching how tickets arrive, how they are triaged, where they get stuck, and how they are resolved. You are not auditing anyone's performance; you are studying how the system behaves.

Here are the specific forms of waste to watch for:

Rework. A ticket is resolved, reopened, and resolved again. This often indicates that the first resolution addressed a symptom rather than the actual issue, or that the analyst lacked access to the information needed to fix it properly the first time. Track how many tickets are reopened within 48 hours; the number is usually higher than anyone expects.

Waiting. A ticket sits in a queue because it needs input from another team, approval from a manager, or access to a system the analyst does not have. The ticket is not being worked; it is waiting. In many service desks, tickets spend more time waiting than being actively worked. Map the total elapsed time of a ticket against the actual work time; the gap is your waiting waste.

Handoffs. Every time a ticket moves from one person or team to another, context is lost, and the customer waits. Some handoffs are necessary (a desktop issue escalated to a network team, for example), but many are artifacts of how the organization is structured rather than how the work needs to flow. Count the average number of assignment changes per ticket. If it is more than two, investigate why.

Over-classification. Analysts spending significant time choosing from dropdown menus with dozens of categories and subcategories. If triage takes longer than it should, the classification model may be too granular for the volume of work. A simpler model with fewer categories often produces better data because analysts use it consistently rather than guessing.

Invisible work. Analysts handling requests that never become tickets: someone walks up, sends a direct message, or calls on the phone, and the work gets done without being recorded. This is not laziness; it is usually a sign that creating a ticket is more effort than solving the problem. If the tool makes it harder to record work than to do the work, people will skip the recording.

What one hour typically reveals

In our experience, one hour of observation at a mid-sized service desk consistently surfaces two or three improvement opportunities that have nothing to do with the platform. The most common findings are excessive handoffs between teams (often three or four per ticket when one would suffice), wait times driven by approval processes that could be simplified, and rework caused by incomplete information at the point of first contact. These are process problems, not technology problems, and they will follow you to any new platform if you do not address them first.

What to do with what you find

Document the waste you observe, quantify it where you can (average wait time, handoff count, reopen rate), and share it with the team. The data often speaks for itself: when people see that the average ticket waits four hours for an approval that takes two minutes to grant, the fix becomes obvious. Start with the waste that is easiest to remove, demonstrate the improvement, and use that momentum to tackle the harder problems.

If, after this exercise, the tooling genuinely is the bottleneck, you will know exactly what the new tool needs to do differently. That clarity alone is worth the hour.

← Back to Insights