Transforming safety and compliance reporting across a restaurant network

The problem

A platform configured for one workflow, used through another. The intended path was simple: a team member notices a hazard or has an incident, scans the QR code on the safety poster, fills in the form. The research found a different path in almost every restaurant. The team member tells the manager. The manager decides whether it is worth logging, logs it if so, and sometimes closes it without telling anyone. In restaurants that ban phones on shift, the QR code was not even an option, so the manager became the reporter by default without anyone deciding that.

How I approached it

Two layers, and a sample designed to test an explanation. Underneath sits the quantitative base: the safety and reporting items carried on the network-wide employee engagement survey, with about 30,000 responses a year from a workforce of more than 50,000 team members across 900 restaurants. That layer says where reporting is strong and where it is quiet. It cannot say why, so the qualitative layer was designed to answer that.

The sample had to be able to disprove the theory. The working assumption in the business was that location explained reporting differences: rougher suburbs, rougher safety culture. So the restaurant sample was deliberately mixed: eight restaurants across high- and low-reporting sites, higher- and lower-crime suburbs, metropolitan and regional.

• More than 50 interviews with team members, restaurant managers, area safety leads, a franchisee and the central safety team, mostly in the restaurants, some by phone.
• A dedicated reporting survey with 55 responses on awareness, training, ease of reporting and what happens after a report.
• Restaurant visits, watching how a report actually gets made during a shift and looking at the posters, the first-aid cabinet and the office setup.
• Two walkthroughs of the platform's forms with the safety team, field by field.

Every recorded observation became a typed record. A pain point, an action people already take, a decision point, a behaviour, a process gap or an opportunity. Each record was tied to a stage and substage of the incident journey and to the role it concerned. That structure is what let the findings report point at exact places in the service rather than at themes.

Why I built a tool

The synthesis outgrew the documents, and then it outgrew the board. The blueprint had lived on a Miro board: one sticky per item, coloured by type, placed by hand in a role-by-stage grid. That worked until the synthesis started moving. Every new batch of interviews reclassified items, moved them between substages and split them, and every move had to be made twice, once in the record and once on the board. The findings report was then retyped from the board a third time.

So I made the records the source and everything else an output. The tool is a Flask application over SQLite with a vanilla JavaScript front end: 50 HTTP routes, 2,674 lines in the server, 37 Python scripts around it, 318 commits between 27 October 2025 and 22 January 2026. It holds the blueprint, the typed records and the trail between them, and it renders the board, the report and the evidence views from the same data.

1. No filter184 items, and no way to argue with themEvery dot is one item on the service blueprint. On the Miro board each was a sticky, coloured by type and placed by hand. At this size the map is complete and useless, because nobody can hold 184 things in a meeting.
2. SubstageNarrow it to where the reporter meets the formThirty of the 184 sit at the point where somebody is actually filling in the report, spread across five roles and the platform itself.
3. RoleNarrow it again to the role that does the workNine items. Filtering by role turns a map into a conversation, and it is the move the business could never make when the blueprint was a picture.
4. TypeSix records, each one a sentence somebody saidThe evidence behind Decision 1. Every record keeps a link back to the transcript line it came from, so a recommendation can be walked back to the moment in the room.

The Miro board is still there. The migrator is the proof of what the manual version cost. Two scripts in the repository push the blueprint out to Miro as stage frames with colour-coded stickies grouped by role, and a third pulls changes back and merges them. Reading the migrator is the clearest description of the work it replaced: for each cell in the role-by-stage grid, for each item in that cell, create a sticky with the category's colour and icon at a computed position. That loop ran 184 times in a second. By hand it is a day.

What the tool saved

This is an estimate, and it is built from counted work rather than from a stopwatch. I did not time the manual version, because the manual version is the thing the tool replaced. The counts come from the tool's own database and the December 2025 findings report. The one number I assumed is the minutes it takes to write, colour and place a single sticky, and it is visible below so anyone can change it.

What the research found

In the sampled restaurants, the manager's routine explained reporting better than location did. Across the eight mixed sites, no difference tracked the suburb. Where a manager talked about safety, thanked people for reports and showed the system on the first shift, reporting was strong regardless of where the restaurant was. This was the finding that reorganised the recommendations.

People reported to a person, not a platform. Team members described telling the manager first, almost without exception. They trusted their managers; nobody described feeling embarrassed or afraid to report, even when they had been doing the wrong thing. The barrier was not fear. It was the form, the phone and the threshold.

The form asked questions the reporter could not answer. Incident type came first, with options like first aid or lost time that nobody can predict while their hand is under the cold tap. The notifiable-to-the-regulator question sent people to a compliance matrix. Even area safety leads admitted asking the restaurant's safety champion which option to choose. Misclassified reports got sent back from above, and everyone learned that reporting was a way to get something wrong.

Reporters rarely heard what happened next. Minor reports were closed without a word. Over time that built the belief that reporting helps you with a claim but does nothing for anyone else. The exceptions proved the point: the restaurant where a faulty piece of equipment was fixed the same day had a story people kept telling.

Time pressure was real but smaller than it felt. Managers said a report takes one to three minutes. The cost people felt was stepping off the floor during a rush, and needing the manager's permission to do it.

Three decisions

The findings report carried a prioritised roadmap.

Decision 1

Ask what happened first; let the manager classify the outcome later

Evidence. Dropdown options that do not describe kitchen incidents; a regulator question no team member can answer; classification errors flagged from above; hazard categories that contain events rather than conditions.

Alternative considered. Add help text and examples to each field. Rejected because the categories themselves were the problem: an industrial taxonomy applied to a kitchen, in an order that asks for the outcome before the event.

Proposal. One entry point, then the mechanism in the reporter's own words, then the manager sets severity after the welfare check. Regulatory questions move to the manager's review. The safety team supported mechanism-first because it also gives them cleaner data. A clickable form prototype made the argument concrete: open the prototype, or see the full reporting flow with its states in the concept.

The ideal state, module by module

The delivered work stopped where the constraint was. The platform was a configured vendor product, so the recommendations were about the form and the routines. The question that leaves open: what would the service look like if the software followed the evidence? So in September 2026 I designed it, module by module, following the navigation of the product the restaurants used.

Ten screens on one design system, each shown whole with numbered notes naming the finding, the decision and the alternative rejected. Every component was checked against shipped products before it was drawn, and the reference list is in the repository.

Explore the full concept, with the design system and the decisions behind each screen.

Delivered, and what happened next

• A findings report with the four themes, the evidence behind each, proposals by theme, form-redesign prototypes and a three-phase roadmap: quick wins, process and culture, system evolution.
• A five-stage, eleven-substage service blueprint with lanes for the team member, the manager, backstage roles and the platform.
• The insight tool: typed records linked to substages, filterable by stakeholder, type, theme and source, with the report generated from the same data.
• Concept mockups for the incident form, the onboarding checklist, the daily check-in card and a reporting-threshold reference.

The report records that the recommendations were refined through a stakeholder discussion and that the roadmap was updated afterwards. Implementation of the form change sat with the platform owner; the manager routines sat with the safety and training teams.

What I would do differently: log the review step as data from the first batch, so the count of corrected extractions and rolled-back imports is a number on the page rather than a sentence.

How AI was used, and where it stopped

Three jobs, each with a gate after it. AI transcribed the recorded interviews. It extracted candidate insights from transcripts and classified them by type, stakeholder and theme, through a Claude Code command whose output is validated against a schema before it can be imported, with a git tag written first so a batch can be rolled back whole. And an Anthropic SDK endpoint drafts recommendations from five templates, storing the prompt alongside its output so any draft can be traced to what produced it.

None of it counted until I had reviewed it. Every one of the 232 records was read against its source and placed on the blueprint by hand. About ten needed correcting, and nearly all of them had failed the same way: an acronym the business uses, read by the extraction as an ordinary word, which flattened what the person had meant. Those were fixed by hand before import; the rest went in as extracted. The drafted mockups and recommendations were edited before they went into the report. That review step is the part I can describe field by field, and it is the part that makes the rest of it usable.

How one record travels from a transcript line to a blueprint cell, and how a record is checked against its source, is set out with synthetic data in the extraction walkthrough.

The same discipline produced the concept screens: designed on a design system I built, checked against shipped products, and measured by a contrast script and a lint gate that fail the build rather than warn about it.