Path 4 combines two changes: selecting a new CCaaS or telephony provider and, at the same time, moving the Salesforce integration into Salesforce Voice with Partner Telephony, commonly referred to as BYOT.

Salesforce’s current documentation places its provider-based Voice offerings within Partner Contact Center. Here, we use Salesforce Voice with Partner Telephony to identify the model. The underlying model remains the same: a third-party provider continues to operate the telephony platform and route the calls, while Salesforce provides the integrated voice experience inside the CRM.

For an organization that already wants to leave its existing contact-center provider, this can be an efficient point to make both changes. Rather than invest in migrating the old provider from Open CTI to Salesforce Voice and then replacing that provider a year later, the company can design the future environment once and move directly to it.

The company is changing the telephony platform, the Salesforce voice architecture, the agent experience and often parts of the operational model at the same time. That can be the right decision, but it should be budgeted, staffed and governed accordingly.

Where this fits in Salesforce’s guidance

Salesforce’s migration guidance covers moves to Salesforce Voice, including native telephony for Agentforce Contact Center. This post describes the broader decision to change phone providers while adopting Salesforce Voice. An example would be moving from an on-premises contact center platform to a cloud contact center provider and integrating with Salesforce using Salesforce Voice.

If the new provider is Amazon Connect, Salesforce has a partnership that allows customers two choices. You can either have the traditional BYOT model where you manage billing and contracts through Amazon directly, or you can choose Salesforce Voice with Amazon Connect, which is a related non-BYOT option. In this non-BYOT model, Salesforce provisions and manages the instance in its own AWS account, with telephony billed through Salesforce. This changes ownership and administration as well as billing; the BYOT assumptions below do not all apply.

The business case starts with why the existing provider is being replaced

Open CTI retirement should not create a reason to replace an otherwise successful contact-center platform. If the existing provider is reliable, competitively priced and meeting the business requirements, Path 1 or Path 2 will usually involve less disruption.

Path 4 makes more sense when the organization already has reasons to reconsider the incumbent provider. The current dialer may no longer meet the needs of the sales organization. Reporting may be difficult to trust. The agent desktop may be dated. Routing or administration may require too much specialist knowledge. The company may want better AI, transcription or automation capabilities. Pricing may have become unattractive, or the existing provider’s Salesforce Voice strategy may not be mature enough to justify another long-term investment.

Contract timing can also play a major role. If the Open CTI planning process begins before a major CCaaS renewal, it is worth asking whether the company wants to commit to another multi-year agreement before deciding what comes after Open CTI. In that situation, the readiness assessment starts to look like a broader contact-center strategy exercise. We still need to understand the existing Open CTI footprint, but we also need to document what the organization likes and dislikes about the current provider so that the replacement solves real problems rather than simply moving them to another platform.

Provider selection needs to happen with Salesforce Voice in mind

Selecting a new CCaaS provider for Path 4 is different from running a general contact-center RFP and deciding on the Salesforce architecture afterward. The Salesforce integration is part of the product decision. Salesforce Voice with Partner Telephony relies on the partner’s integration package, so the provider needs more than a good phone system; it needs a generally available, Salesforce Voice-certified package that supports the capabilities the organization intends to use.

During vendor evaluation, we would want the provider to demonstrate the integration using scenarios that resemble the customer’s environment. An inbound call should find the correct type of Salesforce record. Transfers should preserve context. Dispositions should produce the expected Salesforce data. Recording and transcription behavior should be understood. Outbound use cases should be demonstrated if they matter to the business.

We would also look closely at functionality that lives outside Salesforce. A provider may have an excellent Salesforce Voice integration but still be a poor fit for the organization’s dialer, workforce management, quality management, international calling, compliance or supervisor requirements. The reverse is also true: a provider may have an impressive contact-center platform but a relatively immature Salesforce Voice implementation. For Path 4, both sides need to be strong. If a prospective provider’s own Salesforce integration is strong and works without Salesforce Voice, a new provider with an API-based integration (CommCorrect Path 5) may be the better fit and should be evaluated alongside Path 4.

There are really two migrations happening

The easiest way to understand the scope of Path 4 is to separate the work into a telephony migration and a Salesforce migration, even though the two eventually converge. The telephony work includes rebuilding IVRs, queues, skills, routing, agent profiles, phone numbers, recordings, outbound campaigns, supervisor functions and any other capabilities currently provided by the incumbent CCaaS platform. Existing integrations to workforce management, quality systems, data warehouses, compliance platforms or other enterprise systems may also need to move.

The Salesforce work looks more like Path 1. Open CTI behavior has to be documented and translated into the Salesforce Voice model. Screen-pop rules, interaction data, Omni-Channel configuration, Flow automation, reporting, permissions and application design all need to be addressed. The difference is that Path 1 gives the project team an existing telephony environment as a stable reference point. In Path 4, the telephony environment itself is being redesigned while the Salesforce integration is being rebuilt.

That makes sequencing important. We normally would not want Salesforce developers independently building against assumptions about how the new provider will behave while the telephony team is still designing routing and interaction data. The future-state architecture needs enough definition that both teams are working from the same call flows, queue structures, identifiers and data model. A simple decision such as changing the disposition structure in the new CCaaS platform can affect Salesforce Flow, reporting and integrations; a change to queue design can affect Omni-Channel mapping.

Number migration, UCaaS strategy and outage planning can shape the project

Phone numbers tend to receive less attention during software selection because they are not visually interesting in a demo. In an actual contact-center migration, they can become one of the most important dependencies. The project needs an inventory of toll-free numbers, local numbers, direct inward dial numbers and any numbers used for outbound caller ID. Ownership needs to be confirmed, along with which carrier currently controls them and what is required to move them.

Some organizations have only a few primary contact-center numbers. Others have hundreds or thousands spread across sales campaigns, regional offices and different business units. Porting those numbers can take time, and a failed or poorly coordinated port can have immediate customer impact. The design should also address how calls will be routed during the transition if different teams move on different weekends.

One advantage of selecting a new provider is that the company can consider its broader communications strategy rather than evaluating the contact center in isolation. If a provider being evaluated for Path 4 offers both UCaaS and CCaaS, there may be an opportunity to simplify the environment. Contact-center agents could use Salesforce Voice while the same underlying communications platform supports the rest of the company. Potential benefits for internal transfers, number administration and corporate directories should be demonstrated in the proposed configuration rather than assumed from a shared vendor.

The outage model is also different from native Agentforce Contact Center because the underlying phone system remains with a third-party CCaaS provider. Depending on the provider and implementation, a Salesforce outage does not necessarily mean the telephony platform itself stops routing calls. Agents may lose Salesforce records, screen pops, Salesforce-based workflows and parts of the integrated desktop, but the CCaaS platform can remain operational. Whether the organization can take practical advantage of that depends on whether agents have access to the vendor’s native application during a Salesforce interruption.

The support model has two vendors by design

Path 4 retains another characteristic of the traditional Salesforce-plus-CCaaS architecture: not every production incident has the same owner. Salesforce provides support for Salesforce functionality, while the telephony provider remains responsible for its communications platform. The support model should be discussed during the buying process rather than after the first outage.

We would want to understand how the new provider handles critical incidents, carrier escalation, one-way audio, call-quality problems, number-routing failures and other traditional telephony issues. We would also want clarity around problems that cross the integration boundary, such as a call arriving correctly in the CCaaS platform but failing to create or update the expected Salesforce Voice record. For a large operation, the implementation should include a troubleshooting model that identifies what telemetry is available on each side and which team owns the initial triage.

Licensing and project cost come from several places

In Path 4, Salesforce Voice licensing sits alongside the licensing for the new CCaaS provider. The business case therefore needs to include the new provider’s agent licenses, Salesforce Voice licenses, implementation costs on both platforms, carrier and usage charges, number-porting work, training, integrations, professional services and any parallel licensing required while the old and new platforms overlap.

Contract timing has a major effect on the first-year cost. If the company is still committed to time on its incumbent CCaaS agreement, it may temporarily be paying for the old provider, the new provider and Salesforce Voice during the migration. That does not necessarily make the project unattractive. It means procurement needs to participate early enough to coordinate termination terms, renewal dates, new contracts and migration milestones.

Platform-license customers need additional analysis for the same reasons described in Paths 1 and 2. An organization with hundreds or thousands of users on Platform or OEM licensing may face a broader Salesforce license change in addition to the Voice add-on. At scale, that can outweigh differences in CCaaS pricing between vendors.

What the project tends to look like

A Path 4 project generally starts with two related discovery exercises. The first documents the existing Open CTI and Salesforce environment. The second documents the incumbent contact-center platform in enough detail to create useful selection requirements for the replacement.

Vendor evaluation follows. For a serious enterprise selection, we prefer scripted demonstrations built around the customer’s real workflows rather than generic vendor demos. Providers should show how they handle the organization’s inbound routing, outbound requirements, Salesforce records, transfers, recordings, supervisor workflows and unusual scenarios.

Once the provider is selected, the future architecture can be finalized. The telephony team designs the new CCaaS environment while the Salesforce team designs the Voice implementation. Phone numbers, routing, integrations, data migration, reporting, security and support ownership are addressed in parallel. The build phase includes both platforms, and testing should then exercise the two platforms as one system.

Larger organizations should plan for a pilot followed by rollout waves. This is particularly important when a new provider is involved because the pilot is validating not only Salesforce configuration but also call quality, routing, carrier behavior, agent experience and the operational support model.

A hypothetical example

Consider an 800-agent organization using an older CCaaS platform through Open CTI. The platform is stable enough to operate, but the business has accumulated several concerns. Outbound dialing is limited, reporting requires too much manual work, AI capabilities are behind newer competitors, and the contract is approaching renewal. The Salesforce team also wants a more native voice experience rather than continuing to maintain custom Open CTI behavior.

In this environment, migrating the incumbent provider into Salesforce Voice might solve the Open CTI problem while preserving the larger set of issues the organization already has with the provider. The readiness assessment therefore becomes the beginning of a provider-selection project.

Discovery identifies dozens of queues, a large phone-number estate, regional IVRs, a substantial inside-sales operation, call recording requirements and integrations into workforce management and a data warehouse. The organization also uses a separate UCaaS platform for corporate calling, so one of the evaluation criteria is whether a new provider could eventually consolidate some or all of those communications services.

Rather than giving vendors an hour to demonstrate a standard product, the organization uses scripted scenarios that include an inbound service call, an outbound sales workflow, a transfer from a contact-center agent to a corporate employee, Salesforce record matching, disposition handling, supervisor monitoring and an outage scenario. Two providers meet most of the broader contact-center requirements. The stronger platform has a generally available Salesforce Voice package, but the scripted demonstration shows it does not yet support one capability the business uses every day: it cannot carry the provider’s own agent-status codes into Salesforce, and multiparty conference calls behave differently than in the current environment. The other provider handles those scenarios but is weaker on outbound dialing. The team has to decide whether to accept a workaround, ask the first provider for roadmap commitments in writing, choose the second provider, or evaluate whether a provider-native integration without Salesforce Voice would meet the requirement more simply.

Once the provider is selected and the open items are documented, implementation proceeds across two coordinated workstreams. The provider team rebuilds routing, IVRs, dialing and phone-number configuration while the Salesforce team implements Voice, Omni-Channel, record matching, automation and reporting. A pilot group moves first using a controlled set of queues and numbers, and it is expected to surface issues that scripted testing missed. The workforce-management integration stays unresolved until late in the design phase because the new provider’s connector needs separate confirmation. Once call quality, workflows and Salesforce data are proven and the remaining gaps are closed or accepted, subsequent business units are migrated in waves and the old provider is eventually retired. The final cost and schedule depend on how those gaps are resolved.

Where Path 4 tends to fit

Path 4 makes the most sense when the organization has already concluded that the existing CCaaS platform is not the long-term answer and also sees enough value in Salesforce Voice to justify making it part of the future architecture. It can be particularly attractive when contract timing gives the organization a natural opportunity to change providers, when a new provider offers materially better routing, outbound functionality, AI, reporting or economics, or when the broader communications strategy could benefit from consolidating UCaaS and CCaaS with the same vendor.

The project deserves more scrutiny when dissatisfaction with the existing provider is relatively minor or when the main objective is simply getting off Open CTI. In those environments, changing both the phone system and Salesforce integration may create unnecessary cost and risk. It also needs careful financial analysis for large user populations and Platform-license environments because Salesforce Voice licensing can materially change the total economics even if the new CCaaS provider itself is less expensive.

CommCorrect can support the full Path 4 lifecycle rather than only the Salesforce portion. We can help document the current environment, build the requirements, evaluate and shortlist new communications providers, participate in scripted demos and negotiations, design the Salesforce Voice architecture, and support the implementation and migration after the provider is selected, with delivery responsibilities agreed across CommCorrect, the provider and any implementation partners.

This path makes sense when both changes have a business case and can be delivered through one coordinated program.

CommCorrect Technologies, LLC

5233 Driscoll Court, Orlando, FL 32812

hello@commcorrect.tech

© 2026 CommCorrect Technologies, LLC. All rights reserved.

Privacy Policy

Terms of Service