Why restaurant incidents keep repeating despite reports

An incident repeats when the report stops at what happened. To keep it from coming back, you need four things after the description: a cause looked for in the process, a decided action, a person it is assigned to and a dated check. Without that closed loop, the report works as an archive, not as a fix.

One cold room gasket, three reports

On a Monday, the manager of the second site writes in the logbook: "cold room door not closed properly, reading out of range this morning." Three weeks later, the evening manager writes almost the same sentence, but in the group chat. The first note sits in a logbook, the second scrolls away in a message thread. Nobody connects them.

Each report was honest. None of them looked at the door gasket, the closing instruction or what the evening line cook had been told. The incident was described twice and never dealt with.

Why a report closes nothing

Several mechanisms stack up, and none of them comes from a lack of seriousness.

• Describing it stands in for dealing with it. Writing feels like acting. The line is filled in, so the matter seems closed.
• The cause points at a person. "X forgot" says nothing about the process. As long as the cause is a first name, the only possible action is a word of warning, and a word of warning does not last.
• Nobody owns what comes next. An action with no role and no date belongs to everyone, which means no one.
• Incidents live in different places. Logbook, messages, the manager's memory: there is no way to see that three lines describe the same failure.
• Nobody goes back to check. Once the week is over, the next service buries the topic.
• The history leaves with the manager. When they move to another site or leave the company, the memory of past incidents goes with them.

The five links of a closed loop

Link	The question	The expected proof
Observation	What happened, where, when, who saw it?	Date, site, station, photo or reading
Cause	Which link in the process let it through?	One sentence about the process, not about a person
Action	What concretely changes?	An instruction, a checklist step, training, equipment
Owner	Who takes care of it, by when?	A role and a date
Check	How will we see that it holds?	An observable fact, on a date set from the start

If one link is empty, the incident is open, whatever the logbook says.

Setting up the loop, step by step

1. One place for all incidents. A shared sheet is enough, as long as both sites and every service write in it. The manager no longer has to dig through messages.
2. A five-field form, the ones in the table above. The employee who notices fills in the observation in one minute, with a photo if useful.
3. One question for the cause. Instead of "who?", ask "what made the mistake easy to make?" The answer is often a missing instruction, worn equipment or a badly placed time slot.
4. The action is written where the task happens. If closing the cold room is the problem, the step goes into the closing checklist for that station, not into a memo.
5. The check date is set when the incident is created. Not "keep an eye on it": "recheck a week from Thursday, morning reading."
6. Ten minutes a week, on open incidents only. The manager goes through the lines with no action, no owner or a check due.
7. Before opening an incident, look for an earlier one that looks like it. Same equipment, same station, same time slot: that is the sign of an untreated cause.

Form template to copy

• Date, site, station concerned:
• What was observed (fact, not judgment):
• Proof (reading, photo, witness):
• Cause in the process (instruction, training, equipment, schedule):
• Decided action:
• Assigned to the role of, due on:
• Check planned on, by, against which fact:
• Result of the check:

Mistakes that reopen the loop

• Closing the incident as soon as the action is done. It closes at the check, not before.
• Writing a cause just to fill the box. "Lack of attention" is not a usable cause. "Cause not established, review on ..." is better.
• Reserving reporting for managers. The employee who sees the badly closed door is the first witness.
• Adding too many fields. A fifteen-line form will not be filled in on a Saturday night.
• Using the list to find someone to blame. As soon as an incident earns a reprimand, the list empties, but the problems do not.

EU food hygiene rules (Regulation (EC) No 852/2004) call for procedures based on HACCP principles and for keeping useful records. A properly maintained incident loop is part of that. The exact requirements depend on your business: if in doubt, check with your advisory body or the competent authorities.

What to measure

• The share of open incidents that have an action and an owner. It tells you whether the list is alive.
• The number of incidents that come back on the same equipment, station or time slot, after a check. This is the real test of the cause you found.
• The delay between the observation and the dated check. If it grows, the loop is reopening.

Where Tsuno comes in

Tsuno keeps incidents and tasks with their history: date, site, station, action taken, check. A new incident can be matched to an earlier one, and you can ask "What have my managers not dealt with?" to see the lines still open, with the facts behind the answer. The corrective action is added to the station checklist, and nothing runs without your confirmation. Tsuno connects the facts, it does not name a culprit: the cause is looked for in the process, the training or the schedule. The details of the modules are on the features page.

Key takeaways

A repeat incident is a loop left open, not a lack of goodwill. Write the cause on the process side, assign the action to a role, and set the check date the same day.

Further reading: why a completed temperature check can still be useless, compliance theater, moving from an audit score to an action plan, the closing checklist and the pillar article Digital HACCP: what software should actually remove.