Skip to content
allanninal.dev/build
Collaborate

Part 4 of 7 · Address verifier series ~5 min read

How an unverified address is handled

Having decided not to block anybody, the question becomes what to do with the knowledge that an address probably will not deliver. The answer is not at checkout, and it is not to the customer.

Key takeaways

  • The flag travels with the order to fulfilment, not to the customer at checkout.
  • One intervention: a short message before dispatch, only for high-value or fragile orders.
  • The carrier’s own validation is a second opinion worth capturing.
  • Some addresses are permanently unverifiable and should be marked so, once.
  • A delivery that succeeds to an unverified address verifies it better than any file.

Who sees it, and when

How an unverified address is handled after an order is placedA vertical chain of five steps entered by a box labelled An unverified address, with an order placed. Step one asks whether to tell the customer now, at checkout; the answer is never, because it costs orders and helps nobody. Step two flags the order so it is visible in fulfilment. Step three asks whether the order is high value or fragile; if so it exits to One message sent before dispatch, phrased in a friendly way. Step four dispatches normally, which is most orders. Step five asks whether it was delivered, which is the real verification; a successful delivery exits to Mark verified by delivery, which is better than the file. A note says the last step is the strongest signal available and almost nobody records it.AWS ACCOUNTAn unverified addressorder placedTell the customer now?at checkoutNoit costs orders andhelps nobodyneverFlag on the ordervisible in fulfilmentHigh value or fragile?from the orderOne messagebefore dispatch, friendlyyesDispatch normallymost ordersDelivered?the real verificationMark verified by deliverybetter than the fileyesThe last step is the strongest signal available and almost nobody records it.
Fig 1. What happens to an unverified address after checkout. The final step is the one worth building: a successful delivery is better evidence than any reference file.
  • App integration
  • Machine learning
  • Security & identity
  • Management

Never at checkout

Telling somebody at checkout that their address could not be verified achieves two things and both are bad. It makes a proportion of people abandon, because a warning during payment reads as something being wrong. And it gives them no useful action, because they already believe their address is correct and it usually is.

The one intervention

For a high-value or fragile order to an unverified address, one short message before dispatch is worth it, and the wording matters enormously. Not “your address could not be validated” but “we want to make sure this arrives — is this right?” with the address shown as they typed it and one button to confirm.

That converts at a high rate because it reads as care rather than doubt, and it catches the genuine errors in exactly the population where a failed delivery is most expensive. For an ordinary low-value order it is not worth the message.

Permanently unverifiable

How a permanently unverifiable address is settledA horizontal row of five boxes. Not in the file: checked twice. Delivered fine: twice. Conclusion: the file is wrong. Mark permanent: and stop re-checking. Never asked again: about this address. A note says two successful deliveries settle it and continuing to flag it is just noise.AN ADDRESS THE FILE WILL NEVER HAVENot in the filechecked twiceDelivered finetwiceConclusionthe file is wrongMark permanentstop re-checkingNever asked againabout this addressTwo successful deliveries settle it. Continuing to flag it is just noise.
Fig 2. How an address earns permanent status. Two successful deliveries are conclusive evidence against the reference file, and continuing to treat it as suspect wastes attention.
  • Machine learning
  • Security & identity
  • Management
  • Analytics

This matters more than it sounds for businesses with rural or agricultural customers, where a substantial minority of addresses will never appear in a reference file in the form the occupant uses. Without a permanent marker those customers are flagged on every single order forever, and the flag stops meaning anything.

The carrier’s opinion

Most carriers run their own address validation at booking and return a result, and it is a genuinely useful second opinion because their data and the postal reference file are not identical. Capturing it costs nothing beyond reading a field that is already in the response.

The interesting case is disagreement: the reference file has no record and the carrier accepts it happily, or the reverse. Recording both and comparing them over a few hundred orders tells you which source to trust for your particular customer base, which is a much better answer than picking one on principle.

Next: the addresses already in the database.

All posts