TL;DR: Companies that burn diesel at scale (mines, steel plants, logistics fleets, gensets) lose part of it to theft, spillage and bad records, and nobody can prove where. FuelTracker reconciles every litre from delivery to dispense to consumption, flags variance within a day, and produces a savings report finance will sign. First wedge: high-consumption industrial sites.
BRD v2.1 · Product owner · Pilot completed, in production
Fuel managers at high-consumption sites cannot tell, on any given day, how many litres were lost and where. Losses surface at month-end, if at all, and can't be pinned to a tank, an asset or a shift.
This came out of field work, not a whiteboard. Running fuel operations in India and Southern Africa, I kept seeing the same pattern at client sites:
The pilot. A six-month IoT fuel management pilot at a major Indian steel producer. It started with a field survey of the site's fuel operations before any pitch, then 100+ requirements, integrating automatic tank gauges (ATG), dispensers, flow meters, RFID tags and tank sensors. The win didn't come from hardware alone. It came from a surveyed baseline and disciplined daily reconciliation: the pilot cut loss, theft and spillage by about 20 paise per litre, reaching a run-rate of about ₹4 lakh a month by months 5–6 on roughly 2 million litres of diesel a month, and the client could see it on paper. FuelTracker turns that playbook into software.
| What I saw in the field | Implication for the product |
|---|---|
| Loss, theft and spillage at dispense points were the recurring complaint | Reconciliation must happen per shift, not per month |
| Reconciliation happened after month-end, in spreadsheets, if at all | The product's first job is to replace the spreadsheet, not the meter |
| Buyers wanted proof of savings they could check themselves | The savings report is part of the product, not an afterthought |
flowchart LR
A["Field survey<br>locks the baseline"] --> B["Delivery logged against PO<br>dips before and after"]
B --> C["Dispense logged<br>asset, meter, attendant"]
C --> D["Daily tank reconciliation<br>opening + received - dispensed<br>vs closing dip"]
D --> E{"Variance above<br>site threshold?"}
E -- "Yes" --> F["Alert to fuel manager<br>and finance"]
E -- "No" --> G["Asset consumption<br>vs its own median"]
F --> H["Monthly savings report<br>vs locked baseline"]
G --> H
H --> I["Finance sign-off"]
| Decision | Why | What it cost |
|---|---|---|
| Integrate with existing meters and probes rather than build hardware | Sites already own sensing; the gap is turning readings into a decision | Data quality depends on someone else's devices, so manual entries are cross-checked (R8) |
| Lock the baseline with a joint field survey before go-live | Savings mean nothing if the starting number is disputed | Slower start to every pilot |
| Make the savings report a core feature | The buyer has to be able to verify the saving before it is worth paying for | Finance-grade exports and audit trail move up the build order |
| Offline-first mobile | Every target site has connectivity gaps | Sync and conflict handling add engineering work |
| Cut consumer features (subscriptions, calendar sync, social sharing) | No evidence of pain; field evidence points to B2B loss control | No consumer funnel |