Skip to content
allanninal.dev/build
Collaborate

Part 2 of 7 · Mileage claim checker series ~6 min read

How a mileage claim arrives

The last system had three ways in. This one has exactly one, and the reason is worth stating plainly: mileage is claimed by people standing next to a van at six in the evening. Anything that needs a laptop will be done at month end from memory, and a claim from memory is a guess. So the entire intake design is in service of one number: how many seconds it takes to file a claim on a phone.

Key takeaways

  • One lane: a web form on a home-screen link. No app, no store, no login screen.
  • Three taps, because the recent-sites list covers most trips and the date defaults to today.
  • Site names resolve against the customer list before any routing call is made.
  • An address that cannot be resolved is a question, not a rejection.
  • A fingerprint on claimant, date and both endpoints makes a resubmission safe.

One lane, on purpose

Every extra channel is another shape to parse and another way for the same trip to be claimed twice. Mileage does not need an email lane: nobody writes prose about a journey. It needs the shortest possible path from standing beside a van to a submitted claim.

Three ways to name a place, converging on one claim recordThree boxes stacked on the left. Recent sites: the claimant's last ten destinations, one tap each. Customer search: type three letters and pick from the customer list. Free text: an address typed in full. Each has an arrow labelled tap, pick and type respectively, converging on One claim record on the right, holding the date, the from, the to, the reason and the claimant. Below it, connected by a downward arrow, is the Resolver, which turns each end into a postcode or raises a question. A note says three ways to name a place, one shape of claim, and that the first covers most trips.Recent siteslast 10, one tap eachtapCustomer searchtype three letterspickFree textan address, typedtypeOne claim recorddate, from, to,reason, claimantResolverto postcodes, or a questionThree ways to name a place, one shape of claim. The first covers most trips.
Fig 1. The form’s three ways to name a place, all producing the same claim record. The recent-sites list is not a convenience feature; it is what makes the whole thing a three-tap job.
  • Database
  • Machine learning
  • Analytics
  • Front-end & mobile

Why the recent list matters more than it looks

Field staff visit the same places. A plumber’s ten most recent destinations cover perhaps seventy per cent of next week’s trips, and a maintenance engineer on a contract round is closer to ninety. So the form opens with those ten as buttons, sorted by how recently they were used, and the common case is: tap yesterday’s site, tap today’s, tap submit.

That is not a nicety. A claim filed the same evening is a claim filed from the odometer and the day, which is accurate. A claim filed on the 31st for the whole month is filed from a diary and a memory, which is not. Most of what a mileage checker catches is not dishonesty; it is the accumulated drift of people reconstructing four weeks of driving on a Sunday night.

Turning a place into an address

The routing service needs something routable. People type “Henderson”, “the Henderson site”, “Henderson Ltd, unit 4”, and occasionally just “job 4471”. Resolution runs in a fixed order, and it stops at the first confident answer.

How a submitted claim becomes a checked pair of distancesA vertical chain of five steps inside the AWS account, entered from a box labelled Claim submitted from the phone form. Step one asks whether this trip has been seen before, fingerprinting the claimant, the date and both endpoints and writing conditionally to a DynamoDB claims table; a resubmission exits to Same claim, which shows the original. Step two asks whether each end is a known place, matching against customer and job records. Step three asks whether anything is still ambiguous, exiting to Ask the claimant with a short list to pick from. Step four asks whether the distance for this address pair is already cached in a DynamoDB routes table; a miss exits to a single Routing lookup which is then cached. Step five hands the claimed and expected distances to the checker. A note says the duplicate test is first and the routing lookup last, so a resubmission costs nothing.AWS ACCOUNTClaim submittedfrom the phone formSeen this trip?claimant + date + endsDynamoDB claimsconditional writeSame claimshow the originalresubmitKnown place?customer list, job listCustomer recordsnames and postcodesStill ambiguous?two candidates or noneAsk the claimantpick from a short listunclearCached distance?this pair, everDynamoDB routesaddress pair -> milesRouting lookupone call, then cachedmissHand to the checkerclaimed and expectedThe duplicate test is first and the routing lookup is last, so a resubmission costs nothing.
Fig 2. One claim, end to end. The duplicate test runs before anything is spent, place names are resolved against records you already keep, and the paid routing lookup only happens on a genuinely new address pair.
  • Database
  • App integration
  • Security & identity
  • Analytics
  • Front-end & mobile
  • People
  • Outside AWS

Why the routing lookup is last

It is the only line on the bill that is charged by a third party, and it is the only step that can be skipped entirely. The distance between two fixed postcodes is a constant, so the first time anyone claims Ashford to Maidstone it costs one lookup, and every claim for that pair afterwards costs nothing forever. On a business with a regular round, the cache hit rate settles above ninety per cent within a month.

Putting the duplicate test first has the same shape of benefit. A claimant who taps submit twice on a bad signal generates two requests, and the second must not pay for a routing lookup, let alone create a second claim.

What the resolver refuses to guess

  • Two candidates is not a match. If “Henderson” matches both Henderson Plant and Henderson Motors, the claimant gets both as buttons. Picking the wrong one produces a wrong distance, which produces a wrong question, which wastes everybody’s time.
  • A postcode from a job number is fine. If the reason field contains a job reference and that job has a site address, that is a confident match, and it is the one case where the system fills something in that the claimant did not type.
  • A home address is never inferred. Home-to-first-site is a policy question with tax consequences, and the sheet decides whether it counts. The system never quietly adds or removes it.
  • A place that resolves to nothing stays as typed. The claim is still made, still recorded, and simply goes to a person — because a claim that cannot be auto-checked is not a suspicious claim, it is an unusual address.

Next: the three comparisons the checker actually makes, and why the third one never blocks a payment on its own.

All posts