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

Process Walk / Gemba Analysis sits in the Analyse phase of RDMAICS. In the product's own words it helps you plan the walk, capture observable evidence, analyse patterns and close the loop. The three habits behind it are simple. Go see. Ask why. Show respect.

Use it when your data tells you that something is slow or inconsistent but will not tell you why. Measure phase charts show you where the problem lives. A walk shows you the behaviour, the handovers and the workarounds that produce the number. You watch the work, you talk with the people doing it, and you write down only what you can observe.

Use it before you change a process rather than after. A redesign built on assumptions is expensive to unwind. A redesign built on an hour of structured observation starts from the real condition. The tool gives that hour a shape so the walk produces evidence rather than impressions.

Everything below is built on the sample data that loads with the tool. The case is fictional. It was written to show the method clearly, not to describe any real organisation.

The setting is a customer support centre. The process under review is incident triage and resolver assignment. The stated purpose and question is to see the real causes of ticket ageing before changing the assignment process. The theme is flow and first time right information.

Notice how narrow that purpose is. The team is not walking to improve the support centre in general. They are walking to understand one effect, ticket ageing, before touching one mechanism, assignment. Narrow purpose is what makes a walk useful.

The top of the tool is a planning block. You complete it before you leave your desk. In the sample data the walk route runs from the intake desk to the triage queue, then to resolver assignment, then to the escalation desk. That route follows the ticket, not the org chart. You walk the path the work takes.

The participants are an improvement lead, a triage lead and two service agents. The lead observer is the process improvement lead. Including the people who do the work is not a courtesy. They see detail an outsider will miss, and they are the ones who will have to live with any change.

The condition is recorded as day shift. 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. That reference matters because it gives you a documented expectation to compare against. Without it you are only recording what happens. With it you can record where what happens differs from what was agreed.

The middle of the tool is where the walk itself is recorded. The discipline is to write what you can see and hear. A queue length is observable. A person being disorganised is not. If you cannot point at it, it does not belong in the evidence.

Ask why, repeatedly and gently. The point is not to catch anyone out. It is to understand the conditions that make the current behaviour reasonable. When an agent reworks an intake record, the useful question is what made the record incomplete in the first place.

Keep the walk inside its window. The sample walk runs from 09:00 to 10:15, so about an hour and a quarter across four locations. That is enough to see patterns and short enough to stay attentive. If you need more, run a second walk on a different shift rather than stretching one walk into a half day.

The output of the tool is the walk summary and agreed learning. In the sample case it reads that incomplete intake information and batch based assignment are the two largest observed sources of delay, and that the team should standardise intake validation, trial continuous assignment and verify the effect with queue age data.

Read that output in three parts. The first part is the finding, which names two sources of delay. The second part is the proposed response, which pairs each finding with an action. Standardise intake validation answers the information problem. Trial continuous assignment answers the batching problem. The third part is the verification step, which commits the team to checking the effect with queue age data rather than declaring success.

The tool also offers an AI review that explains the result. Treat it as a second reader of your evidence, not as the author of your conclusion. The agreed learning should still be words the walk participants recognise as their own.

The word agreed is doing real work here. The summary was written with the triage lead and the two agents present. That is what turns a set of notes into a shared conclusion.

A completed walk makes the next three choices easier. It tells you where to intervene, what to trial and what to measure. In the sample case the intervention point is intake rather than assignment, which is a meaningful redirection given the original question was about the assignment process.

It also supports a decision about sequence. Standardising intake validation first makes sense because incomplete information will degrade any assignment method you choose. Changing assignment first would leave the input problem untouched and would muddy the read on whether the new method helped.

Finally it supports a decision about evidence. Verifying with queue age data gives the team a before and after measure that is already collected. You are not building a new measurement system to prove a change you have not made yet.

The most common mistake is walking without a question. A general tour produces a long list of unrelated irritations and no decision. The sample purpose is one sentence and it constrains everything that follows.

The second mistake is recording judgements instead of observations. Phrases about attitude, effort or care are not evidence and they damage trust. Show respect is part of the method, not a slogan attached to it. People who feel assessed will show you a performance rather than the work.

The third mistake is skipping the planning block. If the route, the condition, the times and the standard work reference are missing, you cannot compare this walk with the next one. The fourth is leaving the summary unwritten until the following week. Write it with the participants while the detail is fresh, then close the loop by telling them what happened next.

A process walk is a sample. The example above covers one day shift, one route and seventy five minutes. It will not tell you how the process behaves on a night shift, at month end, during an outage or when a key person is absent. Anything you conclude from one walk is a hypothesis about a pattern, not proof of one.

The tool will not quantify anything. It produces no cycle times, no delay percentages and no savings figure. That is why the sample summary ends by sending the team to queue age data. If you need a number, the walk tells you which number to go and get.

It will not validate a cause. Observing that incomplete intake information coincides with delay is not the same as proving it drives delay. Confirmation comes from a controlled trial and from the verification data, both of which happen after the walk.

It will not fix anything on its own, and it will not substitute for the people doing the work. The output is a written agreement about what was seen and what to try next. Whether that agreement turns into an improvement depends entirely on what you do in the Improve and Control phases. The walk opens the door. It does not walk through it for you.