A fuel ticket is the record of one uplift: the aircraft, the flight, the gallons, the date. Airlines pay against it and reconcile their fuel accounts from it, so someone has always had to check each ticket against the schedule before it posts. For Logicraft that meant about 190 tickets a day, arriving in a dozen layouts, each one read by an operator.
From July 1 to October 31, 2026 those tickets went through FuelDeck™ instead, and we measured the outcome straight from the production database. Nothing was sampled. What follows is a condensed version of the case study. Get the complete case study, free with a work email.
How we count. No human touch means the ticket reached validated or posted without anyone pinning a fuel day, flight or tail, editing a field, overriding a check, or triggering a revalidation, correction or redate. A person clicking Post on a ticket the system already validated is not a touch, because the ticket would have posted on its own. Needed a person means any of those acts, counted once per ticket.
The figures measure the absence of human intervention. They are not an accuracy claim.
Who the tickets belong to
The customers are airlines at 50 stations, most of them in North America and the Caribbean. Three into-plane fueling companies supply the tickets as Excel, PDF and CSV files. About 75 percent come through the handlers' four portals and data feeds, and the other 25 percent through a dedicated email intake.
Logicraft runs FuelDeck™ for these customers as a managed fuel-data service. It's the same service we have provided by hand since 1994, and the airlines changed nothing about how they receive their fuel records. The work that changed was ours. Two modules carried it: FuelScanner™ for intake and validation, and FuelCounter™ for the posted ledger and delivery to each airline's fuel-management system.
Why every fuel ticket used to need a person
Typing was never the hard part. The hard part was a set of judgement calls that only experienced staff made reliably.
| Pain point | What it looked like | Why it needed a person |
|---|---|---|
| Flight and day attribution | Overnight departures, repeated flight numbers, aircraft swaps, tail-number aliases. A ticket written at 23:40 local can belong to the next day's flight. | Deciding the fuel day meant reading the airline schedule and the airline's own date rule. |
| Duplicates or split deliveries | Handlers re-send tickets. Two tickets on one flight can be two trucks on one uplift, or a genuine duplicate. | Telling them apart meant looking at both tickets together. |
| Fragmented intake | Four portals and feeds plus an email inbox, each with its own layout, naming and timing. | Someone had to collect, open and route every file. |
| Knowledge in a few heads | The rules for each station and airline were conventions, not configuration. | A new operator couldn't be left alone with the queue. |
How the beta ran: operator first, then nobody
Both phases used the same pipeline on the same live tickets, so the second phase could be judged against the first.
Phase 1, July to mid-September: operator in the loop
Each day an operator opened the validation queue, the validation pass ran, and the operator reviewed the result and clicked Post. A person was present for every ticket, but the outcome was the machine's. In July, 98.9 percent of tickets posted with no edit, pin or override.
Phase 2, from September 23: fully automated
A stricter schedule-matching gate went live in September. Every ticket now has to match the airline's published schedule and live flight data before it can post, and a ticket that doesn't match is held rather than posted. From September 23 a nightly validation sweep and an hourly auto-post did the rest, with nobody logged in.
- Held tickets heal themselves. A held ticket is re-tried every time new schedule or flight data arrives, and split deliveries are recognized and paired. A ticket that was wrong this morning can be right tonight without anyone looking at it.
- Corrections stick. Every ruling a person makes teaches the system, and the ledger is re-swept until the same mistake stops appearing. Nothing becomes a rule without a person's sign-off, and nothing heals past a material difference in quantity.
- The queue holds exceptions only. What reaches a person is the ticket the rules couldn't decide: a date to pin, a tail to confirm, a schedule mismatch to rule on. The decision is written to the ticket with who made it and why.
Results, month by month
Across all 23,207 tickets, 98.2 percent were validated and posted with no human touch, and the rate held when the operator left the loop. The stricter gate pushed human decisions up to 3.9 percent of tickets in September. In October, with the operator's rulings built in as standing rules, they fell to 0.2 percent.
| Ticket month | Tickets | No human touch | Human decision | Held | Per 1,000 | Phase |
|---|---|---|---|---|---|---|
| July 2026 | 6,000 | 98.9% | 1.0% | 0.1% | 10.2 | Operator in the loop |
| August 2026 | 6,032 | 99.1% | 0.9% | 0.0% | 9.1 | Operator in the loop |
| September 2026 | 5,787 | 96.1% | 3.9% | 0.1% | 38.5 | Stricter gate; automated from 9/23 |
| October 2026 | 5,388 | 98.8% | 0.2% | 1.0% | 1.7 | Full automation |
| Beta total | 23,207 | 98.2% | 1.5% | 0.3% | 15.0 |
"Held" counts tickets still waiting when measured. In October all of them are tickets dated October 31 that arrived on November 1 or 2 and were waiting for schedule and flight data. Holding is not a human act. "Per 1,000" is human decisions per 1,000 tickets of that month.
Put the first month of the beta next to the last and the change is mostly in how often anyone has to show up:
| Measure | July (Phase 1) | October (Phase 2) |
|---|---|---|
| Validated and posted with no human touch | 98.9% | 98.8% |
| Tickets needing a human decision | 1.0% | 0.2% |
| Days with no human decision at all | 4 of 31 | 23 of 31 |
| Tickets still held when measured | 0.1% | 1.0% |
What changed between September and October
September was the learning month. The new gate surfaced the hard cases and the operator ruled on each kind of case once. In October those same cases resolved themselves, and tickets stopped waiting days for a person.
| Measure | September | October | Change |
|---|---|---|---|
| Human decisions per 1,000 tickets | 35.1 | 2.1 | −94% |
| Median time from arrival to posting | 62 hours | 5.2 hours | −92% |
| Validated by FuelDeck™ itself | 78% | 98.5% | +20.5 pts |
| People's time on exceptions | 10.1 hours | 1.2 hours | −88% |
Counted by the month a ticket arrived, so a July ticket worked in September counts in September, which is why these per-1,000 figures differ slightly from Table 2. People's time is counted in the month the work was done. "Validated by FuelDeck™ itself" means the nightly sweep, a self-heal, split pairing, or the check that runs when the queue opens.
What the 1.5 percent actually were
Over the whole beta, 348 tickets carried a human decision. Only one changed a quantity: a meter reading misread by 1,000 gallons, corrected on the operator's ruling. The rest were the judgement calls the gate is built to hand to a person.
A fuel-day pin fixes the date on an overnight flight the schedule rule couldn't settle, and the answer is nearly always the next day (113 of 143 pins). A "Reviewed, post" override is a person confirming a ticket the schedule check couldn't match, with the reason recorded. In 49 of the operator's 108 overrides, the ticket was right and the reference it was checked against was not. A flight or tail pin corrects an alias or an aircraft swap, and in a third of those the operator simply picked the leg FuelDeck™ had already found.
Each of these is written to the ticket's history with who decided and why, so the audit trail an airline may ask for is complete without anyone keeping notes.
What the exceptions cost in people's time
Every decision record carries a timestamp, so the time is added up from the records, not estimated. Nearly all of it belonged to one operator, in short sittings. A typical sitting was 5 decisions in about 7 minutes, and the median decision took 51 seconds.
| Measure | Whole beta | Phase 2 (from Sep 23) |
|---|---|---|
| Tickets processed | 23,207 | 6,921 |
| Tickets that needed a person | 348 · 1.5% | 49 · 0.7% |
| Time people spent on them | about 11½ hours | about 1½ hours |
| Per ticket that needed a person | 2.0 min | 1.8 min |
| Per 1,000 tickets processed | 30 min | 13 min |
| Per day | 6 min | 2¼ min |
Since full automation went live on September 23, 98.5 percent of tickets (6,817 of 6,921) were validated or posted with no human act. Of the rest, 49 needed a person and 55 were still held when measured, 53 of them dated October 31.
"For as long as we have done this work, the day began by opening the queue and reading every ticket until it was empty. Now the queue is already empty when we sit down, and what is left for a person is the ticket the rules were right to leave alone."
Alex Veyberman · Head of Fuel Data Operations, Logicraft
What these figures don't say
They don't measure accuracy. A ticket that fails a check is held, not posted, so "no human touch" tells you how often a person had to step in, not how often a ticket was right the first time. They also come from one operation: the managed fuel-data service Logicraft runs for its airline customers. If you want to know what the same definitions would show on your own tickets, that's a conversation worth having.
The complete case study
Every figure, every definition
The full report adds the pipeline diagrams, the complete definitions table, the method and sources behind each number, and the detail on how the 348 decisions were made.
Request the complete case study PDF.
Get the complete case study
