Shift Handover in Manufacturing: Capture Beats Templates

At 05:58 the night shift supervisor writes "ran ok, some issues on line 2" and goes home. What actually happened is that line 2 stopped four times, someone bypassed a sensor to keep it running, and the plan was to tell maintenance in the morning.

Nobody told maintenance. Day shift spends two hours diagnosing a fault that night shift had already diagnosed, and the bypass stays in place for another week.

That is the shift handover problem, and it is not a template problem. That plant has a template. It has eighteen fields and it is half empty every morning.

Everyone already has a template

Search this topic and page one is templates: free downloads, form builders, "8 best handover formats", plus maintenance-software vendors offering a digital version of the same form. The advice is sound as far as it goes — keep it short, flag unresolved equipment conditions, make it readable in two minutes.

It also assumes the constraint is format. The constraint is the two minutes in which the form gets completed.

Consider the actual conditions at shift change: the outgoing supervisor has been on for twelve hours, the incoming crew is waiting, a forklift is moving behind them, they may be wearing gloves, the plant is noisy, and in a great many European plants the person writing is working in their second language. A form that takes four minutes to complete properly will be completed in forty seconds. The fields that survive are the numeric ones, because they are quick. The narrative — what was tried, what is still bypassed, what to watch — is exactly what gets compressed into "some issues on line 2".

So the detail that disappears is not random. It is systematically the most valuable part.

You will also meet some large numbers in this space: an oft-repeated claim that inconsistent shift communication costs manufacturers around $50 billion a year, and vendor case anecdotes with precise five-figure losses attached. Neither traces to a methodology you can inspect. The documented case is older and more serious: the Cullen Inquiry into Piper Alpha identified failures in permit-to-work handover between shifts as a contributing factor in a disaster that killed 167 people, and modern HSE human-factors guidance on handover exists largely because of it. You do not need a fabricated dollar figure to justify this work.

What HSE actually says, and why it matters here

The guidance is specific: handover should be face to face, two-way, with both parties taking joint responsibility, and should use verbal and written communication together.

That last clause is the one to hold onto when anyone proposes automating this. The conversation is not overhead to be removed. Two people talking is what catches the thing the outgoing supervisor did not think to write down, because the incoming supervisor asks. Replace the conversation with a dashboard and you have optimised away the part that works.

The written record is a different job, and it is the one that is failing. So the target is narrow and worth stating plainly: keep the conversation, remove the writing.

The handover does three jobs, the template serves one

Job	What it answers	Served by a form?
Reporting	What did we produce against plan?	Yes — numeric fields work fine
Continuity	What is unresolved, degraded or bypassed right now?	Poorly — needs narrative, gets compressed
Memory	Has this happened before, and what fixed it?	No — nothing in a form does this

Most plants have solved the first, partly solved the second, and not attempted the third.

The third is the one with the money in it. A handover logbook is write-only memory: entries go in, and unless somebody happens to remember, nothing ever comes out. The same fault gets diagnosed by four different people across six weeks because no one can ask has line 2 done this before? and get an answer in less time than it takes to just start investigating again.

Capture in the conditions that exist

The reliable way to get the narrative is to stop asking for it in writing.

Let the outgoing supervisor say what happened — a voice note, a message in the group they already use, thirty seconds, in their own words and their own language. Then do the structuring by machine afterwards:

"línea 2 paró cuatro veces, creemos que es el sensor de la puerta, lo hemos puenteado para acabar el turno, hay que avisar a mantenimiento"

From that one sentence you can derive the stop count, a suspected cause, an active bypass that must be flagged as an open safety item, and an action for maintenance — none of which the same person would have typed into four separate fields at 05:58.

This is the same capture pattern as OEE tracking without an MES, pointed at a different output. There, free text becomes a downtime reason code so a metric can be counted. Here, the same sentence becomes a continuity record: what is still bypassed, what the next crew watches, what maintenance owes an answer on. One utterance, two derived artefacts, and the operator classified nothing.

The practical rules that make it work are unglamorous:

• Accept whatever channel they already use. A plant WhatsApp group beats a beautiful app nobody opens with gloves on.
• Never reject an input for being unstructured. The moment the system demands a format, you are back to the form.
• Read it back for confirmation, briefly. A three-line summary the supervisor can correct in one message, before they leave, not a review queue they will never open.
• Work in the language spoken on the floor. Translating at capture time loses nuance; translate at reading time instead.

The part nobody builds: retrieval

Capture alone gets you a better logbook. A better logbook is still write-only.

What changes the economics is being able to ask questions of the accumulated handovers:

• Has this machine shown this symptom before, and what was done about it?
• Which temporary fixes are currently in place across the plant, and how old is the oldest?
• Which problems have now been reported by three consecutive shifts without anyone escalating?

That third one is the highest-value thing in this whole article. The single most common expensive failure in manufacturing communication is not a lost message; it is a recurring message that nobody recognises as recurring, because each shift reports it once and each report looks minor in isolation. Three separate "line 2 stopping again" notes across a fortnight is a pattern, and no human reading one handover a morning is positioned to see it.

An agent reading every handover as it lands does see it, and can raise it as its own item — not another dashboard nobody opens, but a message to the maintenance lead that says this has now appeared in five handovers since the 4th. Bypasses in particular should age visibly: anything flagged as a temporary fix that is still open after a week is a standing question, because temporary fixes are how quality holds and safety findings quietly become permanent.

What to automate, and what to leave alone

Automate: capture from voice or chat, structuring into your fields, pushing the production numbers into production reporting so nobody retypes them into the morning meeting spreadsheet, and searching the history.

Automate carefully: flagging recurrence and ageing open items. Tune this to under-report at first. A recurrence alert that fires on everything gets muted in a fortnight, and a muted alert is worse than none because everyone believes it is working.

Do not automate: the face-to-face exchange, and the decision about whether an open item stops production. That second one is a judgment about safety and output with a person's name on it, and it stays a human decision permanently, the same boundary that applies anywhere automation touches something consequential.

Also do not automate your way around a handover that is not happening at all. If shifts overlap by zero minutes because of how the rota is built, no software fixes that; the rota does.

Measure four things

1. Handover completion with narrative content. Not "was a form submitted" — what share of handovers contain anything beyond numbers. This is the number that moves first and predicts the rest.
2. Repeat diagnosis rate. How often two shifts investigate the same fault independently. The clearest evidence of information dying in transit, and the clearest evidence when it stops.
3. Open temporary fixes, and their age. The bypass register you probably do not have. Most plants are genuinely surprised by this list the first time it exists.
4. Time from a recurring issue's first mention to someone escalating it. The pattern-detection payoff, and the one that shows up later in maintenance cost.

Not on the list: handover reports submitted on time. You will hit 100% and learn nothing, because "ran ok" submits on time.

Start here

Take last month's handover records — logbook, forms, WhatsApp scrollback, whatever exists — and read them for one line: every mention of something temporary, bypassed, patched, or "keeping an eye on".

Two things usually come out of that hour. A handful of temporary fixes still in place that nobody was tracking, and at least one problem mentioned by three or more shifts that never got escalated because each mention looked small.

That list is the business case, and it was written by your own supervisors. The information was captured. It just had nowhere to go and no way to be asked a question.

Oido runs the record half of shift handover for plants without an MES: a voice note or message in the group your supervisors already use, structured into output, stops, open items and bypasses, production numbers pushed straight into the morning report instead of being retyped, the whole history searchable in plain language, and recurring issues raised to a named person before they become a breakdown. The conversation at 06:00 stays exactly where it is. See how it fits manufacturing, or send us a month of handover notes and we will tell you what is still bypassed.