Error handling

When Slack’s message fails to send, it stays in your compose box with a bright red “Failed to send” banner and a retry button. The message doesn’t disappear and your work is preserved because losing someone’s carefully crafted message costs a lot of future engagement. Users who experience message loss are less likely to use Slack for important communications again. Slack’s recovery flow assumes you’ll forgive technical hiccups if your work is never lost.

Uber is a little different. When payment fails at ride completion, Uber doesn’t lock you out or hold the driver hostage. Instead, it lets you exit the car, adds the fare to your account balance, and sends persistent but polite payment reminders. The trip completes, the driver gets paid from Uber’s reserves, and you settle up later. Trapping riders in cars over a declined credit card creates safety concerns and terrible PR. A $20 unpaid fare costs less than one viral “Uber held me hostage” tweet. The tolerance for payment errors is remarkably high—Uber knows most users will eventually pay, and the small percentage who don’t cost less than the alternative of making rides feel like hostage negotiations.

Banks are the most tense. When a bank transfer errors, apps like Chase or Bank of America show multiple confirmation screens: “Your transfer did not complete. Your account has NOT been charged. Would you like to try again?” The redundancy seems excessive until you realize a phantom charge totally kills customer trust permanently. Banks know that one “the money left my account but didn’t arrive” incident costs more in customer lifetime value than a hundred frustrated users clicking through extra confirmations. These are all about what you can afford to lose as a company, and banks have the most at stake.

Avatar

About the author