Cost and licensing need to be considered early

Keeping the phone system reduces one category of migration cost, but Salesforce Voice introduces its own commercial considerations. The organization continues paying for its existing telephony platform and should expect to pay for Salesforce Voice licensing from Salesforce across the affected agent population. Depending on the provider, there may also be an additional fee for its Salesforce Voice connector or package, and transcription may require a separate partner license. Depending on the customer's existing Salesforce licenses, there may also be base-edition or entitlement requirements that need to be addressed before Voice can be added. Confirm each of these with Salesforce and the provider early, because they are priced and contracted separately.

At smaller scale, those costs may not dominate the decision. At 500, 1,500 or several thousand agents, they can become one of the most important elements of the business case. Implementation cost should also be separated from software licensing. Even though the telephony provider is not changing, the customer may still need Salesforce architecture, Flow development, automation remediation, reporting updates, provider professional services, testing, project management, training and post-launch support.

The best comparison is therefore not simply the monthly price of Salesforce Voice. It is the total cost of moving the current environment into the new architecture and operating it for several years. That should be compared against the alternatives, including an API-based integration that leaves more of the contact center experience outside Salesforce.

Team involvement and the support model

A Salesforce Voice migration cannot be owned successfully by the Salesforce team in isolation. Contact center operations needs to document how agents and supervisors really work. The telephony provider needs to own its integration package and the configuration on its side. Salesforce architects and administrators need to own the new CRM-side design. Security should review authentication, permissions and integration identities, while reporting teams need to validate that management metrics remain trustworthy after the data model changes.

The support model also changes after launch. Under Open CTI, many issues may have historically been treated as vendor-adapter problems. With Salesforce Voice, more of the operational experience sits inside Salesforce itself. Flow, Omni-Channel, VoiceCall automation, permissions and application configuration become part of the ongoing Salesforce support responsibility.

That division of ownership should be documented during implementation. When an agent reports that a call connected but did not log correctly, someone needs to know whether the incident belongs with Salesforce, the telephony provider, the partner connector or a customer-built automation. Without good logging and clearly defined ownership, incidents can easily bounce between teams because each platform appears healthy when examined on its own.

Cutover planning deserves similar care. Users cannot simply float indefinitely between the Open CTI and Salesforce Voice environments. A large migration should have clear pilot populations, rollout groups and a documented rollback approach. Where the provider supports coexistence, the old Open CTI implementation may provide a temporary fallback while Salesforce Voice is stabilized. It cannot be a fallback after the February 28, 2028 retirement.

A hypothetical example

Consider a 600-agent contact center that is happy with its current CCaaS provider. The telephony environment is stable, supervisors know the tools, call routing works well and there is no business case for replacing the phone system. The provider also has a supported Salesforce Voice integration, making BYOT a realistic option.

The Salesforce environment has been in production for several years. Inbound calls can match Leads, Contacts or Accounts depending on the business unit. Completed calls create Tasks that feed management reports. Several Flows react to dispositions, recordings are linked back into Salesforce, and part of the population uses outbound dialing.

The telephony infrastructure may require very little change, but the Salesforce work is substantial enough that the project should be treated as a real migration. Record matching needs to be rebuilt and tested in the new architecture. Existing Task-based reporting and automation needs to be reconciled with the Salesforce Voice interaction model. Agent presence and routing behavior needs to be understood. Supervisors and agents need to validate the new workflow in production before hundreds of users are moved.

The schedule would depend on the workflow gaps, provider readiness and rollout plan, even though the phone system itself is not being replaced. The value of the path is that the company can modernize the Salesforce integration without throwing away a contact center platform it already likes.

Where Path 1 tends to fit

This approach is usually worth serious consideration when the organization is satisfied with its telephony provider, the provider has a mature Salesforce Voice offering, and the business places real value on having voice more deeply embedded into Salesforce. Companies that already use Omni-Channel or want a more unified Salesforce agent experience may find the architecture particularly attractive.

It deserves more scrutiny when the business only needs a relatively narrow CRM integration, or when the licensing and migration effort outweigh the value of the deeper Salesforce integration.

CommCorrect’s free Open CTI Readiness Assessment is intended to make that distinction before a customer commits to the migration. The free review and any detailed technical discovery should have an agreed scope. If Salesforce Voice with the existing provider is the right path, we can continue into a paid engagement covering architecture, Salesforce Voice configuration, Flow and automation development, testing, rollout and post-launch support, with provider and delivery-partner responsibilities agreed in advance. If the assessment shows that the organization can meet its requirements with a simpler integration model, we would rather identify that early than force a Salesforce Voice project where it is not needed.

For organizations that are satisfied with their existing business phone or contact center provider, one of the most obvious ways to move off Open CTI is to keep the phone system in place and migrate the Salesforce integration to Salesforce Voice using a Bring Your Own Telephony model. On paper, this can look like the least disruptive Salesforce-native option because the underlying CCaaS platform, carrier relationships, phone numbers, IVRs and routing environment can remain largely intact. The change may be concentrated on the Salesforce side, but provider configuration and professional services can still be required.

That description is accurate, but it can also be misleading if it causes the project to be treated as a simple connector replacement. In most established environments, Open CTI has become more than a softphone. It may be responsible for screen pops, activity logging, dispositions, record matching, call-related automation and a variety of small behaviors that accumulated over years. Salesforce Voice uses a different architecture, so those functions need to be identified and, in many cases, rebuilt or redesigned.

The first question in this path is therefore not whether the customer wants to keep the existing telephony provider. It is whether that provider has a generally available, Salesforce Voice-certified partner integration that supports the way the organization actually operates. Once that is established, the project becomes an exercise in understanding how much of the current telephony environment can remain untouched and how much of the Salesforce experience needs to change.

Where this fits in Salesforce’s guidance

This path is Salesforce’s partner-telephony model: your provider keeps running telephony and Salesforce supplies the Voice experience. This is ultimately Salesforce's recommended path for any customer using a phone system vendor integrated with Salesforce.

What remains in place and what actually changes

The main attraction of this path is that the core telephony platform does not have to be replaced. The existing provider can continue to handle carrier services, call routing, IVRs, queues, recordings and many of the operational functions that contact center teams already understand. In a large organization, preserving those investments can remove a significant amount of risk by avoiding a simultaneous phone-system replacement and potentially avoiding number porting and retraining on a new CCaaS platform. Confirm those assumptions with the provider.

The Salesforce side changes much more substantially. Open CTI has historically allowed a vendor adapter to handle things such as screen pops and call logging through its own JavaScript implementation. Salesforce Voice moves more of that behavior into native Salesforce concepts. Voice interactions become part of a different Salesforce data model, screen-pop behavior is commonly handled through Flow, and presence and routing become more closely connected to Omni-Channel.

For a fairly simple Open CTI implementation, that transition may be manageable. An organization with basic click-to-dial, straightforward phone-number matching and limited downstream automation may be able to move through the project without much redesign. A mature enterprise environment can be very different. One inbound call may trigger matching against several Salesforce objects, apply business-unit-specific rules, create activities with custom fields, write a disposition used by other automation and feed management reporting. None of that complexity disappears because the underlying phone system is staying the same.

This is why discovery has to follow the full lifecycle of an interaction rather than focusing only on the visible softphone. The project team needs to understand what happens before the call reaches an agent, what Salesforce does while the interaction is active, what data is written afterward and what other processes depend on that data.

Screen-pop logic is a good example. An implementation may have started years ago with a simple Contact search and gradually evolved to account for Leads, duplicate records, Accounts, Cases, custom objects and specialized handling for different departments. In an Open CTI environment, some or all of that behavior may be hidden inside the adapter. Moving to Salesforce Voice usually creates an opportunity to make those rules more explicit and maintainable, but it also means someone has to first discover what the rules are and decide which ones should survive.

The same applies to call logging. A company may have built years of reporting and automation around Tasks created by the existing CTI adapter. A Salesforce Voice migration may introduce VoiceCall records and a different interaction model. That does not mean every existing report or automation has to be discarded, but it does mean the team should understand the downstream dependencies before the new model reaches production.

What the project tends to look like

The project should begin with discovery and architecture before configuration. The existing Open CTI implementation needs to be documented in enough detail to understand screen-pop behavior, routing, presence, activity creation, dispositions, recordings, outbound workflows, reporting and automation. At the same time, the telephony provider’s Salesforce Voice package needs to be validated against the customer’s actual use cases rather than assumed to be feature-equivalent with the existing adapter.

Once the future-state design is clear, the Salesforce Voice foundation can be established in a sandbox or other non-production environment. That normally includes the new contact center configuration, authentication with the telephony provider, agent and permission setup, Omni-Channel configuration, Flow work and any required changes to Salesforce applications or console layouts.

The build phase tends to expose the difference between a simple and a mature environment. A basic implementation may require relatively little custom work. A heavily customized organization may need to rebuild screen-pop rules, rework post-call automation, modify reporting, adjust permissions and decide how historic Task-based reporting should coexist with the new voice data model.

Testing has to resemble the real operating environment. Making and receiving a call proves only that the basic integration works. The useful test cases are the ones that reflect actual business behavior: multiple Salesforce records with the same phone number, transferred calls, unsuccessful outbound attempts, different dispositions, recordings, follow-up automation, supervisor visibility and the reports management uses every day. If a business unit has unusual routing or custom objects, those scenarios should be represented in the pilot rather than saved for the organization-wide rollout.

Larger contact centers are generally better served by moving a representative user group first. A pilot covering the important roles, queues and workflows can expose differences in agent workflow, presence behavior, reporting and automation that may not appear in scripted QA. Once that group has been running successfully in production and the data has been reconciled, additional teams can move in planned waves.

CommCorrect Technologies, LLC

5233 Driscoll Court, Orlando, FL 32812

hello@commcorrect.tech

© 2026 CommCorrect Technologies, LLC. All rights reserved.

Privacy Policy

Terms of Service