Slack, Uber, and banking apps all handle errors gracefully, recovering from issues even when an unexpected event occurs. However, their distinct error handling approaches reflect their business models and the business costs they can afford to absorb in the event of a failure.
Below is a screenshot from my Slack application when the internet was unavailable – Slack still allows users to view locally saved messages and interact as normal, with a small notification alerting them of the error. This mechanism protects Slack’s core business value that drives revenue: the idea of easy access and interaction. Though users may be annoyed by missing notifications during this time, messages soon reappear once connection is restored, and the business cost is minimal. By limiting the interface disruption, the end user still feels like Slack is “working” even when disconnected.
Conversely, a banking app stops all functionality, requiring a full restart or reconnection before allowing further action. App activity is suspended until the error is resolved. This response incurs a higher business cost than Slack’s model, as no banking activity can take place, and the bank loses money from the lack of transactions. However, this protects the core revenue stream: the secure banking of people’s money. Customers willingly endure such strict error-handling mechanisms if it ensures their accounts’ safety.
Uber’s approach lives between these extremes. When a transaction fails (e.g., a driver declines or the price changes), the app lets the user move through the process but denies completion. In doing so, Uber doesn’t fully suspend services like a bank, but it provides a disruption to make the user aware. Uber may lose a customer who doesn’t redo the transaction, but this allows for its highly optimized dynamic pricing algorithm, which enables more revenue even if a few customers are lost to app issues.
