Before writing a line of dispatch logic for a taxi operator, we spent two days asking one question repeatedly: what do you do when this goes wrong. The answers filled most of a notebook and shaped the system more than the standard flow did.
The happy path is the easy 20%
Ride requested, driver assigned, ride completed, payment taken — every dispatch platform does this and every off-the-shelf option would have covered it. It was never going to be the reason to build custom software.
The exceptions that actually mattered
- A driver accepts a ride and then goes offline without cancelling, which the dispatcher had been catching manually by watching a screen for stale statuses.
- A rider requests a ride, cancels, and immediately requests another, which under the old system sometimes assigned the same driver twice through a race condition in the queue.
- Airport pickups, which have a completely different fee structure, waiting-time rule and driver rotation than every other ride type, handled by a separate paper process the main system had never modelled.
- A driver disputes a fare after the fact, which needs the full trip history — route, timestamps, any surge multiplier — retrievable and presentable to both sides, not just stored somewhere.
Why this changes the architecture
A system designed only for the happy path treats these as edge cases bolted on later. A system designed from the exceptions treats ride state as something that can legitimately sit in an ambiguous or disputed state for a while, and builds the audit trail and timeout handling in from the start rather than retrofitting them.
The operator wasn't asking for a system that handles the normal ride well. They already had one. They needed the other 80% written down and automated.
What surprised the client
How much of their own process existed only as something the most experienced dispatcher did from memory. Writing the exceptions down for us to build against turned out to be valuable to them independently of the software, as a record of decisions that had never been formalised.
What we'd tell another operator starting this process
Bring the person who's been doing dispatch the longest into discovery, not just management. The exceptions live in their memory, not in any document, and they are the actual scope of the project.