Skip to content
allanninal.dev/build
Collaborate

Part 4 of 7 · Fuel log auditor series ~5 min read

How a query gets raised without an accusation

How a query is worded determines whether you get the answer or a defence, and in a system where most anomalies have an innocent explanation, getting the answer is the entire point.

Key takeaways

  • Ask the driver first, before anybody else sees it.
  • State the numbers and ask an open question. Do not state a conclusion.
  • Record the explanation so the same query is never raised twice.
  • Batch queries weekly. A message per anomaly is harassment.
  • The rare serious case goes to a person, off this system, immediately.

The wording

Two versions of the same query

  • Wrong: “Van 4 shows an unexplained 68 litre fill on Tuesday exceeding tank capacity. Please explain this discrepancy.”
  • Right: “Van 4’s fill on Tuesday was 68 litres and the tank holds 60. Was some of it for something else?”
  • The difference: the second one contains the likely answer and invites it.
  • It also assumes competence. The driver knows what they filled; the system does not.
  • Reply rate: the second version gets answered. The first gets escalated to a manager and takes a week.
  • Same data, same query, same person. Only the sentence changed.

The word “discrepancy” is doing a lot of damage in the first version, as is “unexplained”. Both frame the record as a problem attributable to the reader, which is not what the system knows and not usually what happened.

Batching

How fuel queries are batched and sent to driversA vertical chain of five steps entered by a box labelled Anomalies this week across the fleet. Step one groups by driver rather than by anomaly. Step two asks whether it has already been explained as a known pattern; if so it exits to Do not ask again, citing the mower every month. Step three asks whether there are more than three for one person; if so it exits to A conversation rather than a list of queries. Step four sends one message weekly with all of them. Step five records the answers against the records. A note says the second exit is what keeps this from becoming a weekly irritation.AWS ACCOUNTAnomalies this weekacross the fleetGroup by drivernot by anomalyAlready explained?a known patternDo not ask againthe mower, every monthyesMore than three?for one personA conversationnot a list of queriesyesOne messageweekly, with all of themRecord the answersagainst the recordsThe second exit is what keeps this from becoming a weekly irritation.
Fig 1. How queries are grouped and sent. Suppressing known explanations is what stops the same legitimate behaviour being questioned every month.
  • Database
  • App integration
  • Machine learning
  • Analytics
  • People

Recording explanations

The single most important feature here. When a driver explains that the extra litres go in the mower can once a month, that explanation is attached to the pattern, and the query is not raised again next month.

Without it the system asks the same question repeatedly, the driver correctly concludes that nobody is reading the answers, and the reply rate collapses. Every recurring query that is not suppressed after being explained is a small withdrawal from the account that makes the whole system work.

Three or more is a conversation

A weekly message with five queries in it reads as an accusation regardless of the wording. At that point the right action is a two-minute conversation, which usually reveals something structural: a vehicle that has been reassigned, a card that is being shared, a route that changed.

The rare serious case

How a genuinely serious fuel finding is escalated off the systemA horizontal row of five boxes. A clear pattern: repeated and deliberate. Off this system, immediately. To a named person, with the raw records. No automated query, and no batch message. A process, not a tool, as it should be. A note says a tool that handles this badly is worse than one that does not handle it at all.WHEN IT IS ACTUALLY SERIOUSA clear patternrepeated, deliberateOff this systemimmediatelyTo a named personwith the raw recordsNo automated queryand no batch messageA process, not a toolas it should beA tool that handles this badly is worse than one that does not handle it at all.
Fig 2. The exit path for the rare genuine case. It leaves the system entirely, which is the correct behaviour for something that affects somebody’s employment.
  • App integration
  • Security & identity
  • Analytics
  • People

The important design point is that the system does not have a fraud workflow, a case file, or a status for suspicion. Those features invite use, and something that affects somebody’s job should be handled by people with the raw evidence in front of them, not through a queue.

What the system does provide is the underlying records, exportable and complete, so that whoever is handling it is working from facts rather than from a summary the tool generated.

No driver league tables

Worth stating as a rule because it will be requested. Ranking drivers by fuel economy ranks their routes, and publishing that ranking creates pressure to game the one thing drivers can control, which is the odometer reading they type at the pump.

That is a genuinely bad outcome: it degrades the data the system depends on in order to produce a metric that was measuring routes anyway.

Next: what the fuel data says about the vehicles.

All posts