Vendor Relationships: Working With Hosted Providers and Trunk Carriers

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

At some point in every voice engagement, you will determine that the problem is not on the client's network, not in the local equipment, and not in anything you control. The problem is on the provider's side. Maybe it is the hosted PBX platform. Maybe it is the SIP trunk carrier. Maybe it is somewhere in between. And now you need to get someone else to fix it, on someone else's timeline, while your client is staring at you expecting resolution.

This is one of the hardest parts of running a voice business. You are accountable to the client for the entire voice experience, but you do not control every piece of the infrastructure. Your ability to get providers to investigate and resolve issues quickly, with minimal back-and-forth, is a skill that directly affects your client satisfaction, your support costs, and your sanity.

This post is about building that skill. Not the soft stuff about "being nice to vendors" (though that matters too), but the practical mechanics of getting problems solved when the problem is not yours to solve directly.

The information problem

The single biggest reason provider tickets drag on is insufficient information in the initial report. A ticket that says "client is experiencing poor call quality" gives the provider nothing to work with. They will respond with a request for more details, which you will provide, which they will use to ask more questions, and three days of back-and-forth later you still have not gotten to the actual investigation.

Compare that to a ticket that arrives with everything the provider needs to start investigating immediately. The difference in resolution time is measured in days, not hours.

Here is what a well-constructed provider ticket looks like for a voice quality issue:

Account and site identification. Your account number, the client's site, the specific trunk group or service instance affected. Providers manage thousands of accounts. Do not make them guess which one you are talking about.

Specific call examples. This is the most important element. Provide at least three calls that exhibited the problem. For each call, include:

• Date and time (with timezone)
• Calling number and called number
• Call-ID from the SIP headers if you have it (this is the unique identifier the provider uses to find the call in their systems)
• Duration
• What the user experienced (choppy audio, one-way audio, dropped call, etc.)

Call-IDs are worth their weight in gold. A provider's support engineer can search their logs by Call-ID and pull up the exact SIP transaction, RTP quality statistics, and routing path for that specific call within seconds. Without a Call-ID, they are searching by time range and phone number across potentially millions of CDRs, which takes longer and introduces ambiguity when multiple calls match the criteria.

If you have access to SIP traces from your side, include the relevant snippets. This shows the provider what your system sent and received, which helps them determine whether the issue is in their processing or in the path between you.

Quality metrics from your side. If your monitoring shows MOS scores, jitter, and packet loss for the affected calls, include them. Running a VoIP quality test from the client's network during the problem window gives you concrete numbers to attach to the ticket. "The following calls showed MOS below 3.2 with 4% packet loss as measured at our PBX" tells the provider exactly what you observed and gives them a specific metric to compare against their own measurements. If their side shows clean metrics but your side shows degradation, the problem is in the path between you, and that narrows the investigation significantly.

Network path information. A traceroute from the client's network to the provider's signaling and media servers, captured during the time the problem was occurring. This shows the provider the routing path and any intermediate hops where latency or loss may be occurring. It is not definitive (traceroute has well-known limitations for voice diagnostics), but it gives the provider's network team a starting point.

What you have already checked. Briefly list what you have ruled out on your side: local network is clean, bandwidth is not saturated, QoS is configured and verified, problem affects all calls not just one endpoint. This prevents the provider from sending you through a first-tier troubleshooting checklist that you have already completed. It also demonstrates that you have done your homework, which changes how their support team engages with you.

Building the relationship before you need it

The time to build a relationship with your provider's support organization is not when you have an urgent ticket. It is during the quiet periods when everything is working.

Know your account team

Most providers assign account managers or channel managers to their MSP partners. This person is your primary relationship at the provider, and they are your escalation path when normal support is not moving fast enough.

Make a point of having a regular check-in with your account manager, even if it is just quarterly. Understand their role, their authority, and their escalation options. Ask them how their support organization is structured. Find out if there is a dedicated partner support queue separate from the end-user support queue (many providers have this). Ask about any tools or portals available to partners that are not available to end users. Some providers give partners access to deeper diagnostics, direct access to tier 2 support, or expedited ticket routing.

Know the support structure

Every provider's support organization has tiers. Tier 1 handles initial triage and common issues. Tier 2 handles complex technical problems. Tier 3 or engineering handles platform-level issues and code changes. Understanding this structure tells you where your ticket needs to get to and helps you write the initial report in a way that gets it escalated appropriately.

If your initial ticket is written at a tier 1 level ("calls sound bad, please investigate"), it will be handled at tier 1, which means basic troubleshooting steps you have already completed. If your initial ticket includes Call-IDs, quality metrics, SIP traces, and a clear description of what you have already ruled out, a competent tier 1 agent will recognize that this needs to go to tier 2 immediately.

Some providers allow partner accounts to submit tickets directly to tier 2. If yours does, use it.

Provide feedback

When a provider resolves an issue well, tell them. When their support process was frustrating, tell them that too, but through the account manager rather than in the ticket. Providers track partner satisfaction, and your feedback influences how they allocate resources and prioritize improvements.

If you consistently provide clean, well-documented tickets and constructive feedback, you become a partner that the support team recognizes and prioritizes. This is not about getting special treatment. It is about building a professional relationship where both sides operate efficiently.

Escalation paths

Despite your best efforts, some tickets stall. The provider's investigation is inconclusive, the suggested fix did not work, or the issue has been open for days without meaningful progress. You need an escalation path.

When to escalate

Escalate when the normal support process has not produced results within a reasonable timeframe for the severity of the issue. What counts as reasonable depends on the impact:

• A complete outage (no calls in or out) should have active investigation within the hour and resolution within the provider's committed MTTR. If it does not, escalate immediately.
• Ongoing quality degradation affecting all calls should have investigation within 4-8 business hours and a root cause identified within 1-2 business days. If the provider is still asking basic questions after two days, escalate.
• Intermittent quality issues are harder to timeline because they require the provider to capture data during the problem window. But if the ticket has been open for a week with no progress, escalate.

How to escalate

First level: the account manager. Contact your account manager and explain the situation: the ticket number, how long it has been open, what has been done so far, and what the impact on your client is. A good account manager will engage the support management team internally and get additional resources on the ticket.

Second level: support management. If the account manager is not effective (or if you do not have one), ask for the support manager or duty manager in the support organization. Be professional, be specific, and be clear about the business impact. "We have had a ticket open for five business days with no root cause identified. Our client is experiencing degraded call quality on approximately 30% of their external calls. This is impacting their ability to conduct business."

Third level: executive contact. For critical issues that have not been resolved through normal channels, escalate to the provider's leadership. This is a last resort and should be used sparingly, but every MSP should know who to contact at the executive level for their critical vendors. This information often comes from the account manager or from partner program documentation.

Document the escalation

Every escalation should be documented: when you escalated, to whom, what was communicated, and what the response was. This documentation serves two purposes. First, it creates a record if the issue becomes a pattern and you need to evaluate whether the provider is meeting their commitments. Second, it provides evidence if you need to invoke SLA remedies.

Evaluating when a provider is not meeting expectations

Not every issue is a one-off. Sometimes the pattern of issues, the quality of support, or the reliability of the platform indicates a systemic problem that is not going to improve.

Here are the signals that a provider relationship may need to be reconsidered:

Recurring issues without root cause. If the same type of problem keeps happening and the provider cannot identify or resolve the underlying cause, their platform may have a fundamental limitation that they are unwilling or unable to address.

Degrading quality trends. If your monitoring data shows a gradual decline in call quality across clients on the same provider, and the decline does not correlate with any changes on your side, the provider's infrastructure may be oversubscribed beyond what it can deliver at peak or poorly maintained.

Support quality decline. If ticket resolution times are getting longer, if the quality of technical investigation is declining, or if you are seeing increased turnover in the support team (different person on every ticket, no continuity), the provider may be cutting costs in ways that affect service quality.

Feature stagnation. If the provider's platform has not evolved meaningfully in a year while competitors have added significant capabilities, the provider may be in maintenance mode, collecting revenue without investing in the product.

Pricing changes without value. If the provider raises prices without corresponding improvements in service, features, or support quality, the value proposition is eroding.

None of these signals in isolation means you should immediately migrate. But if multiple signals are present and the trajectory is downward, start evaluating alternatives. The cost of migration is significant, but the cost of staying on a declining platform is higher. It just accrues more slowly.

Managing a provider migration

Migrating a client from one voice provider to another is one of the most complex operations in an MSP's voice business. It involves porting phone numbers, reconfiguring or replacing endpoints, retraining users, and maintaining service continuity during the transition. It is not a decision to make lightly, but when it is the right decision, having a plan makes the difference between a smooth transition and a disaster.

Pre-migration evaluation. Before committing to a migration, run a thorough evaluation of the new provider using the same criteria you applied when you originally selected the platform. Set up a test environment, place test calls, evaluate the admin interface, test the support process, and verify that the features the client depends on are available and work correctly. Discovering a feature gap after you have started the migration is extremely costly.

Number porting. Phone numbers are the most critical and most time-sensitive element of a migration. Number porting between carriers typically takes 7-14 business days for standard ports and longer for complex ports involving multiple carriers. Initiate the port request early and track it closely. A delayed or failed port means the client's phone numbers do not work on the new platform, which is an immediate business disruption.

Parallel operation. Where possible, run the new platform alongside the old one during the transition period. Configure the new system, provision the phones, and test everything before porting the numbers. When the port completes, the numbers move to the new platform and the old one can be decommissioned. This minimizes the cutover window and gives you a fallback if something goes wrong.

Communication. Tell the client what to expect. A provider migration will involve some period of adjustment: new phone interfaces, slightly different feature behavior, potentially a brief interruption during the number port. Set expectations clearly and provide a timeline. Surprises during a migration erode the trust you are trying to protect.

Post-migration monitoring. After the migration, increase your monitoring frequency for the first 30 days. Watch quality metrics, call completion rates, and user feedback closely. New platform configurations often need tuning. Trunk settings, codec preferences, QoS markings, and call routing rules may all need adjustment based on real-world performance.

The value of multiple provider relationships

One of the most strategically valuable things an MSP can do is maintain relationships with more than one voice provider. This does not mean splitting every client across two providers (though that has redundancy benefits). It means having evaluated, tested, and established accounts with at least two providers so that you have options.

When you have only one provider relationship, you are dependent on that provider for every client. If their pricing becomes uncompetitive, you absorb the margin hit or pass it to clients. If their support quality declines, your clients feel it. If they have a major platform outage, every one of your voice clients is affected simultaneously.

With multiple provider relationships, you can:

• Match clients to the provider whose strengths best fit their needs. A 10-person office has different requirements than a 200-seat contact center. One provider may excel at simple deployments while another handles complex multi-site configurations better.
• Negotiate pricing with leverage. When your provider knows you have alternatives, pricing conversations are more balanced.
• Migrate away from a declining provider without starting the evaluation process from scratch. You have already tested the alternative.
• Provide genuine redundancy for clients who need it. Primary service on one provider, failover to another.

The investment in maintaining multiple relationships is modest: a test account, periodic evaluation of new features, and an occasional call with the account manager. The value when you need it is substantial.

The MSP as intermediary

The fundamental dynamic in the MSP voice business is that you are an intermediary. The client relies on you. You rely on the provider. When things go wrong, the client holds you accountable and you hold the provider accountable. This works well when the provider is responsive and capable. It becomes painful when they are not.

The skills that make this work are not primarily technical. They are organizational: knowing what information the provider needs before they ask for it, building relationships that give you access to escalation paths, monitoring quality so you detect problems early, and maintaining alternatives so you are never trapped.

The MSPs that struggle with vendor relationships are usually the ones that treat providers as interchangeable commodity suppliers. The ones that thrive are the ones that invest in the relationship, hold the provider accountable with data rather than frustration, and always have a plan B.

Your client chose you because they wanted one responsible party for their voice service. You chose your provider for the same reason. Make sure the relationship you have with your provider mirrors the one your client expects from you: responsive, data-driven, and proactive.

Next up: The Regulatory Landscape: What the FCC Considers a Voice Service Provider. The compliance section begins, covering what triggers VSP classification and why it matters to your MSP.