What Your White-Label Softphone Contract (MSA) Should Cover

Short answer: a white-label softphone MSA should explicitly cover scope of service, branding and app store ownership, licensing model, SLA terms, data ownership, exit provisions, and term length. Miss any of these and you'll find out the hard way.

You found a white-label softphone vendor. The demo looked great. Now they've sent over a Master Service Agreement, and it's 18 pages of legal language that doesn't tell you what happens when things go wrong, or when you want to leave.

Most operators sign these agreements focused on what the app does. The problems show up later when they realize the contract doesn't address who owns what.

Scope of service: pin down what you're actually buying

The MSA should clearly define the deliverables. "White-label softphone" is not specific enough. Look for:

• Platforms covered: iOS, Android, or both? Desktop (Windows/Mac)?
• Feature set: voice, video, messaging, push notifications, call recording?
• Maintenance: OS update compatibility (when Apple releases a new iOS, who updates the app and how fast?)
• App store submission: who compiles, signs, and submits the app binary?

If the scope section is vague, you'll spend the contract term arguing about what's included and what costs extra.

Branding and app store account ownership

This is where operators get burned most often. Two questions matter:

Who owns the branding assets in the app? Your logo, your color scheme, your app name: these should remain your property. The vendor is licensing their technology to you, not the other way around.

Who owns the app store listing? The app should be published under YOUR Apple Developer and Google Play Console accounts. If the vendor publishes under their account, they control the listing. If you leave, they can pull it, and your subscribers lose the app.

Get this in writing. "App published under Client's developer account" should be explicit in the MSA.

Licensing models: per-seat vs. revenue share

White-label softphone vendors typically offer two pricing structures. The right one depends on your scale and growth trajectory.

Factor	Per-Seat / Per-User	Revenue Share
How it works	Fixed fee per active user per month	Vendor takes a percentage of your subscriber revenue
Predictability	High: you know the cost per user	Low: fluctuates with your revenue
Best for	Operators with steady, known subscriber counts	Startups testing the market with low upfront cost
Risk	You pay even if users are inactive	Vendor's cut grows as you scale, can get expensive
Typical range	$0.50–$3.00 per user/month	5%–15% of related revenue
Watch out for	"Active user" definition (registered vs. actually making calls?)	Revenue definition (gross vs. net? Does hardware count?)

Whichever model you choose, make sure the MSA defines the billing metric precisely. "Active user" should have a measurable definition, not a subjective one.

SLA terms: what uptime actually means

An SLA that promises "99.9% uptime" is meaningless without context. Push for specifics:

• What's covered? Provisioning server uptime? Push notification delivery? App crash rate?
• How is it measured? Monthly? Quarterly? Does scheduled maintenance count as downtime?
• What are the remedies? Service credits? Fee reductions? The right to terminate?

A softphone app depends on your SIP infrastructure, the user's internet connection, and the vendor's provisioning systems. The SLA should only cover what the vendor actually controls.

Data ownership: your subscriber data stays yours

This is non-negotiable: you own your subscriber data. The MSA should state this explicitly.

Subscriber data includes:

• User provisioning records (usernames, SIP credentials, feature flags)
• Call detail records generated through the app
• Push notification tokens
• Any analytics or usage data tied to your subscribers

The vendor may process this data to deliver the service, but ownership stays with you. If the contract says the vendor "may use aggregated data for product improvement," make sure it's truly anonymized and aggregated, not individual subscriber records.

Exit clauses and data portability

Every vendor relationship ends eventually: renewal cycles, acquisitions, pricing disagreements, or simply a better option. The exit clause is the section most operators skim and most regret. Here is what a well-drafted one covers.

Termination triggers

The MSA should define three distinct paths out:

• Termination for convenience. Either party can end the agreement by giving written notice, typically 60–90 days. No cause required. Many vendor-drafted MSAs only grant this right to the vendor, so make sure it's mutual.
• Termination for cause. Material breach (e.g., persistent SLA failure, data breach, billing errors) that remains uncured after a 30-day notice-and-cure window. Should give you the right to exit without paying an early-termination fee.
• Change of control. If the vendor is acquired, merges, or changes ownership, you should have the right to reassess the relationship, ideally with a 90-day window to terminate without penalty. Acquisitions are when vendor priorities shift fastest.

Wind-down support window

Whatever triggers the exit, insist on a 90–180 day transition assistance period during which the vendor continues to provide service at the contracted SLA while you migrate. Thirty days is not enough time to evaluate a replacement platform, configure it, test push notification delivery, and roll subscribers over.

A mobile app migration has real subscriber-visible risk, so treat it accordingly. The transition period should be written into the contract, not offered verbally as a goodwill gesture.

Data portability requirements

When the transition window opens, you need your data out in a form you can actually use. The MSA should commit the vendor to exporting:

• Subscriber provisioning records (account IDs, SIP credentials mappings, feature flags, codec preferences) in CSV or JSON with a documented schema.
• Call history and CDRs (where the vendor stores them), in a standard format with column definitions.
• Branding assets (your logo files, splash screens, color tokens) as source files, not just what's compiled into the current binary.
• Voicemail and media: if the platform stores voicemail server-side, confirm export format (WAV/MP3) and retention window post-termination.
• Customer-facing configuration: any registration wizard templates, provisioning link schemas, or custom XML profiles you built on the platform.

Push for a committed delivery timeline: 10 business days from request is a reasonable benchmark. "Available on request" with no deadline is not a commitment.

Source-code and IP considerations for OEM deals

If you signed an OEM agreement (vendor builds a custom app rather than a configured platform), the IP picture is more complicated. This white-label vs. SDK vs. in-house cost-benefit analysis compares those routes. You will not get the vendor's core source code: that is their product. But you should negotiate:

• Source-code escrow. A neutral escrow agent holds the source code for your branded build. If the vendor goes out of business or stops maintaining the product, the escrow releases the code to you. Standard in enterprise software deals; ask for it.
• Perpetual license fallback. App builds already shipped to end users should carry a perpetual license for the underlying SDK. The vendor should not be able to remotely disable apps that subscribers have already installed. This is a rug-pull and it happens.
• No kill-switch clause. Confirm the MSA explicitly prohibits the vendor from remotely deactivating already-distributed app builds during or after the transition period.

App store continuity

The scenario that keeps operators up at night: the vendor pulls the app and 40,000 subscribers lose their softphone. How this plays out depends entirely on whose developer account the app is published under.

If the app is under your Apple Developer and Google Play Console accounts (as it should be), you own the listing, the reviews, the install base, and the binary. Revoking the vendor's build access is a 10-minute task. Your subscribers receive the next update from whatever platform you migrate to through the normal app store flow. No disruption to the installed base.

If the app is under the vendor's developer account, you are at their discretion. They can unpublish the app, and your subscribers have no way to reinstall it. This single point of dependency is reason enough to walk away from a vendor who insists on publishing under their own account.

Exit checklist: what to require before you sign

1. Mutual termination for convenience with at least 60-day notice period
2. Termination for cause with 30-day cure window and no early-termination fee
3. Change-of-control right to terminate without penalty
4. 90–180 day transition assistance period at contracted SLA levels
5. Data export in documented CSV/JSON format within 10 business days of request
6. Source-code escrow (OEM deals) or perpetual license fallback for distributed builds
7. App published under your developer accounts: explicit in writing, not just verbal

Term length and renewal

Standard terms are 12–24 months. Watch for:

• Auto-renewal clauses: many contracts auto-renew for the same term length unless you give written notice 60–90 days before expiration. Mark your calendar.
• Price escalation: can the vendor raise per-seat fees at renewal? Is there a cap?
• Early termination fees: if you need out before term end, what does it cost?

How to negotiate your MSA

Most white-label vendors use template MSAs. That doesn't mean every clause is final.

1. Red-line the data ownership clause first. If they push back on you owning subscriber data, that's a red flag about the entire relationship.
2. Negotiate the exit before you need it. Vendors are most flexible on exit terms during the sales process, not when you're trying to leave.
3. Ask for a trial period. 30–60 days to validate the app against your infrastructure before the full term kicks in.
4. Get app store ownership in writing. This single clause protects your entire subscriber base.

How Acrobits handles white-label MSAs

With Cloud Softphone, our white-label softphone app for B2B, the app is published under your developer accounts.

You own your subscriber data and provisioning configuration. Setup runs approximately $5,000 with monthly fees around $600, a per-seat model with clear definitions. If you leave, your app store listings and subscriber data are yours.

We've been doing this for 18 years. The contract shouldn't be the hard part.