Open CTI reaches end of life on 28 February 2028.
If you have never heard of Open CTI, that is fair enough, because it was never meant to be visible. It is the JavaScript API that lets a third-party telephony platform embed a softphone directly into the Salesforce agent interface. Screen pops, click to dial, call controls, activity logging. For more than a decade it has been the plumbing underneath almost every serious contact centre integration into Salesforce, including ours and everyone else's.
Plumbing is invisible right up until the moment it is not.
What Salesforce has announced
The facts, plainly, because there is already a fair amount of noise around this one.
Open CTI reaches end of life on 28 February 2028. After that date, implementations built on it stop functioning. That much is not ambiguous.
More immediately, new Agentforce Service orgs can no longer implement or use Open CTI. That restriction applies now rather than in 2028. Existing implementations can keep running until the deadline, but the door for new builds has already closed. Salesforce covered the announcement in detail when it landed earlier this year.
The recommended replacement is “Salesforce Voice”, which Salesforce positions as offering equivalent and enhanced telephony capability, with native Omni-Channel integration, real-time transcription, Next Best Action and Agentforce hooks.
This is a reasonable product decision on their part. An older API that sits outside the platform's control is being replaced with something Salesforce can build against properly and support end to end. Most platform companies reach this point eventually, and there is a genuine upside for customers who want tight native integration.
The question for the rest of us is simply what it changes, and what to do about it.
The commercial model changes, and that is worth planning for
Here is the part that has not landed with most buyers yet.
Open CTI was an API. You did not pay Salesforce for it. You paid your contact centre vendor for a platform, your carrier for minutes, and the integration into Salesforce came along as part of the deal. The connection point between CRM and voice channel provided user freedom and sat outside anybody's commercial model.
Salesforce Voice is a product, and it is priced like one. There is a per user, per month licence fee that sits alongside your existing Service Cloud licences, and telephony consumption is charged separately. Independent analysis of Service Cloud Voice pricing describes a layered model: a platform fee quoted and discounted like any other Salesforce SKU, plus consumption on top. The same analysis notes that first year telephony usage diverged higher than customer sizing assumptions by 25 to 40 per cent, which is useful context when you are building a business case.
None of that is unusual for enterprise software. It is simply a different shape of cost to the one most organisations have budgeted for, and it needs to go into the model early.
If you run 300 seats, do that maths before you do anything else.
Third-party telephony has not gone away, but the model is different
I want to be precise here, because there is a version of this story doing the rounds that overstates things.
Third-party voice is not being locked out of Salesforce. Salesforce Voice supports several deployment models, including a turnkey option, an option where you connect your own existing cloud voice infrastructure, and a partner telephony route for approved vendors. OSF Digital has a clear breakdown of the models if you want the technical detail.
The accurate way to describe the change is this. Your telephony can still be your telephony. It now runs inside the Salesforce Voice framework, which means the capabilities available to your agents are the ones that framework exposes, released on that framework's cycle.
So the practical question for your operations team is not whether you can keep your voice platform. It is which of the things your agents do today carry across cleanly.
If your contact centre platform does something specific that the framework does not have a slot for, that capability needs to be rebuilt, worked around, or dropped. ( * Worth finding out which, before the project starts rather than during it! * )
This is a rebuild rather than a swap
Eighteen to twenty four months sounds generous. In practice it is tighter than it looks.
Very few Salesforce contact centre integrations are vanilla. Ten years of Open CTI work tends to accumulate into something bespoke: custom screen pop logic, routing rules tied to case data, wrap up codes feeding a reporting stack somebody built in 2019, click to dial from three different objects, a dialler integration that finance now depends on. Often none of it is documented, and the people who built it have moved on.
Industry commentary is consistent on this, with Apex Hours noting that an effective Open CTI migration may require significant architectural redesign and resources. That matches what we see in the field.
Then put the project into a real enterprise calendar. Change freezes, budget cycles, whatever is already booked for next year. Twenty four months quickly becomes four usable quarters, and one of those will go on discovery.
The organisations that start scoping in 2027 will be doing this under time pressure, which is rarely when the best architectural decisions get made.
A good moment to look at the architecture
Almost every conversation I have had about this so far has been framed the same way: how do we migrate off Open CTI?
That is the immediate question. There is a larger one sitting underneath it.
How much should your CRM determine what your agents can do on a phone call?
Most organisations have not consciously answered that. The CRM is treated as fixed and load bearing. The contact centre platform is treated as the component you go to market on every few years. But look at what has happened here. A change to the CRM integration model lands on your voice channel, your agent workflow, your operating costs and your project roadmap.
That is not a criticism of Salesforce. It is a reasonable consequence of an architecture where the two layers are tightly bound together, and most of us ended up with that architecture without ever really deciding on it.
Your CRM is where the customer record lives. Your contact centre is where the work happens. Those two things can come from the same vendor, and for plenty of organisations that is the right answer. What is worth avoiding is a setup where a roadmap change in one layer forces an unplanned rebuild in the other.
I am not suggesting anyone rips out Salesforce. Many organisations run it extremely well and have no reason to move. The point is only that both layers are choices, and this is a sensible moment to look at them properly rather than assume one of them is fixed.
Pick the CRM. Keep the contact centre.
This is the principle NeonNow CX is built around, and it is why this announcement matters to us.
Our contact centre layer sits on its own foundation rather than inside a CRM. It runs on Amazon Connect and AWS infrastructure, which gives us the enterprise security, scale and reliability profile our customers need without inheriting it from a CRM platform. If you want the detail on that foundation, the Amazon Connect product pages and the full feature list are worth twenty minutes of your time.
On top of that, NeonNow is designed to connect with the CRM and service platforms our customers actually use, including Salesforce, Microsoft Dynamics, ServiceNow, Hubspot, Pipedrive, Monday CRM and many others. The customer picks their CRM. The contact centre stays where it is – at the heart of the real time interactions and customer experience.
The agent experience holds up either way. NeonNow IQ delivers real-time agent assist, live sentiment and intent detection and automated post-call summaries as part of our platform, rather than as something you buy again from whichever CRM you land on. Those capabilities follow you.
And because a migration like this is genuinely hard, our consulting and design and delivery and integration teams do the work alongside our customers rather than handing over a platform and wishing them luck.
What I would do in the next ninety days
Four things, in this order.
Audit what you actually have. Every Open CTI integration in your estate, every piece of customisation hanging off it, and an honest note against each one about whether anybody still understands how it works.
Price the options properly. Not just licence cost, the total. Salesforce Voice licences across your agent base, plus consumption, plus rebuild effort, set against the alternative of a contact centre layer that sits independently of your CRM. Real numbers in both columns.
Ask your vendors the same question and get it in writing. What will my agents be able to do in 2028, and what will it cost per seat. Written answers age better than roadmap slides.
Then decide on architecture rather than on the deadline. The organisations that come out of this well will be the ones who treated February 2028 as a prompt to make a considered decision, not a countdown to an unavoidable one. If you want more background on how contact centre architecture is evolving, the AWS Contact Center blog is a good place to read further.
A deadline is not a strategy. It is a decent excuse to finally have the conversation.
Work out what this means for your contact centre
If you are running voice inside Salesforce today and you are not yet sure what the Open CTI retirement means for your agents, your integrations or your cost per seat, we are happy to walk through it with you. No migration pitch, just an honest look at the options and what each one involves.
Book a demo and we will show you what a CRM-independent contact centre looks like in practice, with your CRM of choice sitting alongside it.
Prefer to start with a conversation? Talk to our team about what your 2028 options look like from where you are standing today.
.jpg)
.svg)
