Ask an operations leader what their Gemba tool should do and almost everyone answers the same way: make the report faster. It is the obvious pain. It is the hour on Friday afternoon that nobody enjoys. But it is not where the routine actually breaks.

The routine breaks in the gap. The walk happens on Tuesday. The report goes out on Friday. The next walk in that area happens the following Tuesday, and by then nobody has reopened the file. The issues from last week are technically recorded, and functionally gone.

Recording is not remembering

A report is a record. Records are useful when someone goes looking for them. The problem is that nobody goes looking for a Gemba report. It gets read once by the people who were already on the walk, and then it lives in a folder that nobody opens unless there is an audit.

So you end up with a system that captures beautifully and recalls terribly. Every issue is written down somewhere. None of them are in front of the person standing in the aisle where they happened.

The value of an observation is not in having recorded it. It is in having it resurface at the moment you can do something about it.

What the recap does

Borrow the idea from television. Before the episode starts, you get thirty seconds of what happened last time. Not the whole episode. Just the threads that are still open.

Do the same with a walk. When you start a walk in Inbound, the first screen is not a blank issue form. It is the last few walks in that same area, with everything still unresolved at the top: what it was, who owns it, how long it has been open, and whether a reminder has already gone out.

Three things change immediately.

  • You stop re-logging the same issue. Half the "new" issues on a typical walk are things somebody already raised. The recap turns them from a duplicate into a repeat count, which is much more useful information.
  • Old items get a decision. Standing in front of the actual problem is the only place where "is this still a problem?" is easy to answer. At a desk it is a guess.
  • The owner gets asked in person. Not a reminder email. A question from someone standing next to them, holding the phone with the issue on it.
In practice
Teams that open the walk with the recap tend to see their closure rate move before their capture rate does. They are not finding more problems. They are finishing the ones they already found.

Why this is hard to bolt on

You can do a version of this with a spreadsheet and discipline. Someone filters last week's rows by area, prints them, and carries the sheet on the walk. It works for about six weeks, which is roughly how long any manual step survives contact with a busy quarter.

The reason it has to be automatic is that the recap is only valuable when it is unconditional. If it is a step someone has to remember, it will be skipped exactly on the weeks when the floor is under pressure, which are the weeks it matters most.

The second-order effect

There is a quieter benefit that shows up around month three. Operators start to notice that the things they raised come back up. Not always resolved, but always visible, always attached to a name.

That is the whole game. Operators do not stop reporting problems because they are disengaged. They stop because the last four things they mentioned went nowhere, and reporting a fifth is a rational waste of their time. A visible open list is the cheapest way to demonstrate that the loop is real.

Close the loop once, in front of the person who opened it, and the next walk gets easier. Close it three times and you have a floor that brings you problems before you ask.