How a Dispatch Team Stopped Working in Two Screens at Once
Ingrid's dispatchers ran the room from a console they trusted, but every call meant leaving that screen for a separate phone app.
Calling moved into the console. One screen, one login, one tool.
Ingrid runs dispatch operations for a regional freight and delivery platform. Her team does not drive trucks or vans. They run the room that tells the trucks and vans where to go.
Loads, drivers, customer accounts, routing, all of it lived in a dispatch console her team had used for years and trusted completely.
Calling drivers and customers, though, was a separate errand. A different app, a different screen, a different login.
We sat down with Ingrid to hear how her team stopped running two tools and started running one.
So what did you do first, before any of this?
We had a dispatch console our whole team already knew cold. Everything about a load, the driver, the route, the customer, the account history, was right there.
But if a dispatcher needed to actually call the driver, they had to leave that screen, open a separate phone app, find the number, and dial it. Every single call started with a context switch.
If you were juggling six loads at once, which every dispatcher is, that switch was where things got dropped. Someone would go to call a driver about a delayed pickup and come back to the console having lost track of which load they were even looking at.
What was the breaking point?
We looked at rebuilding our calling into a from-scratch app so it would live alongside the console. Our team quoted what that would take, rebuilding years of console functionality as native phone screens, and it was the wrong project entirely.
We did not want to throw away the console. Dispatchers were trained on it, trusted it, lived in it all day. What we actually needed was calling to move into the console, not the console to move into calling.
And nobody we talked to could tell us how to do that without a rebuild. It felt like we were being asked to choose between the tool our team already knew and the ability to call from inside it.
How did that feel? And commercially?
Frustrating, honestly, because the fix seemed obvious and nobody could deliver it.
Every missed call or slow callback showed up downstream:
- A driver sitting idle on the clock, doing nothing.
- A customer calling back angry asking where their delivery was, an account at risk.
- Every new hire learning two systems instead of one, which slowed onboarding.
We were paying for that friction every single day, in delays and in training time, and none of it showed up as one clean line item, which somehow made it worse. It just quietly ate margin everywhere.
Calling lived in a second screen
every call meant leaving the console, opening a separate app, finding the number, dialing; context switches dropped loads
A from-scratch rebuild was the wrong project
rebuilding years of trusted console functionality as native phone screens, just to add calling
Put the console inside the app
Custom Web Tab shows the existing console; the IPC SDK lets its buttons operate the phone
One tool, faster onboarding, lower cost
dispatchers train on one system; active-user billing as low as roughly $0.12 per active user for a single-brand deployment
What changed?
We found a calling platform that could sit underneath a branded app built for our drivers and dispatchers, Acrobits Cloud Softphone. The part that mattered to me was not any single feature. It was that the calling itself just worked.
Think about it like a faucet. You do not think about your water pressure, you just turn the tap.
That is what calling needs to feel like for a dispatcher who is already juggling six things. You press a button and the call happens, every time, on WiFi, on cellular, backgrounded, whatever.
Once we stopped worrying about whether calls would connect reliably, we could finally think about how calling should actually fit into the dispatcher's day instead of sitting next to it.
How they used Acrobits
The dispatch console went inside the app as a Custom Web Tab. A Custom Web Tab is just a window inside the app that displays an existing web tool. So we did not rebuild our console. We put the console we already had, exactly as it was, inside the same app our dispatchers use for calling. One screen, one login, one tool.
The IPC SDK turned that window into a control panel. A window on its own would only let you look at the console. The IPC SDK is a bridge that lets our console's buttons actually trigger the app's calling features. Click "Call Driver" inside our own console and the call just goes out. No app switch, no dialing, no copy-pasting a number. Click "Send Route Update" and a message goes out the same way.
Customer calls go out with both numbers masked. When a dispatcher opens a customer record and needs to call them, the call goes out with the driver's and the customer's numbers masked, so neither side ever sees the other's real number. The whole thing is logged in our own systems automatically. Anything the calling app could do, our dispatch console could now trigger directly, from a screen our team already lived in every day.
If you had to teach this to someone, what is the one idea?
Unified communications happens in the UI.
I used to think that phrase meant some big phone system sitting in a server closet somewhere. It does not. It means the actual screen your dispatcher is looking at, right now, today. Calls, messages, driver records, customer accounts, all in the one place they already work in.
The mechanism that makes that possible is the Custom Web Tab plus the IPC SDK. The tab shows your existing tool, the bridge lets that tool actually operate the phone.
Once I understood that, I stopped thinking about "which app should this live in" and started thinking about "which screen does my team never want to leave."
What they needed
- Calling brought into the console her team already trusted, not a rebuild of the console as a phone app
- A reliable base that just works on WiFi, cellular, and backgrounded, so calls connect every time
- A real bridge from the console to the phone: click to call, click to message, all triggered from her own tool
- Number masking on customer calls so neither the driver nor the customer sees the other's real number
- Active-user billing under her own brand so a dispatcher who is not calling in a given period costs nothing
Technical detail
Features that did the work
Custom Web Tabs
the existing dispatch console renders as a native tab inside the app. Same console, same login, now living beside the calling.
IPC SDK
the console inside that tab can trigger the app's calling features. Click to call, click to message, contact lookup, transfer. Standard web code, native behavior.
Number masking
customer calls place with both the driver's and customer's numbers hidden, and log automatically into the team's own systems.
White-label branding
the app runs under the platform's own brand on its own developer accounts, so it is part of the product, not buried overhead.
Active-user billing
pay per active user rather than a flat license, as low as roughly $0.12 per active user for a single-brand deployment, so an inactive user costs nothing.
And the business side of it?
We stopped paying for a rebuild we did not need, and we stopped bleeding time on context switches.
The result:
- Dispatchers train on one system now, not two, so onboarding got faster.
- Calls happen from inside the workflow they are already in, so fewer things get dropped mid-load.
- We pay per active user rather than a flat license. A driver or dispatcher who is not actively calling in a given period does not cost us anything. The wiki notes this kind of active-user model can run as low as roughly $0.12 per active user for a single-brand deployment, though your mileage depends on the tier and volume.
And because the whole thing runs under our own brand on our own developer accounts, the app itself became something we could point to as part of our platform, not a cost buried in overhead.
Don't rebuild the tool your team already trusts just to add calling to it.
The console didn't need replacing, it needed a bridge. Bring the calling to the screen your dispatchers never want to leave, not the other way around.