Salesforce Communications Cloud is the telecom BSS suite built on Salesforce: a communications industry data model, Enterprise Product Catalog, Industries CPQ, Contract Lifecycle Management, Digital Commerce and Order Management in one stack. Twopir Consulting architects, configures and extends it so a commercial offer becomes an order your fulfilment systems can actually complete. Catalog, quote, order and orchestration on one data model.
Trusted by 500+ organizations — including connectivity and communications providers building their commercial operations on Salesforce with Twopir Consulting.
Where We Work in the Stack
Most communications service providers can sell a service in minutes and take weeks to deliver it. The gap is almost never the network. It is the model sitting between the offer and the order.
Products are stored as flat SKUs with pricing attached, so a new bundle means new code. A real product model separates commercial offers from the technical services behind them — and lets product managers assemble both without a release.
A signed commercial order has to become a technical order that provisioning systems understand. Without decomposition rules, someone re-keys it by hand — which is where the errors, the delay and the disputed first invoice all begin.
When an orchestration step fails, the order leaves the system and enters a queue a person watches. Nobody can answer "where is my order" because the answer is not in any system of record.
Upgrades, moves, suspensions and disconnections are not new orders — they are changes to an existing subscription. Systems that cannot express a change order force agents to cancel and rebuild, which corrupts the asset record and the billing that depends on it.
A business customer with 200 sites is not 200 consumer orders. Without site grouping, contracted rates and bulk configuration, enterprise deals get quoted in spreadsheets and re-entered — and the contract that results does not match what was sold.
Self-serve, contact centre, retail and partner channels each get their own eligibility and pricing logic. The same customer is quoted three different prices, and nobody can change an offer once without changing it four times.
Salesforce Communications Cloud is a business support system (BSS) suite for communications service providers, built on the Salesforce platform. It ships a communications industry data model together with the Enterprise Product Catalog, Industries CPQ, Contract Lifecycle Management, Digital Commerce and Industries Order Management — so an operator can design an offer, sell it across channels, turn the sale into a technical order, and orchestrate that order across the systems that actually deliver the service. It was previously sold as Vlocity, and Salesforce documentation still uses both names, which is why older implementation guides reference Vlocity components.
Two things make it different from configuring standard CRM. The Enterprise Product Catalog is a modelling tool, not a product table — it separates the commercial offer a customer buys from the technical services that fulfil it, so a bundle can be assembled and changed as catalog data rather than as code. And Order Management decomposes a commercial order into a technical order, generates fulfilment requests, and runs them through an orchestration plan whose steps are sequenced across billing, provisioning, inventory and field service. Salesforce's Enterprise Product Catalog is certified against the TM Forum Information Framework (SID), and the suite exposes TM Forum Open APIs — which is what makes integration with an existing BSS estate a standards exercise rather than a bespoke one. You can read Salesforce's own developer documentation for the Communications Cloud TM Forum API.
A note on the name. "Salesforce Communications Cloud" (plural) is this telecom BSS product. It is not the same thing as multi-channel customer messaging — the notifications, billing alerts and promotional sends that Twopir covers on its Salesforce communication cloud engagement page, which is built on Marketing Cloud rather than on Communications Cloud. If your question is "how do we message customers across channels", that is the other page. If it is "how do we model, sell, order and activate telecom services", you are in the right place.
Who it is for. Communications Cloud earns its cost where product complexity, order volume or fulfilment dependency is genuinely high: mobile network operators and MVNOs, broadband, cable and fibre providers, satellite and fixed-wireless operators, wholesale and carrier businesses, and B2B connectivity and managed-service providers. An operator with a handful of static plans and no provisioning dependency does not need it — and we will say so on the first call rather than after a discovery phase.
These are not the same project and they do not have the same risk profile. Knowing which one you are actually buying is the difference between a twelve-week engagement and an eighteen-month programme. Twopir Consulting delivers all three.
A first Communications Cloud build: data model, catalog, quoting, ordering and the integrations that make it real. This is the programme, and it is scoped in phases.
You already run Communications Cloud. The work is new offers, new rules, new markets and new channels — inside the product's own configuration surface, without writing code.
Where configuration genuinely runs out: custom experiences, custom integration surfaces and custom logic that the standard product does not express. Deliberate, documented, and kept small.
Where the configuration boundary actually sits
| What you want to change | Configuration | Custom development |
|---|---|---|
| A new bundle, plan or promotion | Catalog change in EPC — no code | Only if the pricing shape itself is new |
| Eligibility, compatibility or discount rules | Declarative rules in the product model | Only for rules that need external data at runtime |
| A new fulfilment system in the order flow | New orchestration items and decomposition rules | The adapter to that system, if no Open API exists |
| A different agent or customer journey | Limited — layout and flow options only | OmniScript, FlexCards, Integration Procedures |
| A new external API contract | Only where a standard TM Forum API already covers it | Custom endpoint, mapping and error handling |
| Logic that must run mid-transaction | Where the product exposes a rule for it | Apex, kept behind a documented boundary |
The rule we hold ourselves to: if the product can express it, we configure it. Custom code is a decision with a named reason and an owner, because every line of it is something you will carry through each Salesforce release.
Each of these is a real engagement with its own scope, its own team shape and its own exit criteria. Most operators start with one and add the next once the first is running.
A full Communications Cloud build — data model, catalog, CPQ, ordering and integration — delivered in phases with a working slice at the end of each.
Moving off a legacy commercial stack, or onto the current Communications Cloud runtime, without losing the subscription history that billing depends on.
Connecting Communications Cloud to the billing, provisioning, inventory and finance systems that surround it — with the data contracts written down.
OmniStudio journeys, agent consoles and extensions where the standard configuration surface genuinely runs out — with the boundary documented.
Ongoing ownership after go-live: catalog releases, orchestration changes, incident response and the release governance that keeps it all safe.
Agentforce for Communications grounded in your own catalog, order and asset data — so an agent can answer and act, not just summarise.
Also part of this practice: Communications Cloud optimization, order management & automation, and API & systems integration.
Communications Cloud is the commercial system of record. It does not replace your billing platform or your provisioning stack — it has to negotiate with them. These are the connections that decide whether an order completes.
So finance bills what was actually sold and activated. Activated order lines, rated products, contracted prices and discount terms flow out to the charging platform — Amdocs, Netcracker, CSG or Aria. Invoice status, balance, and payment and dunning state flow back onto the account, so care agents see a failed payment before the retention call, not after it.
So a sale becomes a working service. The decomposed technical order sends fulfilment requests out to activation and provisioning systems as orchestration items. Activation status, assigned service identifiers, jeopardy signals and completion events come back to advance or fail the orchestration plan — which is what makes an accurate order status possible.
So integrations are reusable instead of rebuilt per project. MuleSoft's API-led pattern puts system APIs over the legacy BSS estate, orchestrates them in process APIs, and exposes them to Communications Cloud along TM Forum Open API shapes. The payoff is that replacing a billing platform later changes one system API, not every consumer of it.
So you only sell what you can actually deliver at that address. Serviceability and qualification calls go out from the cart at quote time; available technologies, speeds and capacity come back before the customer commits. This is the single highest-value check to get right — it is where most order fallout is created.
So an install appointment is part of the order, not a separate process. Orders that need a truck roll raise work orders out to Field Service as an orchestration step; appointment windows, technician status and completion come back to release the next step in the plan. The customer sees one order status, not two systems.
So commercial reality reaches the general ledger. Contracted revenue, order value, and cost and commission triggers flow out to SAP, NetSuite or the finance platform of record; cost centre, entity and approval data flow back to keep quoting inside financial policy. Multi-entity operators need this settled before go-live, not after the first close.
The API layer itself — TM Forum conformance, event design, retry and error semantics — is covered in depth on Communications Cloud API & systems integration. Broader Salesforce integration work sits on Salesforce integration services.
We sequence the work so the riskiest decisions — the product model and the integration contracts — are made and tested early, while they are still cheap to change.
We map the offer portfolio, the order journeys and the BSS/OSS estate as it is now, and identify where orders actually fail today. The output is a target architecture and a sequenced plan, not a slide deck.
We rationalise and model the catalog in EPC — commercial offers separated from technical services, with pricing, eligibility and compatibility rules. CPQ parameters are settled here on purpose: changing them after build has started is expensive.
Cart, quoting, contracts and the ordering surface across the channels you sell through, including MACD so changes and disconnects are first-class orders rather than workarounds.
Decomposition rules, orchestration plans and the integrations to billing, provisioning, inventory and field service — with error, retry and reconciliation behaviour designed rather than discovered in production.
Migration, parallel run, a controlled cutover and hypercare while real orders flow. Then either your team takes it, or ours keeps running it — and we are explicit about which from the start.
On those ranges: they describe engagements we have scoped, and they move with two variables more than any other — how many products end up in the catalog, and how many fulfilment systems the order has to touch. A single-market broadband launch and a multi-country converged operator are not the same programme. We size both in discovery, before you commit to a delivery budget.
These are the operating changes a correctly modelled Communications Cloud produces. They are described in the terms your own teams will use to judge whether the programme worked.
A new offer is a catalog change
Product managers assemble and price offers in the catalog instead of raising a development ticket, so launching a bundle stops competing with the release calendar for capacity.
Orders complete without a human relay
Decomposition turns the commercial order into a technical one and the orchestration plan drives it through fulfilment, so the exceptions queue holds genuine exceptions rather than routine work.
"Where is my order" has an answer
Order, asset, contract and activation state sit on one record, so an agent answers from the system instead of calling provisioning — and the same state is what a self-serve channel or an AI agent reads.
Upgrades stop corrupting the asset record
Moves, adds, changes and disconnects run as MACD orders against the existing subscription, with the associated charges calculated as part of the order rather than reconciled afterwards.
B2B deals are quoted once
Multi-site configuration, contracted pricing and grouped ordering happen in the system that produces the contract, so what was sold and what gets billed are the same thing.
Integrations survive the next vendor change
Standards-shaped interfaces and a documented data contract mean replacing a billing or provisioning platform is a bounded piece of work instead of a second transformation programme.
Related Twopir work
For how this sits against wider operator systems, see Salesforce for telecom infrastructure and the Salesforce for telecommunication excellence case study. Named communications-provider references are discussed under NDA in a scoping call.
We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges. In communications, that usually means one of these five shapes.
High order volume, frequent plan change, device and SIM logistics, and a charging platform that has to be told exactly what changed and when.
Address-level serviceability, install appointments and a footprint that changes constantly — where qualification at quote time is the difference between a clean order and a truck roll that fails.
Capacity-constrained selling across regions and partners, where the catalog has to express what can be sold where, and the order has to reserve capacity as part of activation.
Multi-site quoting, contracted rate cards, bulk MACD and renewal cycles — the segment where spreadsheets survive longest and cost the most.
Partner-facing catalogs, negotiated commercial terms and machine-to-machine ordering, where the API surface is the product experience.
Connectivity bundled with managed IT and hardware, where one customer order spans your own services and several suppliers' delivery timelines.
Communications Cloud programmes rarely fail on configuration. They fail on decisions made in the first six weeks — the product model, the integration contracts, and what was quietly promised to be custom.
The catalog is the schema your commercial business runs on. We design the separation between commercial offers and technical services first, because every downstream decision — pricing, ordering, decomposition, billing — inherits from it.
Rebuilding legacy product structures inside Communications Cloud is the most reliable way to make a project longer and more expensive than it needed to be. We review the process and the portfolio before migration, and we push back when a requirement is only a legacy habit.
Custom code is sometimes the right answer and it is never free. We name the boundary in writing, we keep extensions behind it, and we tell you what each one will cost you at the next platform release.
Order flow-through depends on what happens when a downstream system is slow, wrong or unavailable. We design retry, compensation and reconciliation behaviour explicitly, because that behaviour is what your operations team will live inside.
The real test is the second and third catalog release, when the model meets requirements nobody anticipated. We run managed services for the platforms we build, so the people who made the design decisions are the ones who answer for them.
No. Salesforce Communications Cloud is a business support system suite for communications service providers — product catalog, CPQ, contracts, digital commerce and order management for telecom services. Multi-channel customer messaging, such as billing notifications and promotional sends, is Marketing Cloud work and is a different product with a confusingly similar name. Twopir covers that separately on its communication cloud engagement page. If you are deciding between them: Communications Cloud answers "how do we model, sell and activate services", Marketing Cloud answers "how do we message customers".
Effectively yes. Salesforce Communications Cloud was previously sold as Vlocity, and Salesforce acquired it. Documentation, training material and job descriptions still reference Vlocity, and some components keep Vlocity-era naming — which matters in practice because an older implementation guide you find may describe the same capability under a different name. If your organisation already runs a Vlocity-era deployment, moving to the current runtime is a defined piece of work rather than a reimplementation.
Sometimes, and we will tell you when. Standard CRM and CPQ handle products, pricing and quoting well. What they do not provide out of the box is the telecom-specific layer: separating commercial offers from technical services in the catalog, decomposing a commercial order into a technical order, orchestrating fulfilment across provisioning and billing systems, and expressing moves, adds, changes and disconnects against an existing subscription. If your service is simple, static and has no provisioning dependency, the standard stack may well be enough. If order fallout, MACD handling or multi-site B2B quoting is where you actually lose money, that is what Communications Cloud exists to fix.
No, and a project that assumes it does will run into trouble early. Communications Cloud is the commercial system of record: it models the catalog, produces the quote and the contract, creates the order and orchestrates fulfilment. Rating, charging and invoice production stay in your billing platform, and service activation stays in your OSS. The value comes from the contract between them being explicit — what is sent, what comes back, and what happens when a downstream system fails. That integration design is most of the engineering risk in the programme.
It depends on two things far more than on anything else: how many products end up in the catalog, and how many fulfilment systems the order has to touch. A focused first release — one segment, one channel, a rationalised catalog and a small number of integrations — is typically a few months of build after discovery and catalog design. A converged multi-country operator replacing a legacy BSS is a multi-phase programme measured in quarters. We size it in discovery and sequence it so the first working slice arrives early, rather than quoting a single number before anyone has seen the product portfolio.
The Enterprise Product Catalog is where products, offers and the technical services behind them are modelled, along with their pricing, eligibility and compatibility rules. It matters because it is the schema everything else inherits: quoting, ordering, decomposition and billing all read from it. Salesforce's catalog is certified against the TM Forum Information Framework (SID), the telecom industry's standard information model, which is what allows a well-designed catalog to describe both what a customer buys and what the network has to deliver. Catalog design is also the decision that is most expensive to revisit, which is why we settle it before build rather than during it.
Salesforce builds and licenses Communications Cloud; the catalog engine, the CPQ, the order management and the TM Forum API surface are Salesforce capabilities, not ours. Twopir Consulting is the implementation partner: we design the product and data model, configure the catalog, quoting and orchestration, build the integrations to your billing and provisioning estate, migrate the data, run the cutover, and then support or manage the platform afterwards. Twopir Consulting is a Salesforce Partner and a HubSpot Partner. We do not resell Salesforce licences, and we will say plainly when the product is not the right fit for the problem you have described.
A scoping call with an architect, not a sales qualification script. We will look at your product portfolio, your order flow and your BSS estate, and give you an honest read on sequence, effort and what should come first.
Speak with a team that understands catalog, order & BSS architecture
