Skip to content
allanninal.dev/build
Collaborate

Part 4 of 7 · Mileage claim checker series ~5 min read

How a question reaches the claimant

Every expense system eventually has to ask somebody a question, and almost all of them ask the wrong person. They route the odd claim to a manager, who does not know why the trip was long, who then asks the claimant, who answers, who tells the manager, who approves it. Three people, two days. The person who knows the answer was in the loop the whole time and was asked last. This post is about asking them first.

Key takeaways

  • The claimant is asked first. A manager only sees a claim if the claimant does not answer.
  • The message carries both numbers and the route, so the question answers itself half the time.
  • Three buttons cover almost everything: return trip, detour, or I typed it wrong.
  • “I typed it wrong” corrects the claim rather than rejecting it. Nobody is made to refile.
  • Silence escalates on a schedule: a nudge at 48 hours, a manager at five days.

Ask the person who knows

How a question about a mileage claim reaches the person who can answer itThree boxes across the top outside the AWS account. The Claimant, who knows why the trip was long. A Route map, a static image fetched with one call. And the Manager, who is involved only after silence. Inside the account, three components. The Question builder, which composes a message with both numbers and three possible answers. Send and sign, which mints single-use links and sends through Amazon SES. And the Escalator, which nudges and then brings in a manager. Arrows show the claimant answering with one tap, the route map feeding in, and the manager being reached only if the claim is unanswered. A note says most out-of-band claims are closed by the claimant in under ten seconds.AWS ACCOUNTClaimantknows why it was longRoute mapstatic image, one callManageronly after silenceQuestion builderboth numbers,three answersSend and signsingle-use links,SES outEscalatornudge, then a managerone tap backthe drawn routeonly if unansweredMost out-of-band claims are closed by the claimant in under ten seconds.
Fig 1. Who gets asked, and in what order. The claimant is the first and usually the only person involved; the manager exists in this diagram mainly as the thing that happens when nobody replies.
  • App integration
  • Management
  • People

What the message says

The whole message, in order

  • Line one. The trip, plainly. “Tuesday 14th, Ashford to Maidstone, call-out.”
  • Line two. Both numbers, in that order. “This route looks like about 41 miles. You claimed 84.”
  • The map. A small static image of the route, so the question is often answered by looking rather than thinking.
  • Three buttons. “It was a return trip.” “There was a detour — here’s why.” “I typed it wrong — it was ___.”
  • Nothing else. No claim reference in the subject line, no portal link, no policy reminder, and no sentence containing the word compliance.

The tone is doing real work there. “This route looks like about 41 miles” concedes that the system might be wrong, which it often is. “Your claim exceeds the permitted variance” does not, and the difference in how people respond to those two sentences over a year is larger than anything else in this design.

The three buttons, and why they are those three

  • Return trip. By some distance the most common cause. One tap doubles the expected distance, re-runs the band, and pays it. No manager, no note, no record that anything was ever odd.
  • Detour, with a reason. Opens a one-line box. The reason is stored on the claim and the claim is paid immediately — the reason is for the record, not for approval. A person who has to wait for their detour to be approved will stop mentioning detours.
  • I typed it wrong. Opens a number box, pre-filled with the expected distance. The claim is corrected in place and paid. Nobody is made to delete and refile, because refiling is how claims get abandoned and abandoned claims become resentment.

What happens when nobody answers

Silence is the interesting case, and it is almost never dishonesty. It is a phone in a van, a person on annual leave, an email address that goes to a device nobody opens. So the escalation is slow, and it never turns into an accusation.

What happens to a mileage question that nobody answersA vertical chain of five steps. First, Asked and waiting, with a timer set for forty-eight hours. Second, at forty-eight hours, still waiting, exiting to Nudge by SMS with one line and the same links. Third, at five days, still waiting, which pulls the claimant's manager from the staff sheet and exits to Ask the manager with the claimant copied in. Fourth, at month end, still waiting, which exits to Carry it forward, because a claim is never expired. Fifth, Answered, meaning paid, corrected or noted. A note says an unanswered claim is carried and never cancelled, because people are owed money for driving.AWS ACCOUNTAsked, waitingtimer set for 48hStill waiting?at 48 hoursNudge by SMSone line, same linksyesStill waiting?at five daysTheir managerfrom the staff sheetAsk the managerclaimant CC'dyesStill waiting?at month endCarry it forwardnever expire a claimyesAnsweredpaid, corrected or notedAn unanswered claim is carried, never cancelled. People are owed money for driving.
Fig 2. The escalation ladder. Two days buys an SMS nudge, five days brings in a manager, and month end carries the claim forward rather than cancelling it.
  • App integration
  • Machine learning
  • Management
  • Front-end & mobile
  • People

That last step matters more than it looks. Plenty of expense systems expire unanswered claims at period end, on the reasonable-sounding grounds that the books have to close. What that actually does is take money off somebody who drove eighty miles for you and did not check an email. The claim is carried, it appears on the next month, and it keeps appearing until a human resolves it in one direction or the other.

Next: what happens when a claim is finally approved — the payment record, the monthly total, and the one report that makes this worth running.

All posts