There Is No Best
Platform.
The question gets asked in every procurement, every forum and every conference bar. It has no answer, and the people most willing to give one are usually the least able to give it honestly.
Ask which contact centre platform is best and you will get a dozen confident answers. Every one of them is wrong, and not because the platforms are bad.
The question is wrong. It asks for a property that does not exist in the object being described. There is no best platform in the way there is a fastest car or a tallest building, because the thing being measured is not the product. It is the fit between a product and an estate, and the estate is different every time.
That sounds like a dodge. It is the opposite. Refusing to name a winner is harder work than naming one, because it obliges you to say what the decision actually depends on, and then to be judged on whether you got those dependencies right.
1. Where the question comes from
Nobody asks it out of idle curiosity. It comes from procurement, and procurement needs a defensible single answer.
A board paper cannot say it depends. A business case needs a recommendation, a runner-up and a reason. An evaluation scorecard needs a column that totals higher than the other columns. The whole apparatus of enterprise selection is built to convert a judgement about fit into a number about quality, because a number can be signed off and a judgement has to be owned.
So the question gets asked in a form that demands the wrong kind of answer, and the market obligingly supplies it.
2. Who answers, and why that matters
Look at where confident answers come from.
They come from people who sell one platform. They come from people who implement one platform and hold certifications in it. They come from analysts whose research is funded, in part, by the vendors being ranked. And they come from buyers who spent eighteen months and a great deal of political capital on a decision two years ago and have been living with the consequences since.
None of that makes anyone dishonest. A partner with four hundred certified engineers on one stack is not lying when they say it is the best choice. They are describing an environment where it genuinely was, and quietly assuming yours resembles it. A buyer defending a past decision is not being stubborn. They are protecting a judgement they made with the information available, and reopening it costs them something real.
The problem is that the incentive structure produces confident answers regardless of whether confidence is warranted. Nobody is rewarded for saying they are not sure. And the people best placed to give you a genuinely comparative view, those who have delivered several platforms across several estates, are the ones least likely to be in the room, because they are usually mid-delivery on one of them.
3. Recommendations have a shelf life
Here is the part that has changed most in the last two years, and the part procurement has not absorbed.
An honest recommendation now decays faster than the process that consumes it.
In June 2026 three major vendors made workforce management availability announcements within three weeks of each other, all claiming a version of the same capability. I wrote about that at the time, and the substance of the piece was that the announcements were real but the underlying models were uneven. The relevant point here is narrower and more uncomfortable: a capability comparison written in May was materially out of date by July.
Enterprise procurement does not run in three weeks. It runs in six to eighteen months. Requirements gathering, market scan, RFI, RFP, demonstrations, proofs of concept, commercial negotiation, security review, legal. By the time a contract is signed, several of the capability gaps that justified the decision have closed, and several new ones have opened somewhere else.
What I would recommend today is not what I would have recommended in January, and probably not what I will recommend by Christmas. That is not evasiveness. It is an accurate description of a market moving faster than the mechanism built to buy from it.
4. What the decision actually turns on
If the platform is not the variable, what is? In my experience the answer sits almost entirely in the estate rather than the product.
Your system of record. Where the customer data lives, and how much of your service process is already encoded in it, does more to determine the right architecture than any feature comparison. A contact centre bolted to the side of a CRM behaves differently from a CRM bolted to the side of a contact centre, and the difference shows up in every escalation path you build afterwards.
Your voice estate. Carrier contracts, number ranges, on-premise hardware still in depreciation, regulatory recording obligations, contact centre sites you cannot close for two more years. Voice is the part of the stack most likely to be constrained by decisions taken before anyone in the room arrived.
Your integration debt. Not how many systems you have, but how many of them are undocumented, unsupported or maintained by one person. Every platform demonstrates beautifully against clean APIs. The differences appear at the seams, and the seams are yours.
Your regulatory position. Data residency, retention, model governance, sector-specific supervision. These do not usually eliminate a platform outright. They change its cost and its timeline, sometimes dramatically, and they rarely surface in a capability matrix.
Your people. What your team can actually run on a Tuesday afternoon when something breaks and the partner is not answering. A platform that requires skills you do not have and cannot recruit is not a capability. It is a dependency.
Your appetite for change. Some organisations can absorb a wholesale replatform. Most cannot, and know it, and buy one anyway.
Run those six through any shortlist and the field usually narrows to two or three long before anyone opens a feature list. The feature list then decides between near-equals, which is roughly the weight it deserves.
5. One platform or best of breed
This is the argument that generates the most heat and the least light, because it is usually conducted as a matter of principle when it is a matter of circumstance.
A single platform buys you coherence. One data model, one identity, one support relationship, one roadmap, fewer seams to own. You pay for it in dependency: when the roadmap goes somewhere you did not want to go, you go there anyway, and your commercial leverage at renewal is whatever your migration cost says it is.
Best of breed buys you optionality. You take the strongest component in each layer and you can replace any one of them without replacing the others. You pay for it by owning every seam yourself, permanently, including the ones that only reveal themselves at three in the morning during an incident nobody has a runbook for.
Both are correct. Which one is correct for you depends on whether your organisation is better at managing vendors or better at managing integration, and most organisations know the answer to that even when they will not say it out loud.
The failure mode is not picking the wrong one. It is picking one on principle, then behaving as though the other set of costs does not apply.
6. Lock-in is a price, not a sin
Vendor lock-in is discussed as though it were a moral failing that careful architects avoid. It is a purchase. You buy coherence and you pay in switching cost.
Vendor agnosticism is also a purchase. You buy optionality and you pay in integration effort, duplicated capability, weaker commercial terms and a permanent obligation to maintain your own abstraction layer. Agnostic architectures are not free. They are financed by an engineering team, and if that team shrinks the architecture degrades quietly.
The useful question is not how to avoid lock-in. It is what you are being asked to pay for it, whether you can afford that, and whether you would still consider it a fair price in five years under a different set of assumptions. Sometimes deep lock-in with a strong partner is the most responsible decision available. Saying so out loud is unfashionable and usually correct.
7. A test you can apply to any recommendation
Since I am declining to name a winner, it is only fair to offer something you can use instead.
Ask whoever is recommending a platform to name the environment where their recommendation is wrong.
Any architect worth listening to can do this in about ten seconds. They will tell you that their preferred platform struggles where the CRM is elsewhere, or where the voice estate is complicated, or where the regulatory position is unusual, or where the in-house skills are thin. The answer will be specific, it will be delivered without defensiveness, and it will tell you far more about the quality of their judgement than any amount of enthusiasm.
Someone who cannot answer it has told you one of two things. Either they have only seen one environment, in which case their sample size is one. Or they have decided in advance and are working backwards, in which case the recommendation is a conclusion looking for evidence.
The corollary is uncomfortable and worth stating. Apply the test to me. The environments where I am least useful are those where the deciding factor is commercial rather than architectural, where the organisation has already made a strategic platform commitment at group level, or where the honest answer is that the incumbent is adequate and the money is better spent on process. I have watched replatforms deliver less value than a redesigned escalation path would have done for a fraction of the cost.
8. Where I have landed
Write down the assumptions rather than the answer.
Most selection documents record a decision and its justification. Very few record the conditions under which the decision would need revisiting. That omission is why organisations end up defending choices made against an estate that no longer exists.
A decision record that says we chose this because our system of record is here, our voice estate is constrained until this date, our team has these skills and our regulatory position requires this remains useful for years. It can be re-tested. When one of those conditions changes, you know to look again, and you can look again without anybody having to admit they were wrong the first time.
A decision record that says we chose this because it scored highest is worthless within a year, because the scores have moved and nobody wrote down what the scoring was for.
There is no best platform. There are trade-offs, unmet expectations on every product in the market, and a set of conditions in your organisation that make some of those trade-offs bearable and others intolerable. The work is not finding the winner. The work is knowing which compromise you can live with, writing down why, and being willing to look at it again when the ground moves.
Anyone giving you a straight answer to the wrong question is not being decisive. They are being incurious, and incuriosity is expensive at this scale.
— Beyond The Dial Tone
Mark McLeish is a contact centre technology specialist working across architecture, customer experience, CRM and enterprise AI. He writes about the decisions beneath the product demo, backed by delivery experience rather than vendor messaging.
Written in a personal capacity. The views are Mark’s own and do not represent his employer or any vendor mentioned.
Evidence note. This piece deliberately names no platform and makes no comparative capability claim. The June 2026 workforce management observation refers to three vendor availability announcements within a three-week period, documented with sources in Erlang Doesn’t Cover This (26 July 2026). The underlying position on capability variation across platforms is set out in CCaaS Convergence Is Real. But It Is Not Capability Parity. (26 April 2026), which covers five platforms against sixty voice and contact centre capabilities and states the evidence rules used. Procurement cycle durations described here are drawn from delivery experience rather than published research, and should be read as such. No hands-on validation of any current vendor claim is asserted in this piece.