What Actually Delays a Softphone Launch

The build takes two to four weeks. Launch dates slip by months. The gap between those two numbers is where this chapter lives, and almost none of it is technical.

We have watched enough of these to see the shape of a softphone launch timeline. Projects stall at both ends of the customer size range, for reasons that are exact opposites. The companies in the middle sail through, while everyone assumes they got lucky.

The softphone launch timeline, briefly

Worth having the actual steps in mind, because they are shorter than people expect. They pick up where the softphone trial leaves off.

You configure the app in the provider portal: features, design, provisioning. You select Submit for Review, and it goes to our QA team, who check it against Apple's and Google's requirements. Once it passes, a Pay button appears, and after payment you can build the installation packages. Then white-label apps go to the stores.

Design is the step people underestimate and the easiest to remove. If you do not have someone in-house who wants to produce app assets, we do it as a paid service, usually in a day or two. It is worth taking. Waiting three weeks for an internal designer to find a gap in their sprint is a common and entirely avoidable delay.

Generic apps skip the store queue entirely, since the app is already published. White-label apps do not. Our app publishing service reviews for compliance before submission, which catches the predictable rejections. The review clock itself belongs to Apple and Google, and nobody at Acrobits can promise you a date on it. Anyone who does is guessing.

The barbell

Here is the pattern, and it holds well enough that we can usually predict a softphone launch timeline from the org chart.

Large operators stall on permission. The technical work finishes and then waits. Procurement has a process. Legal wants to see the contract. The budget sits in a cycle that opens next quarter. Someone senior has to sign and is travelling. None of this is dysfunction, exactly. It is what a company that size is for, but the effect on a launch date is the same as if nothing had been built.

Small operators stall on hands. They can decide in an afternoon, and often do. Then it turns out nobody on staff has set up a provisioning flow before, or configured the server side, or knows what to do when a registration fails in a way the documentation does not cover. The decision was instant and the implementation is where it sits.

The middle of the market has enough technical capacity to build and little enough bureaucracy to decide. Those projects go from trial to live in weeks and their teams tend to assume that is normal.

So when a launch slips, the useful question is not who is at fault. It is which arm of the barbell you are on, because the two problems have nothing in common and the fixes are unrelated.

If you are on the large end

The delay is not technical, so a technical answer will not help. What helps is starting the approval work in parallel with the trial rather than after it.

Concretely: find out during the trial who signs, what they need to see, and when their budget window opens. A trial that finishes in week four into an approval cycle that opens in month three has not saved you anything. The document that survives this process is usually a plain requirements summary, the sort of thing someone can forward without explaining. Build one while the trial is fresh.

If you are on the small end

The delay is often technical, and this is the part we have been working on directly.

Provisioning, the server components, the configuration layer: understanding all of it used to be the entry price, and for a team without a telephony engineer that price was the whole obstacle. Documentation helps a competent engineer go faster. It does not help someone who does not know what they are reading.

So we built an MCP server that gives AI coding tools grounded access to the Cloud Softphone documentation, the support FAQ, the IPC SDK API, the provisioning guides, and working integration samples. Instead of guessing, the assistant answers from the real sources.

The practical effect is that an implementation which took a couple of weeks of specialist time becomes a matter of days for someone competent but not specialised. That is a real change for the small end of the barbell, and it is the only part of this chapter where we have changed the outcome rather than just described it.

Be clear about what it does not do. It will not decide your architecture, it will not test your deployment, and it does not replace someone who understands your own network. It removes the research, not the work.

What is actually to blame

Across the projects we see, the causes cluster into three, and Acrobits is rarely one of them.

Decision-making is first: no clear owner, or an owner without authority. Budget is second, usually timing rather than amount, since the money exists but the window does not. Technical capacity is third, and it is the one we can now do something about.

That list is uncomfortable to publish, because a vendor saying "it was not us" is the least credible sentence in business. So take it as a testable claim instead. Ask any softphone vendor how long the build takes, then ask how long their last three customers took to launch. If those numbers match, they are either very good or not counting properly.

The question worth asking

Not "how fast can you build it," because the answer is weeks and it has been weeks for years.

Ask instead: what will my own organisation need in order to say yes, and does anyone here actually know how to implement it? Those two questions predict your launch date far better than anything on our side of the contract. Once the app is live, the question changes again, and chapter four covers what moves softphone subscriber growth after launch.