First Driver Call Shipped in Three Hours, Not Three Quarters
Noor's drivers called customers from their own personal cell numbers, invisible to dispatch and impossible to audit.
Real calling lives inside the driver app her team already ships, with a call log in her own systems.
Noor runs operations for a last-mile delivery platform. The kind of company whose app tells you your groceries are four stops away.
Drivers, dispatchers, and customers all live inside software her team owns and ships every week.
Calling was the one piece that didn't live there. A driver would call a customer from their own number to say "I'm outside," and dispatch had no idea it ever happened.
That gap is where the story starts.
So calling wasn't in the app. What did you do first?
Drivers used their personal cell phones. That was the whole system.
A driver would call a customer from their own number, and the customer would save that number and call it back on the next delivery, except by then that driver was on a different route or had left the company.
Dispatch had no idea calls were even happening unless someone complained. When support needed to reconstruct what was said on a call, did the driver actually call, did the customer answer, there was nothing to look at. It was invisible.
What was the breaking point?
Customers started asking for it directly: "Can I just call my driver from the app, like I message my Uber driver?" We heard it enough times that it went on the roadmap.
Then I asked our engineers what it would take to build calling ourselves, and the answer stopped me. We'd need our own phone infrastructure, push notifications that actually wake a backgrounded Android phone in a warehouse with bad WiFi, iPhone battery-saver behavior, and all of it kept working through every iOS and Android update, forever.
That's not a feature. That's a second company we'd have to run alongside the one we already run.
How did that feel? And commercially?
Honestly, it felt like being told no by our own team, which is worse than being told no by a customer. We weren't a phone company and had no business becoming one.
Commercially it was worse than a "no." It was a slow bleed:
- Drivers calling from personal numbers meant no record, no accountability, and occasional harassment complaints we couldn't investigate.
- Support was spending hours per week piecing together "what happened on that call" from driver text messages and customer complaints.
- We didn't want to build a VoIP team. We also couldn't keep shipping nothing.
Drivers called from personal cell numbers
no dispatch record, no call log, harassment complaints with nothing to investigate
Building calling in-house meant becoming a phone company
own infrastructure, push, and OS-update maintenance, forever, alongside the real product
Brought in the Acrobits SDK
real calling embedded inside the existing driver app; first call in about 3 hours, full evaluation inside 30 days
Calling became a shipped feature, not a phone project
flat $5,000/month SDK fee plus active-user billing; engineers went back to the product
What changed?
We looked at reselling a separate calling app, pointing drivers and customers at some other softphone. We killed that idea fast. Nobody wants to open a second app to make a call about a delivery that's happening in the first app.
So instead we brought in the Acrobits SDK, a toolkit that let our own engineers put real phone calling directly inside the driver app we already had. Same login, same screen, same workflow drivers already knew.
The part that surprised me: our team had a real call going, end to end, about three hours after they started the integration. Not three months. Three hours.
The full evaluation, testing it against our actual driver base and our actual network conditions, wrapped inside 30 days. We went from "this will take a year" to "we tested it this quarter" without lowering the bar at all.
How her team used Acrobits
Driver-to-customer calling went live inside the app drivers and customers already had open. No new icon, no second login, no "download this other app to talk to your driver." Under the hood it's a real phone call, not a browser trick, so it held the connection like a normal carrier call even as drivers moved between warehouse WiFi, the delivery yard, and cellular.
Number masking followed once calling was live. When a driver calls a customer through the app, neither party sees the other's real number. The platform sits in the middle, connects the call, and keeps its own record. That closed the privacy complaints and the accountability gap in one move, and support finally had a call log in our own systems.
If you had to teach this to someone, what is the one idea?
Unified communications happens in the UI.
I used to think "unified comms" was some big system phone companies install in a server closet. It's not. It's whatever screen your driver or your customer is already looking at.
Our drivers don't think "I opened a calling app." They think "I called the customer," full stop, inside the same app they use for routes and deliveries.
The SDK is just the mechanism that let our engineers wire a real phone call into a screen we already owned, instead of asking our customers to go somewhere else for it.
What they needed
- Calling inside the app they already ship, same login and workflow, no second app to open
- A real phone call, not a browser trick, that survives drivers moving between WiFi, the yard, and cellular
- A call log and number privacy so dispatch has accountability and customers never see a driver's real number
- Billing that flexes with a seasonal driver pool, not a fixed per-seat license paying for phantom drivers
- No VoIP team to hire, so engineers stay on the product features that differentiate the platform
Technical detail
Features that did the work
SDK for embedded calling
a toolkit that puts real phone calling directly inside an app you already own, same login and screen, no separate softphone.
Number masking
the platform sits between driver and customer, connects the call, and keeps its own record, so neither party sees the other's real number.
Native SIP, not WebRTC
a real carrier-grade phone call that holds the connection across WiFi, warehouse, yard, and cellular, instead of dropping when someone walks out a loading dock.
Active-user billing
pay for calling on the drivers actually making calls this month, so a seasonal pool that shrinks off-season does not mean paying for phantom drivers.
And the business?
We pay a flat $5,000 a month for the SDK, plus a charge per active user on top of that for the calls themselves, not a fixed seat price per driver.
That mattered more than I expected. Our driver headcount swings hard with peak season: we bring on contract and gig drivers for a few months and let that pool shrink again afterward.
- A flat per-seat license would have meant paying for phantom drivers every off-season, or renegotiating a contract every quarter.
- Active-user billing means we only pay for calling on the drivers actually making calls, this month. No surprise invoice when peak season ends.
- Because it shipped in three hours and evaluated in 30 days, it never became the multi-quarter engineering project that eats a roadmap.
Our engineers went back to building the product features that actually differentiate us, instead of maintaining a phone system.
"We need calling" is a different problem from "we need to become a phone company." Only one of them is actually yours to solve.
Put real calling inside the app your drivers and customers already live in, and keep your engineers on the product that sets you apart.