Top Softphone Features to Look For (Buyer’s Checklist)

Four vendors now account for 53% of total UCaaS market revenue, according to research on UCaaS market share published in March 2026. If you resell voice, that number is the whole problem in one line. Your customers spend their working day inside an app, and the logo on that app is either yours or somebody else’s. Once it is somebody else’s, the renewal conversation stops being about your service quality and starts being about their brand.

So the softphone features that matter to you are not the same ones that matter to an office manager picking a business phone app. An office manager wants call transfer and a decent contacts list. You want to know whether the app can carry your name in the App Store, whether the provisioning API can onboard 400 seats without a human, and whether the video button is included in the seat price or billed as its own line item. Those are different questions with different answers.

This page is the checklist itself, sorted into three tiers: what every vendor must have, what actually separates them, and what only matters if you are an MSP, ITSP or carrier reselling to your own base. If you want the wider buying process (requirements gathering, trials, rollout), we cover that separately in our guide to choosing a softphone for your business. What follows assumes you have already decided to sell a branded app and now need to compare white label softphone features honestly.

We are iotum. We build the white-label softphone that VoIP service providers, ITSPs and MSPs rebrand and sell as their own, so the list below is written from the vendor side of that table. Where a feature is genuinely hard to deliver, we say so.

What a White-Label Softphone Is, and When a Branded App Is the Right Call

A white-label softphone is a voice and video calling application, built and maintained by one company, that a second company rebrands and sells under its own name. The reseller supplies the brand, the customer relationship and usually the SIP infrastructure. The vendor supplies the app, the clients for each operating system, the update cycle and the back-end services that make calls actually connect on a mobile network.

Three terms get used interchangeably and should not be.

• Softphone. The client application itself: the thing running on the desktop and the phone.
• Cloud PBX. The call control layer that handles extensions, hunt groups, voicemail and routing.
• UCaaS. The commercial bundle that wraps call control, messaging, meetings and presence into one subscription.

You can buy a softphone without buying a new PBX, which is the point most softphone feature comparisons miss. Most resellers we talk to already run a switch they are happy with and only want to replace the app their customers complain about, which is why the softphone features they shortlist look nothing like an office manager’s list.

That is worth being blunt about, because a branded app is not free. You take on app store accounts, review cycles, support tickets that say “the phone rings twice” and a marketing job you did not have before. Below roughly 300 to 500 seats, and with no support desk of your own, a branded softphone is usually overhead rather than margin. Above that, the arithmetic flips fast: churn drops when the customer’s daily tool carries your logo, and you stop advertising a competitor to your own base every time somebody makes a call.

The Softphone Feature Checklist, Tiered

Long feature lists are a poor guide. One recent analysis of feature adoption found that across the average software product, a mere 6.4% of features generate 80% of all user clicks. A softphone feature comparison that scores 90 line items equally will point you at the wrong product. Weight the tiers instead.

Feature	Tier	What good looks like	How to test it in the demo
SIP registration and call control	Table stakes	Registers to your switch, survives network handover, transfers do not drop	Register a test extension against your own switch, not the vendor’s
Mobile push wake-up	Table stakes	Call rings within 2 seconds with the app closed and the phone asleep	Kill the app, lock the phone, leave it 30 minutes, then call
Desktop, iOS, Android, web clients	Table stakes	One account, same feature set, real web client	Start a call on desktop, move it to mobile mid-call
Codec and network resilience	Table stakes	Opus support, jitter buffer, graceful drop to audio	Throttle to 3G and stay on the call for five minutes
Contacts, history, voicemail	Table stakes	Server-side sync across devices	Add a contact on one device, check the other two
Full brand control	Differentiator	Your name, icon, colours, domain and store listing	Ask to see a live partner app in the public store
Video and meetings included	Differentiator	In the base price, not an add-on SKU	Ask for the price sheet with every line item
Team messaging and presence	Differentiator	Persistent, searchable, in the same app	Send a message, then restart the app
Open API and SDK	Differentiator	Public docs, sandbox, versioning policy	Read the docs before the call, not after
Multi-tenant provisioning	Reseller only	Bulk create, update and suspend by API	Provision 50 test seats without touching a UI
Zero-touch onboarding	Reseller only	User gets a link or QR, no manual SIP entry	Onboard a user from a cold install in under 2 minutes
Branded billing and usage export	Reseller only	Seat and session counters that match your switch	Reconcile a week of usage against your own CDRs
Tiered partner support	Reseller only	Named escalation path and response times in writing	Ask what happens at 2am on a Sunday
Per-tenant configuration	Reseller only	Feature flags per customer, not per platform	Turn video off for one tenant only

Tier one: the features that only lose you deals

Nothing in the table stakes row wins business. Every credible vendor claims all of it. What varies wildly is quality, and the two that break most often in production are push notification delivery and network handover. A softphone that misses calls when the phone is asleep is not a softphone, it is a liability, and it is the single most common reason an end customer asks to go back to a desk phone. Test it on a real carrier network with the app force-closed, on both iOS and Android, and do it on a weekday afternoon when the push services are busy. No other item on a list of top softphone features matters if this one is shaky.

The second is handover. Somebody walks from office wifi to LTE mid-sentence. A good client re-registers and keeps the media flowing; a bad one drops the call and takes ninety seconds to come back. Ask any vendor to demonstrate this live rather than describing it.

Tier two: where products actually differ

This is where a softphone feature comparison earns its keep. Brand control, whether video and meetings sit in the base bundle or behind an add-on, the depth of team messaging, and the quality of the API are the four axes where two products that look identical on a spec sheet turn out to be very different businesses to run.

We put video, team messaging, webinars and file sharing in the base product rather than selling them as separate SKUs, because the reseller economics fall apart otherwise. When a service provider has to add a line item every time a customer wants a video call, they either eat the cost or run an awkward upsell conversation with an account they already won. Bundling is itself one of the white label softphone features worth scoring, because it changes your margin model rather than the end user’s experience.

Tier three: the features nobody outside the channel asks about

Provisioning, billing reconciliation, per-tenant configuration and partner support are invisible to end users and decisive for resellers. They are also the features vendors are least likely to demo unprompted, because they are unglamorous. Ask for them by name. We go through each one further down.

Branding: What White Label Actually Gets You

“White label” covers at least five distinct depths of branding, and vendors rarely say which one they sell. Of all the softphone features to look for, this is the one where the marketing language and the engineering reality drift furthest apart. When you assess branding options for a white-label softphone app, work down this list and get a yes or no on each.

• Skin and logo. Your colours, your wordmark, your icon inside the app. This is the shallowest layer and every vendor offers it.
• Your own domain. The app, its web client and its admin portal live on a hostname you control, such as app.yourcompany.com, rather than on the vendor’s domain. Partners on our platform run on their own child domains for exactly this reason.
• Your own app store listing and bundle ID. The app is published under your developer account, with your privacy policy, your support URL and your bundle identifier. This is the line between a re-skinned app and a genuinely separate product. It also means you own the reviews and the install base rather than borrowing them.
• Your own push and signing certificates. Push credentials sit under your Apple and Google accounts. This matters more than it sounds: it determines who can break your notifications during a certificate rotation.
• Your own telemetry. Any analytics running inside the app report to a property you own.

That last one is worth dwelling on, because it is the one of these softphone features buyers forget to check and the one that embarrasses everybody when it surfaces. Our white-label configuration has a field for the partner’s own analytics ID, and on a call in July 2025 our team went through the reports and found that partners who leave that field empty end up with telemetry defaulting to the parent property. One of our team put it plainly on that call: it kind of violates the whole white label premise. A customer who opens developer tools on their branded meeting app and finds somebody else’s tracking code has just learned something you did not want to teach them. So the practical test is boring and effective: open the web client, view source, and see whose measurement ID is in there. Do the same for the mobile app’s network calls if you can.

Dual branding is the related term you will see on comparison pages. It means the same underlying platform is sold under two names at once, usually the platform vendor’s and the reseller’s. We do this openly: our video product is also sold through the NetSapiens ecosystem as NetSapiens Premium Video, with billing consolidated onto the partner’s existing invoice. Dual branding is fine as long as you know it is happening and it is your name facing your customer, and it does not change the softphone features underneath. It stops being fine when the vendor’s name appears in your customer’s app store listing, in the email headers, or on the support page your users are directed to when something breaks.

One honest caveat on branding depth: a separate store listing means separate app review, and Apple and Google review branded VoIP clones with some suspicion. Ask the vendor how many partner apps they currently have live in the public stores and how long the last submission took. A vendor who has done it fifty times has a submission playbook. A vendor who has done it twice does not.

API and SDK Quality: How to Judge It Before You Commit

Buyer questions about softphone features have shifted from “do you have an API” to “is the API any good”, which is a much harder thing to fake. Three delivery models exist, with three very different costs.

• A ready-made branded app. The vendor ships the client; you configure it. Fastest to launch, lowest engineering cost, least control over the interface.
• An API. Your systems talk to the platform over HTTP for provisioning, user management, call data and webhooks. You keep your own portal and automation, and the calling app stays the vendor’s.
• An SDK. You embed calling and video into your own application. Maximum control, and the only route if the softphone has to live inside a product you already ship. It is also the route that needs mobile engineers on staff, indefinitely, not just at launch.

Judging API quality before you sign is mostly a documentation exercise, and you can do it in an afternoon without talking to sales. Look for public reference docs you can read without an NDA, a sandbox you can get into without a demo call, a published versioning and deprecation policy, webhooks rather than polling for call events, documented rate limits, and a changelog with dates on it. A changelog is the single most useful artefact: it tells you whether the platform is maintained weekly or annually, and it tells you how much notice you will get before something you depend on changes.

Ask two more questions that rarely appear on a published softphone feature list. First, can you provision, suspend and delete a user entirely through the API, or does suspension still need someone in an admin console? Suspension by API is what lets you automate non-payment. Second, does the API expose call detail records in something you can reconcile against your switch, or only a dashboard you have to read with your eyes? Our APIs and SDKs cover video, voice, real-time messaging and streaming, and the provisioning and analytics surfaces are the ones service providers ask about first.

For context on how much of this market is now sold as a service rather than built: worldwide UC and collaboration revenues reached $69.2 billion in 2024 on 7.8% year-over-year growth, per IDC’s tracker for the worldwide collaboration market. Almost none of that is companies writing their own SIP stacks, which is why choosing softphone features has largely replaced building them.

What MSPs and ITSPs Should Prioritize That End Users Never Ask About

This is the section that separates a reseller’s checklist from a buyer’s guide. When we ask what features to prioritize in a white-label UCaaS for MSPs, the answers cluster around five things, none of which an end user has ever requested.

• Multi-tenant provisioning. You need to create, modify, suspend and delete users across many customers from one place, by API and in bulk. If onboarding a 200-seat customer means 200 form submissions, the product does not scale past your first big win.
• Zero-touch onboarding. The end user should install the app, tap a link or scan a code, and be registered. Nobody should be typing a SIP password into a phone. Ask specifically how credentials reach the device and whether the link expires.
• Billing that matches your switch. MSPs and PBX providers license numbers to their customers and bill by seats or by concurrent sessions. If the softphone counts seats differently from your switch, every invoice becomes an argument. Ask for a usage export you can reconcile against your own CDRs before you sign, not after.
• Per-tenant feature control. One customer wants recording off for compliance reasons. Another wants video disabled to save bandwidth. If features are platform-wide flags rather than per-tenant, you will be saying no to reasonable requests for years.
• A real partner support tier. Named escalation path, response times in writing, and a clear answer about who handles a Sunday night outage. These are the softphone features nobody demos unprompted. Ask what the vendor does when Apple changes push behaviour in a point release, because that will happen.

Push notification infrastructure deserves a line of its own here, because it is a feature and not an afterthought. The vendor operates a push gateway between your SIP switch and Apple and Google. Its reliability is not something you can fix from your side, and it is the difference between an app that rings and an app that gets uninstalled. Ask who runs it, whether the certificates sit under your developer account, and what the delivery monitoring looks like.

Everything on this list is aimed at the same outcome: adding a branded softphone to an existing base without adding headcount. That is why our service provider platform is built to sit on top of the PBX a partner already runs rather than replacing it.

Call Recording, Analytics and Compliance Features

Call recording is where a shallow softphone feature comparison does the most damage, because every vendor ticks the box and the box hides four separate decisions.

• Where recordings are stored. Vendor cloud, your cloud, or your own S3-compatible bucket. If you serve regulated customers, this is a contract question before it is a technical one.
• Retention and deletion. Can retention be set per tenant, and does deletion actually delete, including from backups, within a stated window?
• Consent and announcement. Two-party consent states and several countries require an announcement. Ask whether it is configurable per tenant and per direction.
• Access to the recording itself. Is there an API to fetch a recording by call ID, or only a web player? You will need the API the first time a customer asks for a year of audio for an audit.

Analytics splits the same way. A dashboard is table stakes. What a reseller needs is an analytics API that returns call quality metrics, MOS scores, registration failures and usage per tenant in a format you can pull into your own reporting. Quality data is also your best support tool: when a customer says calls are bad, packet loss numbers per leg end the conversation in ten minutes instead of a week.

On compliance, treat certifications as buyer education rather than marketing. Ask any vendor to confirm their current certifications in writing, with scope and dates, and ask specifically which parts of the stack are covered. Our video and communications platform is built for HIPAA-compliant deployments, which is why healthcare and telehealth providers are one of our larger segments, and the same encryption and access-control features underpin the softphone. If a vendor will not put the scope in writing, that answer is itself informative, and it tells you more than any list of top softphone features on their site.

SIP Switch Compatibility and CRM Connectors

“Works with any SIP switch” is a claim worth interrogating, because the honest answer is: mostly, with caveats. Basic registration and calling are standardized and will work almost anywhere. The features buyers actually care about are not. Presence, BLF, shared line appearance, park orbits, call queues, voicemail message-waiting indicators and provisioning APIs are all implemented differently by each platform, and a softphone gets those by integrating with the switch specifically, not by speaking generic SIP.

So the useful question is not “does it support SIP” but “which switches have you integrated deeply, and which softphone features work on mine”. Ask for the list. Ask which features degrade on an unlisted platform. Our own softphone runs on top of the NetSapiens PBX as an add-on, which is deliberate: partners keep the back end they already operate and their customers get a different front-end experience, with no rip and replace of the infrastructure their base is already provisioned on.

Buyers already shop this way, and it is more literal than most vendors realise. In February 2026 our marketing lead came off a call with a new customer and asked him how he had found us. He had asked ChatGPT for Acrobits softphone alternatives that connect with NetSapiens, and we came up. Not “best softphone”. Switch compatibility first, brand second. If you are evaluating vendors, run the same query with your own switch name in it and see who can actually answer. Compatibility is a filter applied before anybody reads a feature list.

CRM connectors follow the same rule and belong on any list of softphone features to look for. Click-to-dial and screen pop for Salesforce or HubSpot are usually native; anything else is a webhook and some work. Confirm which direction the integration runs, whether call outcomes write back to the CRM record, and whether the connector is maintained by the vendor or was a one-off project. We go through the practical side of this in our guide to connecting a softphone to your CRM.

Comparing Features and Price Without Getting Burned by Add-On Costs

Add-on pricing is the live concern in this category and it deserves a direct answer rather than a dodge. The pattern is consistent across the market: a low headline per-seat price, then separate line items for video, for meetings above a participant threshold, for recording, for recording storage, for SMS, for the push gateway, for API access above a call ceiling, and sometimes for the branded app build itself as a one-off fee. Each one is defensible on its own. Stacked, they can double the number you put in your own pricing model, and they make a softphone feature comparison across two vendors almost meaningless unless you normalise for them.

Build a landed cost per seat before you compare anything. Take a real customer profile, say 100 seats with 30% using video weekly and 10% recording every call, and ask each vendor to price that exact profile with every line item shown. Then ask three follow-ups: what changes at renewal, what the overage rate is, and whether the branded app build is charged again when you rebrand or when the vendor ships a major version.

The build-versus-buy comparison sits underneath all of this. Writing your own client means native iOS and Android development, a media stack, a push gateway, app store maintenance and a permanent mobile team, which is why the total is measured in hundreds of thousands of dollars per year rather than per seat. We broke the arithmetic down in the real cost of developing a softphone. For most service providers the decision is not build versus buy, it is which white-label softphone features justify the difference in per-seat price.

Our own answer to add-on pricing is to include the pieces most resellers end up needing anyway, softphone, video, messaging, webinars and file sharing, in the base offering, so the price you model in month one is the price you defend in month eighteen.

Feature Gaps to Check When You Replace an Incumbent

Most of these evaluations are replacements, not greenfield builds. If you are already selling an app from Acrobits, Bria, Zoiper or another established client, the features that matter are the ones that break during migration.

• Provisioning file compatibility. Your existing provisioning flow probably emits a config format the old client understands. Ask whether the new vendor can consume it or whether every user needs re-onboarding.
• Contact and history migration. Local contacts and call history usually live on the device. Confirm what carries over and what does not, then tell your customers in advance rather than after.
• App store transition. If the incumbent app was published under the vendor’s account and the new one is under yours, users install a new app rather than receiving an update. Plan the comms for that.
• MDM and enterprise deployment. Larger customers push apps through Intune or Jamf. Check that managed configuration is supported and that the new bundle ID is added to their allowlists.
• Feature parity on the long tail. Park, page, intercom, BLF and shared lines are the features that get noticed only when they disappear. Take an inventory of what your top ten customers actually use before you switch.

Run the migration on your own internal extensions for a fortnight before you touch a customer. It is the cheapest insurance available, and the list of features in a business softphone that you find yourself missing during those two weeks is a better requirements document than anything a vendor will hand you.

Frequently Asked Questions

What is the difference between a white-label softphone and a white-label UCaaS platform?

A white-label softphone is the branded client application your customers install and use to make calls. A white-label UCaaS platform is the whole commercial stack behind it: call control, messaging, meetings, admin portal and billing, all rebrandable. You can add a branded softphone to a PBX you already run without replacing the platform underneath it.

Can a white-label softphone work with any SIP switch?

Basic registration and calling will work with almost any standards-compliant switch. Deeper features such as presence, BLF, shared lines, call parking and automated provisioning depend on a specific integration with that platform, so they vary by vendor. Ask for the list of switches with a certified integration and ask exactly which features degrade on anything outside it.

What features do MSPs need that a standard softphone does not have?

Three, mainly: multi-tenant provisioning that creates and suspends users in bulk through an API, branded billing with seat and session counters you can reconcile against your own switch records, and tiered partner support with a named escalation path. None of them are visible to end users, and all three decide whether the product scales past your first large account.

Should I choose an SDK or a ready-made branded app?

If you have mobile engineers on staff permanently and the calling experience has to live inside a product you already ship, take the SDK. If you are a service provider whose job is selling and supporting connectivity rather than maintaining iOS releases, take the ready-made branded app and spend the engineering budget on provisioning automation instead. The middle path, a branded app plus an API for provisioning and billing, covers most resellers.

How do I compare softphone features and pricing fairly?

Model one real customer profile, then make every vendor price that profile with all line items visible, including video, recording, storage, SMS and any one-off branded build fee. Compare the landed cost per seat, not the headline price, and ask what changes at renewal.

Key Takeaways

• Weight the tiers, do not count the features. A small fraction of features drive most real usage, so a flat scorecard will point you at the wrong product.
• Push reliability and network handover are the two table-stakes features that actually break. Test both on a real carrier network with the app closed.
• Branding has five depths. Skin, domain, store listing and bundle ID, push certificates, and telemetry. Check whose analytics ID is inside the app before you sign.
• Judge the API from the docs, the sandbox and the changelog, not from a sales answer. Suspension by API and reconcilable call records are the two capabilities resellers miss most.
• The reseller-only features decide scale. Multi-tenant provisioning, zero-touch onboarding, billing that matches your switch, per-tenant flags and a named support escalation.
• Price a real customer profile with every line item exposed. Add-on stacking, not the headline seat price, is what breaks a reseller’s margin model.
• Plan the replacement, not just the purchase. Provisioning formats, contact migration, a new store listing and MDM allowlists are where migrations actually hurt.

The pattern across every deal we work on is the same: the features that win the evaluation are end-user features, and the features that decide whether the business works two years later are provisioning, billing and brand control. Score both, and weight the second group higher than instinct suggests.

If you are weighing softphone features for a branded app of your own, the iotum Communicator is the white-label softphone and UCaaS suite that VoIP service providers, ITSPs and MSPs resell under their own name, with softphone, video, messaging and webinars in one product. Book a demo and bring your switch details; the useful part of the conversation starts there.