Most CSPs already have a softphone somewhere in their portfolio. Likely, however, some time in the past few years, it stopped being a differentiator and instead became a mere checklist item. When it comes to evolving technologies like this one, at some point companies are meant to move on from asking “do we have a softphone?” to “is it still a good softphone?” Unfortunately, that second question is the one almost nobody thinks to ask. It’s true that finding and sourcing an alternative is a cost. But few businesses fully realize the cost of standing still.
That reality is that a good softphone isn’t a product that passed a checklist on launch day. It’s one that its creator – in other words, your vendor – continually evolves. Let’s take a walk through what this looks like in practice.
The Competition Isn’t Other Softphones
Ask a user what a good calling app feels like, and they won’t describe a PBX feature. They’ll describe WhatsApp, Telegram, Messenger, FaceTime. These are apps that show presence without being asked, let you switch from a call to a chat without opening another app, and ship something new often enough that using an older version feels slightly off before you can say why.
That’s why a softphone that only compares itself to other softphones is benchmarking against the wrong opponent. The app that a subscriber already has open in another tab is the real comparison that a softphone is actually measured against.
Bought Once, Judged Once
A lot of providers treat their softphone like a stapler. They buy it, it works, they stop thinking about it. Once they’ve deployed it, they give it a line in the sales deck and then it just sits there. Nobody circles back months later to ask whether it still holds up against what subscribers have since become used to.
That’s how a perfectly good softphone quietly becomes a dated one. It happens without anything breaking, crashing, or throwing an error. Your product just slowly slips under the line of what “normal” looks like to the person using it. By the time you notice the gap, it’s already been far too wide for a far too long.
The Red Queen Problem
There’s a line from the classic novel Through the Looking-Glass that describes this better than any softphone comparison chart. That line is: It takes all the running you can do, to keep in the same place.
While this may seem like a odd narrative connection to make, it’s literally what’s happening. OTT apps ship weekly, while Apple and Google change platform rules, push certificates, switch background execution limits, and update TLS requirements on their own schedule, whether or not a vendor is ready. Plus, the way people communicate keeps shifting. You can see this evidenced in fewer answered calls, more texts, and more distrust of unknown numbers. None of these changes in consumer behaviour pause to wait for a softphone vendor to catch up.
Softphones metrics do not stand still. That means you can’t stand still either. Unless, that is, you are comfortable with falling behind.
So What Makes a Softphone a Good Softphone?
A good softphone requires a vendor that is continuously and actively building it. They’re watching the platforms, what OTT apps normalize, and what subscribers are expecting, rather than shipping it once and calling it finished.
Before any of that shows up as a feature a subscriber notices, vendors must consider several structural issues. Get these wrong, and no amount of feature-shipping fixes it later. You have to consider:
- Whether it’s built on WebRTC or an older client-server model: This is the difference between a softphone that lives inside the browser tab a subscriber already has open, and one that asks them to install something first. We’ve written before about why WebRTC has quietly become the default way business calling gets delivered. It’s the same reason a softphone can try to compete with solutions like WhatsApp instead of with other PBX clients.
- Whether calls actually reach a locked, backgrounded phone: A call that never rings because iOS or Android decided the app was asleep isn’t a minor bug, it’s the whole product failing at the one job it has. We’ve gone deep on the push notification architecture that makes this reliable, because solving the “does it ring?” problem turns out to be a harder engineering problem than it sounds.
- Whether deployment can move with the customer, not just the vendor’s roadmap: A provider that lands a healthcare or government contract can suddenly need on-premise instead of cloud, or both at once. A softphone that only does one is a softphone that quietly rules out deals before the conversation even starts. We’ve covered when on-premise beats cloud for exactly this reason.
Don’t Forget the Unglamorous Tasks It Requires to Make a Good Softphone
On top of that, staying competitive involves a lot of what you might call “grunt work”:
- Reading platform announcements before they become outages: Google gave the industry roughly six months’ notice before a recent TLS certificate change took effect. A vendor that’s paying attention treats that as a deadline to plan around, not a surprise to react to later.
- Running app updates through proper review, not shortcuts: A mobile release goes to Apple and Google for review, followed by internal testing before general availability. The goal is to prevent a rushed release that violates a store policy and gets pulled from the store without warning.
- Making updates boring for the provider: If the softphone runs as a service, a platform update shouldn’t be a project the provider’s team has to staff. It should be a heads-up about a short maintenance window and not a weekend lost to a backend migration.
The cost of skipping can have real consequences. An app that misses a store requirement gets removed from the store. A softphone that doesn’t handle a platform change in time simply stops connecting calls. There’s no warning screen for that moment. So, the phone just stops ringing, and the subscriber goes looking for whoever’s phone still works. To get it right, there has to be a human in the loop because apps and robots are not responsible for the service, making the decisions, or taking care of the running service.
What Good Softphone Development Looks Like
At PortaOne, we can’t afford to treat PortaDialer as finished, because the market it competes in doesn’t stand still either. So, we keep on building it, on top of the calling basics that our clients and prospects expect every softphone to have. Think: HD voice and video calls, call transfer, voicemail, encryption, sending SMS, chats… all of which are today’s baseline, not the pitch. What we keep adding is the part that keeps it in step with what OTT apps have normalized. (And what subscribers now expect by default.)
Below are some of the features that have shipped most recently:
On mobile:
- Presence: See who’s online before calling, the way you’d check before messaging someone on any chat app.
- BLF (Busy Lamp Field): See who’s actually on a call right now, so a transfer doesn’t land on someone mid-conversation.
- Call Pull: Move an active call from desk phone to mobile, or web to mobile, without dropping it or the other party noticing anything happened.
In the web app:
- Chats: The same instant messaging already in the mobile app, now in the browser. Text and voice live in one place instead of two.
- Voicemails: Read and play voicemail from the browser, without dialing into a menu.
- Call Waiting: Hold one call and answer another, or start a second, without the second caller hitting a busy signal.
- Caller ID Selection: Pick which company number shows up before dialing out, so someone handling multiple brands or regions always shows the right one.
None of this is the finish line. It’s this quarter’s version of keeping in step. And inevitably, there will be a next one.
“Good” Means Nobody’s Talking About It
Nobody praises a browser for opening, nor do they thank a calculator for getting the sum right. A softphone that’s actually good works the same way. It rings, the text sends, the transfer goes through, and nobody notices it, because it just works.
That’s the target, and it’s a moving one. Rather than fulfilling a longer feature list than the last competitor’s, a softphone must keep evolving fast enough to stay exactly where a subscriber expects it to be.
Want to see where PortaDialer is running toward next? Book a demo.
Want to learn more? Find out why a web dialer removes the onboarding friction in a way that mobile app can’t. We admit that it’s a different question from the one this post is answering, but it’s one we think is worth asking.