Lean Six Sigma in service operations

Service work hides. A part sitting in a queue is visible on the floor; a case sitting in a queue is a row in a system nobody looks at. The first map of a service process is therefore almost always a shock: twenty minutes of actual work spread across eleven days, with nine of those days spent in three separate waits that no single person can see.

The second problem is peculiar to service and it is the most valuable thing the method exposes. A large share of the demand arriving at a service operation is not real demand at all: it is people chasing, correcting, re-explaining and complaining because the operation failed them the first time. Strip that out and many operations discover a third of their workload is created by their own failures, which is capacity they are paying for twice.

The third is utilisation. Service managers are pushed to keep people busy, and queueing behaviour punishes it savagely. As a team approaches full occupancy, waiting time does not rise gently, it accelerates: at eighty percent busy the waiting factor is four, at ninety five percent it is nineteen. A team run flat out is not fast, it is congested, and the fix is slack rather than effort.

Define in a service context means choosing one type of case, not the whole department. "Complaints take too long" is unfinishable. "Category two complaints take nineteen days against a five day promise" can be measured, analysed and closed.

Measure is easier than people expect, because the systems already hold timestamps. The work is in cleaning them: a case that was reopened, a queue that was renamed halfway through the year, a status that means two different things in two teams. Expect the first week of the measure phase to be an argument about what the data actually records.

Analyse looks for the wait, not the worker. The usual finding is that the delay lives in two or three specific transitions, often where work crosses a departmental boundary, and that the people on both sides have known for years. Improve removes the transition or removes the reason for it. Control puts the lead time on a chart somebody owns, and keeps sampling failure demand, because it creeps back the moment attention moves.

The most important limit in service is the variation you should protect. Judgement at a bedside, care in a difficult conversation, the discretion to make an exception for someone whose circumstances do not fit the form: standardise those into a script and you get compliant, hollow work that meets its targets and fails the person in front of it. The test is never whether a thing can be standardised, but whether the variation in it harms the customer or serves them.

The second is targets. Service operations are unusually good at hitting a number while making the service worse. Average handling time is the classic: push it down and calls get ended rather than resolved, which returns next week as failure demand. Any measure introduced without its counter measure will be gamed, not out of malice but because people do what they are measured on.

The third is that a service problem is often a policy problem wearing an operations costume. If the delay exists because a rule requires two signatures for a decision nobody has ever reversed, no amount of mapping fixes it, and saying so at the start is more useful than proving it over three months.