Operations Dashboard for a Dairy Vending Fleet

Replacing an evening spreadsheet with one system for stock, refill plans, driver routes and machine alerts. The system proposes; a person approves.

849,317

Machine readings analysed

Machines in the dataset

False alarms in replay

4.4

Days of data replayed

The problem

Every evening a member of the team counted stock and worked out the next day's refills by hand in a shared spreadsheet. Drivers opened a tab to find their route. The owner checked takings and litres separately, and a machine running warm or going quiet was only spotted when somebody happened to look.

The owner was clear about one thing from the start: the system should propose the plan and a person should approve it. Nothing should run the business on autopilot.

What we built

The spreadsheet's refill and production maths, moved into tested code, with the existing sheet imported so nothing had to be retyped.
A stock page with an automatic 9pm snapshot, plus production and route planning screens.
A private, revocable link for each driver that shows only their own route.
A propose, edit, approve and publish flow: blocking warnings must be acknowledged, and implausible entries ask "are you sure?" before they save.
An insights page that sets sales against the weather, bank holidays and school holidays.
An alert engine for warm milk and silent machines, with quiet hours and one message per incident.

How the machine data gets in

Each machine's touchscreen already keeps its own logs. Using only the remote-access service the panels already had, a collector mirrors those logs read-only into a UK-hosted Postgres database. The dashboard never writes to a live machine, and raw readings are never edited.

The first pull brought in 849,317 readings from all 18 machines over 4.4 days, plus a year of daily pour counts. At the median, the panels log every 10 seconds. Live publishing from each panel over encrypted MQTT is built and proven end to end against a simulated panel, and switches on machine by machine as each panel's software is updated.

Alerts built on how the machines really behave

Fridge doors open and machines get restocked, so a simple temperature limit would cry wolf all day. In the recorded data there were 50 short spells above 8°C across 17 machines, and 45 of them ended on their own within half an hour.

So the warm-milk rule fires only when a fridge stays above 8°C for two hours, with enough readings and a sensor reporting sane values. Anything that trips overnight is held until 7am and sent only if it is still true. Replayed against the recorded data, the rule raised exactly one alert, on the right machine, with no false alarms.

Safeguards

Every page is private by default, with a test that fails if a route slips outside the login.
Sign-in and driver links are rate-limited; driver links are stored hashed and can be revoked.
Database changes are additive and reversible.
Alerts go to Serqet only until the rules have been reviewed with the operator.

Where it stands

Stock, production, routes and driver links are deployed. Next come live overview cards, then a 14-day parallel run beside the spreadsheet before the switch-over, then card-payment data. Alerts reach the operator's team once they have reviewed the rules.

Technology

Next.js
React
TypeScript
Postgres (UK region)
Vercel scheduled jobs
MQTT over TLS
Python
Vitest