"Cloud call centre" is one of those phrases that has been stretched until it stopped narrowing anything down. I have watched buyers compare four products under that heading where the only shared property was that none of them shipped in a box.
So, plainly: what people actually mean, and what to check.
The short version
A cloud call centre is a contact-centre platform — dialer, agent interface, routing, recording, reporting — that runs on infrastructure you do not own, reached over the internet, with agents working in a browser rather than at a desk phone wired to a PBX in a cupboard.
That is the whole definition. Everything else is a question of degree, and the degrees matter a great deal.
The four things it might mean
1. Managed hosting of a platform you already know. Someone else runs the servers; the software is the same software. You keep your configuration, your integrations and usually your administrative access. This is what VICIfast is — managed VICIdial, stock codebase, root retained.
2. A multi-tenant SaaS platform. You are one tenant among many on shared infrastructure. Provisioning is instant, upgrades are automatic and not optional, and you configure within whatever the product permits. Most of what gets marketed as CCaaS is this.
3. A platform plus the CRM. The dialer and the system of record are one product rather than two joined by an integration. Different category, because it changes where your data lives. Adoptiv is this.
4. Outsourced agents. Sometimes "cloud call centre" means people, not software — a BPO answering your calls. Entirely different purchase. Worth confirming early which one a vendor is describing.
The questions that separate them
Where does the audio actually go? Media path determines quality, latency and, in regulated verticals, where recordings come to rest. "Cloud" says nothing about jurisdiction. Ask which region.
Whose carrier? Some platforms bundle minutes; some let you bring your own. Bundled is simpler and you inherit their routing quality and their margin. Bring-your-own means you own answer-seizure ratio and cost per connect — which is where the real money is — but you have to actually manage it.
What happens when you leave? The single most useful question, and the one most likely to be answered vaguely. Can you export leads, dispositions, recordings and configuration in a usable format? Does anything you have built transfer? If the honest answer is that leaving means rebuilding, price that in now.
Where does administrative control stop? Some platforms give root. Some give a settings page. Neither is wrong — but if your team can diagnose a SIP problem and the platform will not let them look, you have bought a support relationship whether you wanted one or not.
How does it scale, and what does scaling cost? Per-agent licensing changes behaviour: it makes the marginal agent expensive exactly when you want to staff up. Per-server pricing does not. Ask what happens at three times your current volume.
What you genuinely gain
No hardware. The obvious one, and still the biggest. Nobody drives to a colo at 3am.
Agents anywhere. Browser-based agent screens over WebRTC mean a floor can be distributed across cities or countries. This stopped being a nice-to-have some years ago.
Elastic capacity. Seasonal outbound operations no longer size hardware for December in March.
Someone else patches it. Assuming they actually do — worth asking how patching works and how often it happens.
What you give up
Some control, in proportion to which of the four models you chose.
Direct visibility into the failure, sometimes. When something breaks on your own server you can look. On a closed platform you file a ticket and wait, and your ability to answer your own client's question depends on someone else's response time.
Cost predictability at scale, occasionally. Per-minute and per-agent pricing that is cheap at 20 seats sometimes stops being cheap at 200. Model it at the volume you are planning for, not the volume you have.
The honest summary
Cloud is now the default, and for good reasons — but "cloud" is a deployment model, not a quality claim. A badly architected platform in someone else's data centre is still a badly architected platform, and it will fall over in the same order: database first, then channels, then the web tier.
Pick based on how much control you need, how much of the operating burden you want to keep, and how expensive it would be to change your mind in two years. That last one is the question people skip, and it is the one they call me about later.