The shop-floor system your operators clock on to

Two buttons and a barcode wand, and it has run every shift since it was installed.

A typical business running one of these has 40 to 150 staff across one or two factory units, 15 to 40 terminals by the machines, and between 500 and 3,000 bookings a day. Whether the booking screen was written for grey terminals in 2004 or for tablets in 2020, the job is the same.

In the supervisor's words, the operator scans a badge, scans the job card, picks the operation and clocks on. At the end they clock off with the quantity made and the scrap, with a reason code. The terminal shows the next job queued for that machine, the office screen shows who is on what and which jobs are late, and at the end of the shift the hours go to payroll and the bonus calculation, the time goes against the job, and the accountant's work-in-progress figure updates itself.

The rules it holds are the ones payroll would notice first:

• An operator can be clocked on to two jobs at once on the multi-spindle machines, and the time is split in the ratio set for that machine.
• The first fifteen minutes after a shift start book to the shift's overhead code, a leftover from how the bonus scheme was agreed.
• Breaks are deducted automatically unless the operator clocked off, and the deduction differs by shift pattern.
• A job cannot be clocked off complete when good plus scrap does not match the batch, unless a supervisor's badge overrides it, and the override is logged.
• Certain scrap reason codes need a supervisor's scan before the terminal accepts them.

None of that is in a document. It is in the program, and in the habits of the people who use it.

Written between 2000 and 2010 in Visual Basic 6 or Delphi by a contractor who came in to do the terminals and stayed for the supervisor screen. It writes to a SQL Server database shared with the office system that raises the works orders, and it runs as a Windows program on every terminal: a PC in a steel cabinet by the machine, with a serial wand or a keyboard wedge. It has been reinstalled on new terminals twice and changed by hand many more times.

The contractor stopped answering years ago. The compiler lives on one machine in the office, and the connection string is compiled into the program, so the database cannot move without a new build on every terminal. That build has been put off at every budget meeting since.

The same booking screen built between 2016 and 2022, usually by an agency or a freelancer as a web system in React, Angular or Node with a tablet app in React Native or Ionic, or put together in Power Apps by a keen production engineer. Operators tap a tablet on an arm by the machine and scan the job card with its camera, the supervisor has the floor live on a big screen in the office, and payroll gets the hours as a download. From the office it looked as though the steel cabinets had had their day.

The wifi is the first problem. Behind the press line, where the signal drops, a tablet booking made offline is lost rather than held, so those operators went back to paper cards. The last change, a night-shift break pattern, doubled some bookings and was switched off. The agency finished its fixed-price job and left, and where the app went through Google Play, updates have had to target Android 16 since 31 August 2026.

Since 2023 a few production engineers have tried again with an AI app builder and stalled at the split bookings and break rules payroll depends on. Tablets or steel cabinets, the factory has booking software nobody can safely alter, stuck the same way as the program it was meant to replace.

A factory the office can see without walking round it, and wages that come from what was booked.

The terminals turned a walk across the floor and a card filled in from memory into a scan. The office knows which machine every job is on, how long it has been there and what is queued behind it, and the customer who rings for a delivery date gets an answer from the screen.

The other half is money. Because the bookings feed payroll and the bonus, the wages are right and the arguments are rare. Because they feed the job cost, the estimator learns what a part took, and the work-in-progress figure at month end is a report rather than a count. Every efficiency number the owner looks at starts as an operator scanning a badge.

Operators trust it because it asks little of them. Two scans and a quantity, no writing, and it has not changed in years.

Systems like this are left alone for good reasons. The reasons are also the problem.

The database stopped getting updates in 2019. The terminals write to SQL Server 2008 R2, which lost its updates in July 2019, on a server the terminals cannot be moved off because the connection string is compiled into the program. The insurer's questionnaire and the big customer's supplier audit both ask about it now.

A change is a shift at risk. In either generation the booking screen runs on every terminal at once, so a bad update stops the floor at six in the morning. On the older program the last change, adding a scrap code, took a weekend, and nobody wants to be the person who tries the next one.

The office moved on and the floor stayed. When the office went to a new works order system, the terminals kept reading the old table, so somebody exports the day's works orders into it every morning before the shift. If they are late, the floor clocks on to yesterday's jobs.

It shows a job number, not the job. The terminal has no drawing, no work instruction and no photo of what good looks like, and the quantity is whatever the operator keys in, checked against nothing, so the job pack is still paper and the revision on it is whatever was printed. The supervisor can see the floor from the office screen and nowhere else.

The same two scans, on any screen, fed by whatever the office runs now.

Each of these keeps a rule the terminals already enforce.

The same clock-on screen, in a browser. The same buttons in the same places, so it runs on the existing terminals, on a rugged tablet, and on the supervisor's phone. The wand still scans, and the split bookings and the break rules still apply.

Fed by the office system it has now. Works orders read straight from whatever the office uses, so the morning export stops and the floor is never a day behind. When the office changes system again, the terminals change one connection, not one program on forty machines.

The right revision, checked at clock-on. The drawing and the work instruction on the terminal when the operator clocks on, at the revision the works order carries, with a flag when the job card's revision is older than the current one. The paper pack becomes optional.

The machine's count beside the operator's. Where the controller offers it, the cycle count from the machine sits next to the quantity the operator booked, so the count is confirmed rather than typed and the gap between them is visible the same shift.

A floor that can be changed on a Tuesday. The database on a version that is still supported, the source in a place that builds, and a test floor of two terminals on a test copy, so a change is tried on two machines before it goes to forty. The scrap code that took a weekend takes an afternoon.

None of this switches the terminals off. The new screen runs on two of them first, beside the old program on the rest, and moves across as the supervisors choose.

Check them before payroll does, and put a finish date on every job from what the floor has already booked.

AI works on what the terminals record, never on the operators:

Bookings checked before the wages go. An operator left clocked on for fourteen hours, a scrap quantity larger than the batch, a split booking with one half missing: today the supervisor hunts for them in the week's bookings before the payroll run. AI goes through every booking at the end of the shift, flags the ones that do not add up and suggests the correction, and the supervisor approves or changes it. On a floor booking 500 to 3,000 times a day, that hunt typically takes a morning before each weekly payroll and becomes a few minutes a shift.

An expected finish for every job. The customer rings for a delivery date, and somebody walks the floor or phones the supervisor. AI works out an expected finish from the bookings so far and what the same part took last time, and shows it beside the job on the office screen. Each chase is ten minutes or so of walking and asking, and a busy office makes several a day, so this typically gives back three or four hours a week.

The shift handover, drafted. Which jobs are late, which machines stood idle, which overrides were used. AI drafts the note from the shift's bookings across 15 to 40 terminals, and the supervisor going off shift reads it and adds what the data cannot know, typically a quarter of an hour back at each change of shift.

Not worth doing: predicting machine breakdowns from the booking data. There is not enough of it, and the maintenance fitter hears the bearing first.

A flag or a finish date is only as sound as the tables it reads, and those sit on an unsupported server behind a compiled connection string, so this follows the first stage. The assessment maps where it would pay back on the floor as it stands.

The order is set by one fact: the floor cannot stop.

1. Make it safe to change. The source found and built on a machine that is not the one under the desk, the database moved off SQL Server 2008 R2 onto a version that is still supported, with the terminals still talking to it, a backup restored on purpose, and two terminals on a test copy. This goes first because a change that cannot be tried on two terminals cannot be tried at all.
2. The feed from the office. The first new piece touches no terminal: works orders read from the office's current system in place of the morning export. The floor notices only that yesterday's jobs stop appearing.
3. The new screen on two terminals. The clock-on screen in a browser, on two machines whose operators are willing, beside the old program everywhere else. When the supervisors prefer it, it spreads.
4. Drawings, the phone view, the machine counts. Each a stage, each priced on its own, each live on the test floor before the real one.
5. Retire the old program from the last terminal when nothing still runs it. The last thing to go is usually the end-of-shift payroll export, because payroll trusts it.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a shop-floor system that means a few days on the floor and in the code, watching a shift clock on, reading the booking rules out of the program and finding what else writes to its tables, and a report with costed options and a fixed price for each. Each stage after that is priced before you commit to it. How we work, what drives the price and the payment terms each have a page, and so does each technology the system is built on: Visual Basic 6, Delphi, SQL Server and desktop to web, and for the newer generation React, Angular and Node, React Native and Ionic.