The shop floor will not fill in a form it gets nothing back from

The tablet is bolted to a bracket at the end of the filling line, at chest height, turned slightly so the roof panel does not glare straight off it. The form on it has eleven fields. Batch number, machine, operator, start time, end time, good count, rejects, reject reason, downtime minutes, downtime reason, remarks. Every one of those fields was agreed in a meeting by people who were sitting down at the time.

A few weeks after go-live the data looks tidy, which is the first thing that should worry you. Almost every record is created inside a twenty minute window at the end of the shift, by one person, in one sitting. The numbers being typed are being read off the shift register, the hardback book on the supervisor's desk that has been the real record of that line for years. The software has not replaced anything. It has added a second copy, made once a day, by someone who is now staying late to make it.

This is the ordinary outcome, and it is rarely a defect in the application. Capture at the machine is a trade. You are asking somebody who is already fully occupied to stop, take a hand off the work, and hand you something. If nothing comes back in return, the trade is bad, and people who have no comfortable way of telling you a trade is bad will simply route around it and keep the plant running.

Gloves, glare and the twenty seconds you do not have

Before any argument about incentives, there is a physical argument, and it is usually lost first. Thin nitrile works on a capacitive screen. Heavy gauntlets, wet gloves and anything with a cotton liner do not, so the operator either takes a glove off, which is a safety decision, or jabs at the glass until it registers something. Screens in a bright bay wash out. Screens near a wash-down point get covered in film. A keyboard that pops up over the field you are typing into is merely annoying at a desk and disqualifying next to a machine that is still moving.

• Hands Gloves, oil, flour, water. Assume one thumb and no precision. Targets should be large and far apart, and nothing important should sit near a screen edge.
• Distance If the tablet is eight steps from where the work happens, entry moves to the end of the shift. The device belongs where the operator already stands.
• Shared devices One tablet, four people, one login. Either identity comes from a badge tap or you accept that the operator field is a guess and stop pretending otherwise.
• Time A changeover is not a moment of calm. Anything that takes longer than the pause the operator already has gets deferred, and deferred means remembered, and remembered means wrong.
• Network Metal buildings, thick walls, forklifts parked in front of access points. Coverage at the office end of the plant tells you nothing about coverage at the far end of bay three.

None of this is exotic. It is the sort of thing you learn in an hour of standing next to the line and none of it in a requirements workshop. The useful discipline is to specify capture only after somebody has watched a full shift, including the messy end of it.

The register already exists

The second problem is social. There is almost always an existing record, and it is usually paper. The register wins on merits that are easy to underrate. It accepts half an entry. It tolerates a correction with a line through it. It never asks anyone to log in. Most importantly, somebody reads it. The supervisor reads it, initials it, and acts on it, which means writing in it has a visible consequence for the person writing.

A second record always loses to the first one, unless it does something the first one cannot.

The pattern, stated plainly

So there are two honest options and one dishonest one. You can replace the register, which means the new system has to absorb everything the register was doing, including the informal notes in the margin. You can feed from the register, which means accepting a once-a-day transcription and designing your downstream expectations around data that is a shift old and partly reconstructed. The dishonest option is to run both, call the digital one the source of truth, and quietly build reports on numbers that were copied out of a book by a tired person at ten to six.

Ask for less than you want

Most capture forms ask for things the system could work out for itself. Time of entry is on the device. Machine is a property of the device, or of the QR code stuck to the machine. Shift is a function of the clock. Operator is a badge tap. Batch is usually whatever batch was running on that machine at that time, which the scheduling side of the system already knows. Once you strip all of that out, the number of things only a human can tell you is small, and the small number is the point.

Write paths that forgive a bad network

Capture that only works online will be blamed for the site's wifi, and the blame will stick to you. The pattern that holds up is boring. The client generates an identifier for the entry itself, holds it locally, and retries until the server acknowledges it. On the server, that identifier is a unique key, so a retried entry updates rather than duplicates, which in Postgres is an insert with an on-conflict clause and nothing cleverer than that. Reconciliation, late arrivals and anything that needs a second look then run as scheduled work in your orchestration layer, well away from the operator's screen.

Confirm it back in the same second

The single cheapest change to adoption is showing the entry landing. Not a spinner, not a toast that vanishes, but the record appearing in a short list of the last few entries for that machine, with a running total for the shift beside it. This does two things. It tells the operator the tap worked, so they stop double-entering out of doubt. And it turns the screen into something with a reason to be looked at between entries, which is what eventually makes the device part of the job rather than an audit device someone installed.

Give the line back to the people on it

The strongest version of the trade is to give the operator and the supervisor something they already wanted, and to give it before you ask for anything. Almost everyone on a line wants the same three facts. How far ahead or behind are we against the plan for this shift, how much is left to run on this batch, and what is coming next. Those facts usually exist somewhere in the ERP or the scheduling sheet and are visible to nobody who could act on them.

A read-only view of those three facts, at the machine and on a phone, earns more cooperation than any mandatory field. When we built the mobile side of Uloborus we made it read-only on purpose, for exactly this reason. The phone in the supervisor's pocket is for looking, and the fixed device at the line is for the handful of things only a person standing there can know. Once the shift view is genuinely useful, asking for a reject reason stops feeling like surveillance and starts feeling like keeping your own screen correct.

Where this argument runs out

Some data should never be typed at all. If a machine has a counter, a PLC tag or even a dry contact you can read, take the count from the machine and leave the human out of it. People are good at judgement and reasons, and poor at transcribing numbers they can see on another display. Every field you move from a person to a sensor is a field that stops decaying at the end of a long shift.

And there is a case where the right answer is to buy nothing. A single line, one supervisor, a register that is read every day and acted on, and no regulatory requirement that the record be electronic. That plant does not need software, it needs the register photographed and kept. The argument for digital capture gets strong when there are several lines, when the person who needs the number is not the person who wrote it down, or when someone will one day ask which batch a given lot of raw material went into and the answer has to be found in minutes rather than in an afternoon with a box of books. Until then, the form on the wall is just a form on the wall, and the shop floor is right to ignore it.