Choosing the Right VoIP Platform for the Client

The MSP's Guide to VoIP: Part 5 of 20

We all have a default. The platform we know inside and out, the one we can deploy in our sleep, the one whose quirks we have memorized. There is nothing wrong with having a go-to. The problem starts when every client gets that go-to regardless of whether it actually fits.

Choosing a VoIP platform for a client is not about what you are most comfortable supporting. It is about what serves that particular business best given their size, their workflows, their compliance obligations, and their budget. Sometimes the right answer is a hosted UCaaS seat. Sometimes it is an Asterisk box in a closet. Sometimes it is telling the client their current system is fine and they should stop looking for something new.

This article walks through the decision process from the client's perspective, not yours.

Start With the Client, Not the Platform

Before you even open a vendor's pricing page, you need to understand the client. Not just how many phones they need, but how their business actually uses voice communication. Sit down with someone who answers the phone all day, not just the owner or the IT contact.

Here is what you need to map out before making any recommendation:

Organization size and growth trajectory. A five-person office that has been five people for a decade is different from a five-person startup planning to hire thirty people this year. The platform needs to fit today and tomorrow without requiring a forklift upgrade.

Call volume and patterns. Some businesses live on the phone. Call centers, medical offices, law firms with heavy client contact. Others might make ten calls a day and mostly use email. High call volume demands reliability and call quality in ways that light usage does not. Understanding call patterns also matters. A business with heavy morning call volume and dead afternoons has different capacity planning needs than one with steady traffic all day.

Feature requirements. Do they need an auto attendant? Call recording? A call center queue with reporting? CRM integration? Video conferencing built in? SMS? Fax? Make a list of what they actually use today and what they wish they had. Be specific. "We need call recording" might mean they record every call for compliance, or it might mean a manager occasionally wants to review a support interaction. For clients with complex call routing needs, sketching the flow in an IVR planner during discovery helps surface requirements that a verbal conversation misses.

Compliance and regulatory needs. Healthcare clients need HIPAA-compliant call recording and messaging. Financial services clients may need MiFID II or Dodd-Frank compliant recording with tamper-proof storage. Legal firms may need attorney-client privilege considerations around call recording policies. If compliance is in play, it narrows your options significantly and you cannot cut corners.

IT sophistication on the client side. Some clients have an internal IT person who can handle basic phone admin: adding users, changing call routing, updating a greeting. Others will call you every time someone new starts. This affects whether you recommend a platform with a simple admin portal or one that requires CLI knowledge to manage.

Multi-site considerations. A single-office business is straightforward. Multiple offices, remote workers, and hybrid arrangements all add complexity. Can remote workers use softphones? Do branch offices need local survivability if the internet goes down? Does the receptionist need to see presence across all locations?

Budget reality. Not budget aspiration, budget reality. What are they spending today? What are they willing to spend? A hosted seat at twenty-five dollars per user per month is great until you multiply it by two hundred users and the client realizes that is sixty thousand dollars a year. On-prem has higher upfront cost but potentially lower ongoing cost at scale.

The Hosted vs. On-Premises Decision Tree

Once you understand the client, the first major fork in the road is hosted versus on-premises. Here is how to think about it.

Hosted (UCaaS) tends to be the right call when:

• The client has fewer than fifty users (though this is not a hard cutoff)
• They want predictable monthly costs with no capital expenditure
• They have remote or hybrid workers who need the same experience as office workers
• They do not have and do not want to hire internal IT staff for phone management
• They need the platform to scale up or down quickly
• They want built-in redundancy without having to architect it themselves
• Their feature needs are mainstream: auto attendant, voicemail, basic call routing, maybe a small call queue

On-premises tends to be the right call when:

• The client has a large user count where per-seat pricing becomes expensive
• They have strict data sovereignty or compliance requirements that make cloud hosting complicated
• They need deep customization that hosted platforms do not offer
• They have reliable internal IT or an MSP (you) willing to commit to ongoing management
• They are in a location with unreliable internet and need the phone system to work during outages
• They have complex integrations with internal systems that require low-level API access
• Call volume is extremely high and per-minute or per-seat costs would be prohibitive

The hybrid middle ground is increasingly common: an on-premises system that connects to SIP trunking services for external calling, or a hosted platform with local survivability appliances at each site. Do not think of it as binary.

Evaluating Hosted Platforms

If you are going the hosted route, here is what to evaluate. And evaluate means actually testing, not just reading the marketing site.

Reliability Track Record

Ask for uptime numbers, but also check independent sources. Search for outage reports. Ask the vendor what happened during their last major outage and what they changed afterward. A vendor that claims 99.999% uptime but had a four-hour nationwide outage last quarter is not being straight with you.

Look at their architecture. Do they have geographically distributed data centers? What happens if one region goes down? Do they have a published status page with historical incident data?

Feature Set

Map the client's requirements list against the platform's actual capabilities. Do not trust the feature comparison matrix on the vendor's website, because those are designed to make every box look checked. Get a trial account and test the specific features the client needs.

Pay special attention to how the platform handles SIP and media negotiation. Some hosted platforms use proprietary protocols between their endpoints and translate to SIP only at the edge. This can cause compatibility issues with third-party devices and SIP trunks.

API Availability and Integration Ecosystem

If the client needs CRM integration, check whether the platform has a native integration or just a webhook that requires custom development. Native Salesforce integration that syncs call logs automatically is different from a generic webhook that fires on call events and requires you to build the rest.

Look at the API documentation. Is it well-documented? Is there a sandbox environment? Are there rate limits that would be a problem? A good API is a sign that the vendor takes the platform seriously as a business tool, not just a phone service.

Support Quality

This matters more than most MSPs realize, because when something goes wrong at 2 AM and you cannot fix it yourself, vendor support is your lifeline. Test the support experience during your evaluation. Open a ticket with a moderately technical question and see how long it takes to get a useful response. Try their phone support. Ask to speak with someone from their partner engineering team, not just tier-one support.

Some vendors have dedicated MSP/partner support channels that are dramatically better than their end-user support. If those exist, make sure your partnership tier includes access.

Pricing Model

Hosted platform pricing generally falls into a few categories:

Per seat, flat rate. You pay a fixed amount per user per month and get unlimited domestic calling. Simple to budget, but can be expensive at scale. Watch for what is included versus add-on, since some vendors charge extra for call recording, call queues, or analytics.

Per seat plus per minute. Lower per-seat cost but you pay for call minutes. This works for light-usage businesses but can get expensive for heavy callers. Make sure you understand whether inbound, outbound, or both are metered.

Blended or tiered. Different user tiers at different price points: a basic user who just needs a phone, a standard user with voicemail and basic features, a power user with call center capabilities. This can save money if the client has a mix of usage patterns, but it adds billing complexity.

Contract terms matter too. Month-to-month gives flexibility but usually costs more. Annual contracts lock in pricing but create switching costs. Multi-year contracts with aggressive discounts can trap you if the platform does not work out. Push for annual with a meaningful out clause rather than multi-year.

Evaluating On-Premises Platforms

If the decision tree points toward on-prem, you have a different set of choices to make.

Open Source: Asterisk vs. FreeSWITCH

Asterisk is the grandfather of open-source telephony. Massive community, enormous ecosystem, well-understood. If you are building a traditional PBX with standard call routing, voicemail, IVR, and conference bridges, Asterisk is proven. FreePBX provides a web GUI on top of Asterisk that makes administration manageable for most common tasks.

The trade-off is that Asterisk's architecture shows its age in some areas. It was designed as a PBX first and a general-purpose telephony engine second. High-density call processing and complex media manipulation can push its limits.

FreeSWITCH is more of a telephony engine than a PBX out of the box. It handles high call volumes more efficiently than Asterisk in many scenarios and has a more modern architecture for media processing. But it requires more expertise to deploy and configure. The community is smaller. Finding a FreeSWITCH consultant is harder than finding an Asterisk consultant.

Choose Asterisk if the client needs a PBX and you want a large support community. Choose FreeSWITCH if you need high-density call processing, a SBC, or a platform for custom telephony applications.

Commercial On-Premises

3CX has become a popular choice for MSPs because it is relatively easy to deploy and manage. It runs on Linux or Windows, supports a wide range of SIP phones, and includes a decent web client and mobile apps. Licensing is per-simultaneous-call rather than per-user, which can be cost-effective for businesses where not everyone is on the phone at the same time. The downside is that you are dependent on 3CX's licensing model and roadmap, and they have made significant licensing changes in the past that caught partners off guard.

Grandstream UCM series is a hardware appliance approach. Relatively inexpensive, straightforward to deploy for small to mid-size businesses. The UCM6304, for example, handles up to 1500 users and 200 concurrent calls. The limitation is that you are locked into Grandstream's firmware update cycle and feature set. Customization beyond what the GUI offers is limited.

Other commercial options like Sangoma (which now owns FreePBX and offers commercial modules), Yeastar, and Zultys each have their niches. Evaluate them the same way: test actual features, check the support experience, understand the licensing model, and make sure the platform can grow with the client.

Hardware and Infrastructure Requirements

On-premises means you are responsible for hardware. For a small deployment, a modest server or even a virtual machine will do. For larger deployments, consider:

• Redundant power supplies and UPS
• RAID storage for call recordings
• Adequate CPU and RAM for concurrent call capacity (with headroom for growth)
• Network interface redundancy
• A maintenance contract for hardware failures

If the client does not have a proper server room with climate control and backup power, an on-prem phone system is going to have reliability problems that no amount of software configuration can fix.

Ongoing Maintenance Commitment

This is where many MSPs underestimate the on-prem burden. You are committing to:

• Security patches and firmware updates
• Certificate renewals for TLS/SRTP
• Monitoring for service health and call quality
• Backup and disaster recovery testing
• Capacity planning as the client grows
• Troubleshooting codec issues, SIP registration problems, and oone-way audio
• Staying current with the platform's development roadmap so you are not caught off guard by breaking changes

Build these ongoing costs into your managed services agreement. If you are charging a flat monthly fee for phone system management, make sure it reflects the actual time you will spend. Too many MSPs sell on-prem phone systems at a healthy project margin and then lose money maintaining them for years afterward.

When to Recommend Keeping the Existing System

This might be the most important section in this article. Sometimes the right recommendation is to leave things alone.

The current system works and meets their needs. If the client has a phone system that is functioning, their users are not complaining, and it does everything the business requires, there is no reason to replace it just because it is old or because you do not support that platform. Help them maintain it or find someone who can.

The switching costs outweigh the benefits. Every migration has costs beyond the price of the new system: user retraining, temporary productivity loss, number porting delays, integration rework, and the inevitable problems that surface in the first few weeks. If the new system's benefits are marginal, those switching costs may not be justified.

The client is in a transitional period. If they are about to move offices, go through a merger, or significantly change their workforce size, now is a bad time to deploy a new phone system. Wait until the dust settles and you can size the solution properly.

Their real problem is not the phone system. Sometimes clients blame the phone system for issues that are actually network problems, internet bandwidth limitations, or SIP trunking configuration issues. Before recommending a platform replacement, do the diagnostic work to identify the actual root cause. A new platform sitting on the same bad network will have the same problems.

You cannot adequately support the replacement. If the best platform for this client is one you have no experience with and no bandwidth to learn, recommending it and then struggling to support it helps nobody. Either partner with someone who has the expertise, invest in training before the deployment, or be honest that this particular project is not a fit for your shop.

Building Your Evaluation Framework

Rather than evaluating platforms ad hoc for every client, build a repeatable framework:

1. Client discovery questionnaire. Standardize the questions you ask every prospect. Cover all the factors listed above: size, call volume, features, compliance, IT sophistication, multi-site, budget. Write it down so you do not forget anything and so every technician in your shop asks the same questions.

2. Platform scoring matrix. Create a weighted scorecard that maps client requirements to platform capabilities. Weight the scores based on what matters most to this specific client. Compliance support might be heavily weighted for a healthcare client and irrelevant for a retail shop.

3. Reference deployments. Maintain a list of your own successful deployments by platform and client profile. When a new prospect matches a profile you have already served, you can draw on that experience and potentially reference the existing client.

4. Total cost of ownership calculator. Build a spreadsheet that models three-year and five-year TCO for hosted versus on-prem, including your labor costs for ongoing management. Show the client real numbers, not guesses.

5. Migration playbook. For each platform you support, document the migration process step by step. This reduces the risk of the deployment going sideways and lets you give the client a realistic timeline.

Your platform choice affects your regulatory position. Before committing to a platform and service model, understand your FCC obligations as described in Parts 17 through 20 of this series. The difference between reselling a hosted platform under a wholesale provider's authority and deploying your own PBX with direct trunking has significant regulatory implications that should factor into your evaluation. Consult a telecom attorney before signing any wholesale or trunking agreement.

Avoiding the Comfort Zone Trap

The temptation to recommend what you know is strong, and it is not entirely irrational. You can deploy a familiar platform faster, support it better, and troubleshoot it more efficiently. All of that matters.

But it does not matter as much as getting the client the right solution. A platform you can deploy in four hours that does not meet the client's needs is worse than one that takes two weeks but actually works for them.

The way to reconcile this tension is to build depth in two or three platforms that cover different client profiles. Maybe you have a hosted UCaaS platform for small to mid-size clients with standard needs, an on-prem solution for larger or compliance-heavy clients, and the ability to support clients who want to keep their existing system. You do not need to be an expert in everything, but you need enough range to match the right tool to the job.

If a client's needs fall outside your range, the professional move is to say so and help them find someone who can serve them. That honesty builds more trust than forcing a square peg into a round hole and hoping they do not notice.

The Recommendation Conversation

When you present your recommendation to the client, walk them through your reasoning. Show them the decision tree, not just the conclusion. Explain why hosted makes sense for them, or why on-prem is the better fit, or why their current system deserves to stay.

Clients who understand the reasoning behind a recommendation are more confident in the decision, more patient during deployment, and more likely to refer you to others. Clients who are just told "you should use Platform X" without context will second-guess the choice at the first sign of trouble.

Be transparent about trade-offs. Every platform has downsides. If you pretend otherwise, you lose credibility when those downsides surface. If you name them upfront, the client is prepared and you look honest.

The goal is not to sell a phone system. The goal is to solve a communication problem in a way that makes the client's business work better. Sometimes that is a shiny new UCaaS deployment. Sometimes it is a firmware update on the box they already have. Either way, you did the right work and made the right call.

Next up: The Internet Connection Conversation