A Salesforce Communications Cloud implementation is a BSS programme, not a CRM rollout. It replaces or fronts the systems that decide what you can sell, what a customer is charged, and whether an order reaches the network. This page sets out what the programme actually involves — the phases, the deliverables, what your team has to supply, and what go-live has to prove. Written for the people who will be accountable for it.
Trusted by 500+ organizations — including connectivity and communications providers running complex, integration-heavy Salesforce programmes with Twopir Consulting.
Implementation Scope
None of these is a configuration problem. Every one of them is a decision made — or avoided — early, that only becomes visible once build is underway and expensive to undo.
Modelling and configuration happen at the same time, so the product model changes underneath work that already depends on it. Catalog design is a phase with its own sign-off, not an activity that runs alongside the build.
Several CPQ configuration choices are extremely difficult to change once a project is underway. Deciding them late, or letting them be set by whoever configures first, is one of the most common sources of mid-programme rework.
Carrying legacy product structures and equivalent functionality straight into Salesforce Industries is the single most reliable way to make a programme longer and more expensive. The portfolio and the process need reviewing before migration, not after.
Treating integration as a later phase hides the hardest problems until the end. What a downstream system does when it is slow, wrong or unavailable is design work, and it belongs alongside the build, not after it.
If no internal team can change the catalog after go-live, the operator has bought a dependency rather than a capability. Ownership has to be built during the programme, not handed over in a training session at the end.
Without measurable exit criteria — order flow-through, fallout rate, the changes your own team can make unaided — there is no way to tell a successful cutover from a deferred problem. We define those criteria in discovery.
A Salesforce Communications Cloud implementation takes an operator's commercial business — its products, prices, rules, channels and order flows — and expresses it as a working model on the Salesforce platform, then connects that model to the billing and provisioning systems that deliver the service. In practice the programme has five phases: discovery, product and catalog modelling, quote-to-order build, orchestration and integration, and cutover with hypercare. The middle three overlap; the first and last do not.
The work divides into two very different halves, and confusing them is what makes estimates wrong. The first half is modelling: deciding how your offers, services, prices and eligibility rules should be represented. It is mostly analysis and design, it is done with your product and commercial people, and it determines how much of the second half is even necessary. The second half is construction: configuring the catalog, quoting, contracts and orchestration, building the integrations, migrating the data and proving the whole thing under load. A good first half makes the second half shorter. A skipped first half makes it open-ended.
Salesforce provides the platform and the components — the Enterprise Product Catalog, Industries CPQ, Contract Lifecycle Management, Digital Commerce, Order Management and the TM Forum Open API surface. Twopir Consulting provides the implementation: the design decisions, the configuration, the integration engineering, the migration and the cutover. What your organisation provides is described in the table below, because a programme where that is left vague is a programme that slips.
If you are still deciding whether you need the product at all, start on Salesforce Communications Cloud consulting, which covers what the product is, who it suits, and when standard CRM and CPQ would serve you better. This page assumes that decision is made.
We sequence so the decisions that are most expensive to reverse happen first, and so something demonstrable exists at the end of every phase rather than only at the end of the programme.
We map the offer portfolio, the order journeys across every channel, and the BSS/OSS estate as it really is. We find where orders fail today and why. Output: a target architecture, a sequenced plan, and the measurable go-live criteria we will be held to.
Rationalise the portfolio, then model it in the Enterprise Product Catalog — commercial offers separated from technical services, with pricing, eligibility and compatibility rules. CPQ parameters are decided and signed off here, deliberately, before anything depends on them.
Cart, quoting, contracts and the ordering surface for the channels you actually sell through — assisted, self-serve, partner and retail. MACD is built as a first-class path in this phase, not retrofitted once someone notices upgrades do not work.
Decomposition rules, orchestration plans, and the integrations to billing, provisioning, inventory and field service. Error, retry, compensation and reconciliation behaviour is designed here — this is the workstream that most often determines the real go-live date.
Data migration with reconciliation, a parallel run where the shape of the business allows it, a controlled cutover, and hypercare while real orders flow. We agree in advance who owns the platform afterwards, and we build toward that from Phase 01.
What each phase produces — and what your team supplies
| Phase | What we deliver | What you supply |
|---|---|---|
| 01 · Discovery | Target architecture, sequenced plan, measurable go-live criteria | Access to system owners, current-state documentation, decision-makers |
| 02 · Catalog model | Rationalised portfolio modelled in EPC, signed-off CPQ parameters | Product and commercial owners who can decide, not just review |
| 03 · Quote to order | Configured cart, quoting, contracts, MACD and channel surfaces | Business validation of pricing and eligibility against real deals |
| 04 · Orchestration | Decomposition rules, orchestration plans, integrations, error handling | Downstream system access, test endpoints, and their owners' time |
| 05 · Cutover | Migration, reconciliation, cutover runbook, hypercare, handover | UAT participation, cutover window, named post-go-live owners |
The column on the right is the one programmes underestimate. Communications Cloud implementations are gated far more often by decision latency and downstream-system access than by configuration effort, which is why we name the required client roles in the statement of work rather than discovering them in week nine.
These are not stages. Each one starts in discovery and stays live until handover, and each has a named owner on both sides.
Turning a commercial portfolio into a model the platform can execute — and that your product team can change afterwards.
The selling surface across every channel, including the change orders that most projects discover late.
How a commercial order becomes a technical order and reaches the systems that fulfil it.
The connections to billing, provisioning, inventory, field service and finance — designed, not improvised.
Moving customers, subscriptions, assets and contracts without breaking what billing depends on.
Keeping configuration, code and catalog data moving safely between orgs from the first sprint.
Six choices you will live with long after go-live. We make them explicitly, with you, and write down why.
How many orgs, how they are refreshed, and how catalog data moves between them. Communications Cloud configuration lives partly in metadata and partly in data, so an environment plan that only covers metadata will strand your catalog. Decide the refresh cadence before UAT, because a mid-UAT refresh that wipes test catalog data costs a week.
Salesforce Industries configuration deploys as DataPacks alongside standard metadata, using the CLI build tool or the IDX Workbench desktop application, and the repository can serve as source or target. Choosing the pipeline in Phase 01 — rather than the week before the first release — is what keeps parallel workstreams from overwriting each other.
Catalog-driven systems fail in combinations, not in single paths. The test approach has to cover offer permutations, eligibility edge cases, MACD against existing assets, and order flow-through with downstream systems stubbed and live. We build the regression suite during delivery so it exists at cutover.
Whether you migrate active subscriptions as assets with full history, or start clean and let the legacy system run off, changes the programme shape completely. It is a commercial decision as much as a technical one, and it has to be made in discovery because everything downstream depends on it.
Who owns the catalog, who approves an orchestration change, and who is called at 2am. A platform nobody internally owns degrades within two release cycles. We define the target operating model early and build toward it, including the training that makes it real.
How orders in flight are handled, what happens to a partially provisioned order at the switch, and what the fallback actually is. Writing the runbook early surfaces the gaps while there is still time to close them — a cutover plan written in the final fortnight is a plan nobody has tested.
Agreed in discovery, measured at cutover. Each one is deliberately observable rather than a matter of opinion.
Orders complete without manual help
Order flow-through is measured against the baseline captured in discovery, so the improvement is a number both sides agreed on before the programme started.
Your team changes the catalog unaided
A named internal owner builds and releases a new offer without us in the room. If that cannot happen at handover, the programme is not finished, whatever the burndown says.
Every channel sells the same thing
Assisted, self-serve and partner channels read the same catalog and the same rules, so a customer is quoted one price regardless of where they started.
MACD works on day one
Upgrades, moves, suspensions and disconnections run as change orders against existing subscriptions, with charges calculated as part of the order rather than reconciled later.
Failures are visible and recoverable
When a downstream system fails, the order is in a known state, the exception is visible to a named team, and there is a documented path to recover it without re-keying.
Someone can run it at 2am
Runbooks, alerting, known limits and an escalation path exist and have been rehearsed — whether the platform is handed to your team or stays with ours.
Related Twopir work
Related work: Communications Cloud migration, integration, and support & managed services for what happens after cutover. For context on operator systems more broadly, see Salesforce for telecom infrastructure.
The fastest way to reduce the cost of a Communications Cloud implementation is to reduce what it has to build. That work happens in modelling, and it is the phase most partners compress.
It gets its own sign-off, its own owners and its own exit criteria. Every downstream estimate depends on the model, so a model settled late makes every later estimate unreliable.
A surprising share of any portfolio exists because an old system could not express something more simply. We review the process and the portfolio before migration, and we will tell you when a requirement is costing more than it returns.
Your product team makes catalog changes in Phase 03, in a real environment, with us beside them. Handover is then a formality rather than an event, because it has already been happening for months.
The interesting question is never the happy path. Retry, idempotency, compensation and reconciliation are designed alongside the build, because that behaviour is what your operations team will actually live inside.
Order flow-through, fallout rate, and the changes your own team can make unaided. Agreeing them at the start is what stops "live" and "working" from drifting apart at the end.
It is driven by two variables far more than any others: 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 a working slice exists early, rather than quoting a single duration before anyone has seen the portfolio.
More than most programmes assume, and it is concentrated in specific roles. You supply product and commercial owners who can decide rather than review, access to the owners of your billing, provisioning and finance systems, test data and environments, business validation of pricing and eligibility against real deals, UAT participation, and named owners for after go-live. Communications Cloud programmes are gated by decision latency and downstream-system access far more often than by configuration effort, so we name the required roles in the statement of work rather than discovering them in week nine.
Almost never, and this is the most valuable thing we will tell you early. Salesforce's own implementation guidance advises against a lift-and-shift approach — carrying equivalent legacy functionality and product structures into Salesforce Industries makes the project more complex and slower to go live. A large share of most portfolios exists because an older system could not express something more simply. Reviewing business processes and rationalising the portfolio before migration is the single biggest lever on cost and timeline.
Phased is usually better and is how we sequence by default. Common first slices are a single segment, a single channel, or a single product family — enough to prove catalog, quoting, ordering and at least one real fulfilment integration end to end. That proves the architecture under real orders while the remaining portfolio is still being modelled. A single big-bang cutover is sometimes forced by a legacy contract expiry or a billing migration, and when it is, the fallback plan matters far more than it otherwise would.
Industries CPQ carries configuration settings that shape how pricing, cart behaviour and product configuration work across the whole implementation. Salesforce's own best-practice guidance is to define them well at the very beginning, because modifying them once a project is underway causes significant problems — anything already configured against the old behaviour has to be revisited. We settle and sign off these parameters in the catalog modelling phase, before build work starts depending on them.
Salesforce Industries configuration deploys as DataPacks alongside standard Salesforce metadata. There are two supported routes: a command-line build tool for pipeline-driven deployment, and the IDX Workbench desktop application for a UI-driven one, with a Git repository usable as either source or target. The important decision is not which tool but when: agreeing the environment and deployment strategy in Phase 01 is what stops parallel workstreams from overwriting each other's catalog data later.
Hypercare first — we stay on while real orders flow and the exceptions that only production produces start appearing. After that the platform either transfers to your team, which is why we build internal ownership from Phase 01, or stays with ours under a managed service covering catalog releases, orchestration changes, incident response and platform-release readiness. We agree which of those it will be during discovery, because the two produce different handover artefacts and different training.
A scoping conversation with the architect who would run the programme. We will look at your product portfolio, your channels and your downstream estate, and give you an honest read on phasing, effort and what should come first.
Speak with a team that has sequenced this programme before
