The App Is Live. Now What?

The small stuff first

There is always some. A handful of subscribers on one Android manufacturer whose battery optimisation kills background registration. A desk phone that behaves differently from the twelve you tested. Something in your provisioning that nobody hit until the four hundredth user.

That is what support is for, and it is worth knowing what you are getting: our support team, not a reseller's, working on software our own engineers wrote. Updates ship under your brand without you doing anything. When Apple changes something in a new iOS release, the fix arrives in your app because it arrives in the platform.

None of this is remarkable and it is not what the monthly fee is really for. It is table stakes, and any vendor who makes a feature of it is telling you something about the rest of their offering.

Softphone subscriber growth: the question that actually comes

"My subscriber base is not growing fast enough."

We get this one often enough that it deserves a straight answer. It starts with an uncomfortable part: when subscriber numbers disappoint, the app is rarely the reason. Nobody churns because a softphone lacked a feature they never knew existed. They churn, or never adopt in the first place, because the offer did not give them a reason to change what they were already doing.

Which means the honest response is not a feature list. It is a set of questions about what you are selling and to whom.

Still, some of it is genuinely on the product side, and this is where we can help concretely. Operators routinely ship a fraction of what they have already paid for. A launch configuration is a snapshot of what you understood in month one, with features switched off to keep the first release simple. It very rarely gets a second look.

Two features separate the customers who grow from the ones who plateau. Neither has anything to do with calling.

Custom web tabs

Chapter one, on the white label or generic softphone choice, said custom web tabs make almost anything feel achievable. Here is what that looks like. Cloud Softphone can host your own web content as a native tab inside the app. That much has been true for years. Most operators use it for a billing page or a promotion, which is a reasonable thing to do and roughly two percent of what a web tab can do.

Point it at anything your subscribers would interact with and the app stops being only a phone. It becomes a platform. There are two ways to use that, and they are worth separating, because one saves you money and the other makes you some.

The tab you build for yourself. Put your own self-care inside the app. The current plan and what it costs, the renewal date, data used against the allowance, voice minutes and messages, every device on the account including eSIMs and wearables, and the perks the subscriber has forgotten are included.

Then look at what sits next to each number. A data bar reading thirty-five percent left, with a button to buy more directly beneath it. That is an upsell offered at the one moment the subscriber actually wants it, which is not a moment your website can catch, because nobody visits a self-care portal to browse. Meanwhile every action taken there is a call your support team did not receive: the top-up, the plan change, the bill query, the suspended travel SIM.

Operators pay for a web self-care portal and then discover their subscribers do not visit it. The same pages, inside the app they already open several times a day, get used. You can even set the custom tab to be the one that shows when the app is opened.

The tab you sell to your business customers. This is the one that adds a revenue line.

Take a hotel. The tab opens on the guest's own room: check-out with a button to extend it, the folio, one-tap requests for housekeeping or valet, the room service menu with an add button, spa treatments with a booking button, the minibar charging to the room. A guest can order dinner, book a massage, and push their checkout back without speaking to anyone.

Every element on that screen is a transaction and none of them is a phone call. The guest may go the whole stay without dialling and the app still moved real money.

The same shape fits a clinic with a patient directory and appointment list, a logistics operator with a dispatch queue and driver status, a field service company with job sheets, an insurer with claims. The tab is a URL, so whatever the business already runs on the web can live inside a branded phone app you provide.

With the IPC SDK the tab stops being a display surface and starts talking to the phone underneath it. Web content can place SIP calls, match numbers against native contacts to drive a caller screen-pop, react to call state, and update badge counts. Your web team builds it with tools they already have, and it ships when they deploy rather than when Apple approves.

Here is the part that answers the growth question rather than the feature question. Tabs switch on per user and per tenant, which makes each one something you can package and price. A premium CRM bundle for one business customer, a video room for another, an industry workflow for a third, each billed inside the app they already pay you for. That turns the app from a cost centre defending your minutes into a place where you sell things. Operators who work this out stop competing on price with the provider down the road, because they are no longer selling the same product.

The push token reporter

Every subscriber who installs your app is a device you can reach directly, and most operators never once use that.

The push token reporter is a web service that hands your server each device's push token every time the app starts, along with the application id and account username. Your server keeps the list. When you want to reach those devices, you post to our HTTP push gateway and the notification goes out through the Push Notification Mediator to Apple or Google. There is a web console at pnm.cloudsoftphone.com for sending test pushes before you wire anything up. Or build your own.

What that gives you is a direct channel to your entire installed base that costs nothing per message and does not go through a carrier, an inbox, or an ad platform. Service notices, a new feature, an upgrade offer, a reminder to the half of your base that installed the app and then forgot it exists. For most operators this is the highest-leverage thing they own and have never switched on.

Three honest caveats, because this one has sharp edges.

Your token list decays quietly. Tokens are reported on app start. A companion account removal reporter cleans up when a user logs out, and you should implement it at the same time. But neither fires when someone simply uninstalls the app or the operating system clears its data. So your list will always claim more reach than you have, and the gap grows with time.

On iOS there are two separate token types, and they are not interchangeable. One is for PushKit, which is now permitted only for notifying incoming calls and must produce a call screen immediately. Everything else uses the standard remote-notification token. Sending marketing through the wrong one is not a configuration mistake. It is a way to get an app rejected.

And the obvious one: this is direct marketing to subscribers, which in the EU means consent, an easy way out, and keeping a record of both. The channel is free, which makes it very easy to over-use. The fastest way to teach a subscriber to disable your notifications permanently is to send them something they did not ask for.

What the conversation covers

So when someone tells us growth has stalled, we go through four things. What subscribers actually do in the app and where they stop. What is already licensed and switched off. Whether there is a web tab worth building and charging for. And whether anyone has ever sent a push to the base.

That last question is answered with "no" more often than you would believe.

Selling through partners

One model worth knowing about if you sell to businesses rather than consumers.

A white-label owner can create sub-branded apps for their own customers using the generic bundles. Same features, same configuration, different branding per customer, so the end customer sees the service as coming from their own provider rather than from you or from us. For an operator serving many small business accounts, that turns a single app into a product line without a separate development project per client.

It changes the economics of the original purchase, and a surprising number of customers discover it a year after launch and wish they had known. Which is why it is in this article and not buried in a datasheet.

What the monthly fee is for

Since chapter one quoted the number, this is the chapter that should say what it buys.

Maintenance and updates are the obvious part: platform changes, OS releases, security work, store requirement changes, all shipped under your brand. The less obvious part is access to people who have watched a few hundred of these deployments and can tell you which of your problems are unusual and which are just Tuesday.

We would rather spend that time on the growth conversation than on tickets. A customer whose subscriber base is growing renews without thinking about it. That alignment is not altruism, and it is worth saying so plainly. A vendor claiming pure benevolence is a vendor you should read more carefully.

The end of the series

Four chapters, and if there is one thread through all of them, it is that the software was never the hard part.

The discovery call matters more than the demo. The trial is only worth what you decided to test. Launches slip on approval cycles and staffing, not on builds. And after launch the binding constraint moves out of the product entirely and into what you are selling and to whom.

Which is roughly the opposite of how softphone vendors usually pitch, feature list first. Make of that what you like.