Case study: why the hardest part of the job goes missing from the SOP draft

This is one pilot, not a study. The team — around twenty field technicians who maintain equipment at customer sites — recorded procedures with their phones in July and August 2026, in French and English. Some recorders had been through our recording training; some joined the team after a reorganization and had not.

The team received the pilot very positively, and it made their work noticeably easier. That is exactly why we looked closely at the places where the drafts fell short.

For this article we took the six physical procedures recorded in the final phase of the pilot. We left out two office procedures (screen-based, a different route) and the earliest uploads, which had almost no narration and would not tell us anything about the platform. For each of the six, we read the transcript and the draft side by side, watched the video at every point where the two disagreed, and wrote down what was missing, what was wrong and what caused it.

The procedures differ in kind — a cleaning routine is not a motor test — so we do not compare step counts between them or draw a statistical line through six points. What we can say is where, inside each recording, the draft lost detail.

The belt replacement is the clearest case. The procedure has an easy part — opening the unit, removing covers — and a hard part, inside the machine, where the old guide comes out and the new one goes in. The technician narrated the easy part. During the hard part, he concentrated, and there are four silent stretches of 27 to 53 seconds.

The draft mirrors that exactly. The opening and the covers come out as separate, well-described steps. The work inside the machine, two and a half minutes of it, is one step.

The reason is not mysterious. A video-to-SOP system works from two sources at once: the picture and the speech. The picture shows that hands move inside the machine. It rarely shows which part is released first, in which direction, or why. Without speech, the system can tell that something is happening, but not where one meaningful action ends and the next begins, so it merges them.

The team described this in their own words at the end of the pilot: long jobs “felt thin” compared with short ones. In our reading, the thinness is in the silent parts, not in the length.

What to do: say what you do while you do it. When the work needs full concentration, pause the recording, do the step, then repeat it on camera with narration — or describe it right after, while the hands are still on the part.

This one was ours. In the motor rotation test, the technician connects a tester and sets it before starting. The recording, translated from French:

“Plug in one or the other, make sure the tester is set to 45. The adjustment is very sensitive. Off we go.”

The draft:

Adjust the sensitivity and start the test. Turn the potentiometer to adjust the sensitivity.

What the step should say:

Set the tester to 45 and start the test. The adjustment is very sensitive. Check the setting before starting.

The draft is not wrong. It is useless, because the number was the step. The team told us this was the moment their trust in the drafts dropped: once a reviewer finds one dropped value, they start re-watching every video next to every draft, and the time saving is gone.

A spoken value should never depend on a reviewer's attention. Every number said in the recording should either appear in the draft or be flagged as missing, and that check belongs in the software, not in the review.

In the same recording, the technician first says the second motor is turning the right way. A few minutes later, with a colleague, he concludes that it is not, and explains why. The draft built its quality check on the first statement.

Real people correct themselves while they work. That is normal and useful. A draft should show both statements, with their timestamps, and leave the decision to the reviewer. We cover this failure mode and four others in five AI errors that reviewers miss on a quick read.

The two French recordings came back with transcripts that needed almost no correction. Several English recordings, made by French-speaking technicians, did not: one part name was transcribed four different ways, none of them right, and the error carried into the step text and the tool list.

Speech recognition is very good at fluent speech in any major language and noticeably worse at technical vocabulary in an accent it did not expect. For a bilingual team the conclusion is slightly counterintuitive: record in your first language and let the platform produce the second. A clean French draft translated into English is better English than a transcript of hesitant English. More on this in multilingual work instructions.

Two recordings were conversations: one person working, another asking. “How often do you have to clean this?” “Each day.” In a training session, that is a good way to learn. For a system that turns speech into steps, it is ambiguous input. A question can become a step, and an answer to a hypothetical (“if it were turning the other way, you would swap the wires”) can read like an instruction for something that never happened.

If two people are on camera, agree before recording who explains and who films. Questions go in the pause.

The French calibration procedure came out close to release-ready. The camera was close to the screen, the narration was continuous, and the reference value the technician gave for a good result ended up in the quality check. The system also skipped a false start correctly: the first take had been recorded twice, and the draft began with the second.

The cleaning routine captured practical knowledge you will not find in a manual: that a cleaning cycle normally takes five to ten minutes and a much shorter one in the history is a warning sign. That kind of knowledge is why teams record procedures in the first place.

1. Spoken values are evidence. A value said in the recording and missing from the draft is a defect, not a style choice.

2. Every pilot now has a joint review after the first three to five SOPs, with the people who recorded them, draft next to video. Every pattern in this article was visible in the first few drafts. We describe the full pilot design in why SOP software pilots end without a decision.

3. New team members get the recording training live. A session from two months ago does not survive a change in the team.

4. Confidential content can now be blacked out. Feedback from the pilot team led to a new redaction function in Soperion: anything in the picture that should not end up in the SOP can be blacked out.