Roadside assistance ("emdad khodro" in Persian-speaking markets) is one of those industries that has run almost the same way for decades: a phone rings, a dispatcher scribbles down an address, and a driver is sent out — hopefully to the right place, hopefully in time. As developers, we don't often think about what's happening under the hood of these local service businesses, but the technical challenges turn out to be surprisingly rich.
Over the past year I worked on modernizing exactly this kind of operation, and I wanted to share what that process actually looks like from a systems and product perspective — not a sales pitch, just the real engineering and UX problems we ran into.
The starting point: a phone number and a paper log
Most roadside assistance operators still run on:
A single phone line (or a few WhatsApp numbers)
Manual dispatching based on which driver "feels" closest
No historical data on response times, common breakdown types, or peak hours
This isn't a technology failure so much as a scale failure — it works fine for a small operation, but it falls apart the moment call volume spikes (rush hour, bad weather, holidays) or the business tries to expand to new areas.
What "digitalizing" actually meant here
- Location-first architecture
The core problem in this domain isn't billing or scheduling — it's geography. Every decision (which driver to send, how long it will take, what it will cost) depends on accurate real-time location data. We ended up building around:
Live GPS tracking for field technicians
Geofenced service zones to auto-route requests to the nearest available driver
Distance/time estimation using mapping APIs, tuned for actual local traffic patterns rather than straight-line distance
- Turning a phone call into a structured request
Instead of a dispatcher manually parsing a phone call, we moved intake to a simple web form / landing page: vehicle type, issue category (flat tire, dead battery, towing, lockout, etc.), and location — either typed or auto-detected. This single change had an outsized effect: it removed ambiguity, cut average response time, and created a data trail we could actually analyze later.
- A dispatch layer instead of a person's memory
We built a lightweight internal dashboard where incoming requests are automatically scored and matched against available drivers based on distance, current load, and vehicle capability (e.g., not every driver can handle heavy towing). This is a classic assignment-optimization problem — nothing exotic algorithmically, but it made a measurable difference over "whoever the dispatcher remembers is nearby."
- Data you can actually use
Once requests are structured, patterns become visible for the first time: which neighborhoods generate the most calls, which issue types spike in winter vs. summer, and where average response time quietly creeps up. None of this exists when everything lives in a phone log.
What surprised me
The hardest part wasn't the mapping or the dispatch logic — it was trust. Customers calling for roadside help are often stressed, sometimes stranded on a highway at night. A slick digital form doesn't help if it makes people feel like they're talking to a bot instead of getting real help fast. We ended up keeping a human-backed phone line alongside the digital intake, and used the software mainly to make that human faster and more accurate, not to replace them.
Takeaways for anyone digitalizing a local service business
Start with the data model of "location + urgency," not with a fancy UI
Automating dispatch beats automating customer interaction — keep a human in the loop where trust matters
Even a simple structured form beats an unstructured phone call, purely because it's queryable later
Expect resistance from staff used to the old process — the software has to make their job easier, not just add reporting overhead for management
If you're curious about the live result of this particular project, you can see the roadside assistance service we built this around here: امداد خودرو ابراهیمی (Persian-language site, Iran-based operation).
Happy to go deeper into any part of this — the dispatch-matching logic, the mapping/geofencing setup, or how we structured the intake form — just ask in the comments.
Top comments (0)