Gemba Walk: See Why Tickets Age Before You Redesign the Assignment Process

The Gemba Walk tool helps you plan a structured visit to the place where the work happens, capture what you can actually observe, analyse the patterns you find and close the loop with the people who do the work. The product describes its own job in four moves: plan the walk, capture observable evidence, analyse patterns and close the loop. The guiding idea behind it is older and simpler. Go see, ask why and show respect.

It sits in the Measure phase of RDMAICS for a reason. By Measure you have a defined problem and a scope. What you usually do not have is a trustworthy picture of how the process behaves on a normal day. System data tells you that a ticket took a long time. It rarely tells you why the person holding that ticket paused, asked a colleague, reopened a form or waited for a batch.

Use the tool when the gap between the documented process and the observed process matters. Use it before you redesign something. Use it when stakeholders disagree about the cause and each of them is quoting a different report. Do not use it as a substitute for measurement. Use it as the thing that tells you what to measure next.

Everything that follows uses the sample data built into the tool. The case is fictional. It describes a customer support centre that wants to understand ticket ageing before it changes how incidents are assigned to resolvers.

The purpose statement reads: see the real causes of ticket ageing before changing the assignment process. That sentence does a lot of work. It names the subject, ticket ageing. It names the decision it serves, the assignment process. It also sets a sequence, observation first and change second.

The theme is flow and first-time-right information. The area is the customer support centre. The process under observation is incident triage and resolver assignment. The team has already resisted the most common trap, which is to walk the whole department and come back with a long list of unrelated irritations.

The tool asks you to fix the conditions of the walk before you leave your desk. In the sample case the walk route is intake desk, then triage queue, then resolver assignment, then escalation desk. That route follows the ticket, not the org chart. You start where work enters and you move in the direction work flows.

Participants are the improvement lead, the triage lead and two service agents. That mix matters. The improvement lead brings method. The triage lead brings authority to act on what is seen. The two service agents bring the ground truth and, just as importantly, they hear the questions being asked about their own work.

The shift or condition is day shift. The lead observer is the process improvement lead. The date is 2026-09-05, with a start time of 09:00 and an end time of 10:15. The standard-work reference is incident triage standard work v3.2. Recording the standard-work version is the quiet discipline in this form. Without it you cannot say whether a deviation you saw was a person ignoring the standard or the standard failing to cover the situation.

The capture step is where most walks succeed or fail. The rule is simple. Record what you can see, hear or count. Leave opinions, diagnoses and fixes out of the evidence field. If someone on the walk says the problem is staffing, that is a hypothesis, not an observation.

At the intake desk you look at what information arrives with a ticket and what is missing. At the triage queue you look at how tickets wait and in what order they move. At resolver assignment you look at how the decision is made and how often it is made. At the escalation desk you look at what comes back and why.

The ask why part is not an interrogation. You ask the person doing the work to explain what they are doing and what gets in their way. You ask several times, gently, until you reach a cause they can describe rather than a frustration they can only name. Showing respect is not politeness for its own sake. It is the condition under which people tell you the truth about workarounds they have invented to keep the service running.

The tool brings the inputs and the observations together into a single walk record with a summary and agreed learning. In the sample case the summary reads: incomplete intake information and batch-based assignment are the two largest observed sources of delay. Standardise intake validation, trial continuous assignment and verify the effect with queue-age data.

Read that in three parts. The first part is a finding with two named sources of delay. The second part is a pair of countermeasures, one for each source. The third part is a verification method, queue-age data. A walk summary without a verification method is just a story.

Notice what the finding does not claim. It does not say these are the only causes. It says they are the two largest observed sources of delay. Observed is the operative word. The walk ran from 09:00 to 10:15 on one day shift. The tool also offers an AI review that explains the result and the logic behind it, which is useful when you are preparing to present the record to people who were not on the walk.

The two findings also fit the stated theme, flow and first-time-right information. Incomplete intake information is a first-time-right failure. Batch-based assignment is a flow failure. When your findings line up with your theme, you have evidence that the walk stayed in scope.

The sample walk supports three decisions and blocks a fourth. The first decision is to standardise intake validation, which means defining what a complete ticket looks like and stopping incomplete ones at the point of entry. The second is to trial continuous assignment rather than batch-based assignment. The third is to measure queue age before and after, so the trial produces evidence rather than an impression.

The decision it blocks is the one named in the purpose statement. The original instinct was to change the assignment process. The walk says do not change it blind. Trial it, and fix the intake problem at the same time, because changing assignment alone leaves the information defect untouched.

The record is also a handover artefact. It carries the date, the route, the participants, the shift and the standard-work version. Six months later, when someone asks why intake validation was introduced, the answer is a dated observation with named participants rather than a recollection.

The most frequent mistake is treating the walk as an audit. The moment people believe they are being assessed, they perform the standard rather than the real process, and you learn nothing. State the purpose out loud before you start and keep to it.

The second mistake is fixing things on the walk. You will see something small and obvious and you will want to solve it immediately. Write it down instead. Solving on the spot shortens the walk, narrows the evidence and often removes the symptom that would have led you to the cause.

The third mistake is a vague purpose. The sample purpose names ticket ageing and names the decision it informs. Compare that with a purpose such as look at support operations, which produces a list you cannot act on.

The fourth mistake is skipping the closing loop. If the people you observed never hear what you concluded, the next walk will be harder and quieter.

The tool will not measure anything. It records what was observed during one window, in the sample case 09:00 to 10:15 on 2026-09-05. That is a sample of one shift on one day. It will not tell you how often incomplete intake information occurs, how long tickets wait on average or how much delay each cause contributes. The sample summary points you at queue-age data precisely because the walk cannot supply those numbers itself.

It will not prove causation. The finding is that incomplete intake information and batch-based assignment are the two largest observed sources of delay. Observed, by four people, in one process, on one shift. A different shift or a different volume day could rank them differently or reveal a third cause nobody saw.

It will not design the countermeasure. The record says standardise intake validation and trial continuous assignment. It does not tell you what a validated intake form contains, who maintains it, how the trial is scoped or what happens when a ticket fails validation at three in the morning. That work belongs in Analyse and Improve.

It will not manage the people side either. The record cannot make a triage lead act, cannot resolve disagreement about what was seen and cannot replace the conversation where you tell the two service agents what changed because of what they showed you. The tool organises evidence and keeps the walk honest. The judgement, the measurement and the follow through stay with you.