Two systems, and what went wrong in each.

A dispatch operation logged every delivery run by hand. Staff described the run in a chat message and someone copied it into a spreadsheet afterwards — free text at both ends, so a mistyped price or a missed row looked exactly like a correct one.

A Telegram bot asks one question per column and takes answers as buttons rather than free text. The columns are not in the code: it reads them from the spreadsheet's own header row, and a separate file decides which are asked, which are required and what the suggested answers are. Adding a column is an edit to a spreadsheet, not a change to a program.

It runs as a Windows application — no Python, no command line — with access limited to an approved list. Tested end to end against a ten-column schema; the live run found two defects the unit tests had missed, one of them because those tests called the logic directly instead of going through the bot. Both are fixed, and a test that does go through the bot now exists.

One of the writer processes failed on 11 August 2026 and kept reporting itself active. Process status said healthy; the table had received nothing for thirty-one hours. 5,156 writes had been attempted and lost.

The health check was rewritten to read the data rather than the process: every table is now compared against the interval that was measured for it, and a table that stops receiving rows fails the check even while the service that feeds it is running.

The same class of failure now surfaces within one interval instead of a day and a half. Two further defects of the same kind — merges that were dropping rows without raising an error — were found by the new check rather than by noticing missing data later.