A bilingual pump form and the fleet workflow behind it

An operations team fuels its trucks and machines from its own pumps, across several crews and all day. For fuel cost to land on a unit, the fill has to be attributed to that unit as it happens, and the meter reading taken at the same moment has to reach the office, because that reading is what a service clock runs on. A card charge has to be tied to the unit it was spent on. How each of those was handled before this was built is not recorded beyond the one line the specification carries.

The project specification records the prior process as a padlocked pump, a key kept with a clipboard, and truck number and name written by hand.

The specification records that description; no baseline figure was measured. Gallons per unit, missed meter readings, and time from a crew report to a closed repair were not being counted before this was built, so no before-and-after change can be computed.

I defined the operating problem, specified the system, directed the build and reviewed the result. AI agents wrote most of the code under my review gates.

I set the requirements for a phone form in English and Spanish, correctable entries, retained fields after validation errors, and a stated reason when a cost figure lacks enough meter history.

At the pump:

• Bilingual form. Shipped. Served as plain HTML with no JavaScript and no external resource, designed to open from a QR sign at the pump. English and Spanish come from one catalogue; a string with no Spanish entry falls back to English rather than rendering blank.
• Entry fields. Shipped. Person, one truck or one machine, fuel type, gallons, an odometer or hour reading, and optional notes. Fuel type is pre-selected per pump sign and the crew can change it. A missing reading takes a stated reason, and units with no meter take a recorded exception.
• Interrupted entry. Shipped. Drafts live 15 minutes in server memory, scoped to the pump credential, written to no disk and no browser storage. Validation errors, language switches and corrections keep every field the crew already entered. A service restart clears drafts and says so on screen.
• Duplicate suppression. Shipped. The server mints the entry’s sequence number, so a double tap on a slow phone records one row.
• Receipt with undo. Shipped. An undone fill is voided in place and stays visible as a voided row. Nothing is deleted.

In the office and the shop:

• Fuel dashboard. Shipped. Current month, historical months, a monthly workbook export, reconciliation variance, tanks, prices, route coverage, truck and machine economy, and an attention strip. Published workbooks and this case study omit per-person figures.
• Fleet manager tree. Shipped, English only. Units with server-side filters, and a unit page carrying its fuel and purchase history with voided rows struck through, service due, meters, crew requests and their queue, work orders, purchase attribution, readiness, unit comparison, and register and cost exports.
• Cost refusals. Shipped. Cost per mile and cost per hour print once a unit reaches the configured minimum meter span. Below that, the page says there is not enough meter history to print one.
• Purchase inbox. Shipped. A card charge whose memo folds to exactly one unit is attributed automatically; everything else waits for a person, who assigns it to a unit, to shop stock, or out of the fleet entirely.
• Crew reports. Shipped, not yet exercised in the field. Scoped one credential per active unit. A crew credential asking for the fleet manager tree and a manager credential asking for a crew report both return not-found rather than a permission message.
• Scheduled work. Recorded as deployed in the September release. Meter and ERP synchronization with Aspire five times daily, a monthly export, a route summary, and a daily pull of card charges. Each of the two services has an operator kill switch.

The person at the pump selects a unit, records the fill and supplies a meter reading or a reason it is missing. Validation preserves the other fields. A receipt allows a mistaken fill to be voided while retaining the audit history.

In the office, the unit record brings together fuel, purchases, meter history and service work. Charges that cannot be attributed confidently wait for a person. Cost per distance or operating hour is withheld when meter history is insufficient.

Deployed. The deployment record describes two access-controlled services. The 7 September 2026 release passed 14 authenticated read-only checks. A browser-driven release exercise ran eight stages and 31 real HTTP responses against a throwaway database.

Used. The source account dates the pump form’s first live use to 12 August 2026. A 2 September 2026 reading recorded 32 fills, of which 22 were live and 10 voided. The September 7 release generated and decoded 311 unit-specific labels in software; that count predates a later roster refresh. Physical QR scanning at the units is not established by those software checks.

Measured. No outcome measurement exists for this system.

Outcome not yet measured.

Four things would be worth measuring once enough months exist to compare: gallons and dollars reconciled against delivery invoices; the share of fills that arrive with a usable meter reading; the elapsed time from a crew report to a closed work order; and the share of card charges attributed to a unit without a person tagging them by hand. None of these has a recorded before-state, so the first reading will state a level, and a change becomes computable only after a second period.

For a reader whose crews record work on paper and whose office rekeys it, the engagement this resembles is a paid workflow review of one field-to-office path, ending in a written specification of the form and the rules it enforces, including what it refuses to compute. What a first engagement covers

The related entry closest to this one is Business reporting, where fuel gallons, spend and variance surface as business figures with their sources and vintages.