Order management is what happens between a customer agreeing to buy and a service actually working. In Communications Cloud that means decomposing a commercial order into a technical one, generating fulfilment requests, and running them through an orchestration plan sequenced across billing, provisioning, inventory and field service — including the change orders that most platforms handle badly. Twopir Consulting designs that lifecycle, including what it does when a step fails.
Trusted by 500+ organizations — including connectivity and communications providers automating order-to-activate with Twopir Consulting.
Order Capabilities
Each of these is a design decision that was never made, rather than a system that failed.
Without decomposition rules, somebody reads the order and types it into provisioning. Every error, every delay and most disputed first invoices begin at that keyboard, and the cost scales linearly with volume.
Upgrades, moves, suspensions and disconnections are modelled as new sales, so agents cancel the existing subscription and create a replacement. The asset record loses its history and billing inherits the mess.
When an orchestration item fails there is no modelled exception state, so the order leaves the platform for a queue. It is now invisible to reporting, to the customer and to any automated recovery.
Orders have expected durations per step, but nothing compares actual against expected. Problems are found when the customer calls, which is the most expensive possible detection mechanism.
Self-serve, assisted and partner each submit orders differently, so decomposition and orchestration behave differently depending on origin. The same product gets fulfilled three ways.
There is no compensation design, so the only way to fix a partially fulfilled order is to unwind it by hand and resubmit — which is slow, error-prone, and frequently leaves the network and commercial states disagreeing.
In Salesforce Communications Cloud, order management is the process of taking a submitted commercial order and driving it to an activated service. It happens in two mechanisms that are worth understanding separately. Order decomposition prepares an order for orchestration: it transforms the commercial order — what the customer bought — into a technical order describing what has to be delivered, and generates the fulfilment requests that the downstream systems will act on. Orchestration then executes those requests: an orchestration plan definition specifies how to fulfil an order across a set of fulfilment systems, grouping processing tasks into orchestration items that run in the correct sequence.
The distinction matters commercially. Decomposition is where the product model earns its keep — a catalog that properly separates commercial offers from technical services can decompose automatically, while a catalog of flat SKUs cannot, which is why order automation projects so often turn into catalog projects. Orchestration is where the integration estate earns its keep: the plan is only as reliable as the systems it calls and the failure behaviour designed around them.
The third piece is MACD — move, add, change and delete. These are changes against an existing subscription rather than new sales: relocating a service, adding products, modifying what is there, or disconnecting it. In Communications Cloud, MACD orders and asset-based orders are the same thing, they are created in Industries CPQ and submitted to order management like any other order, and associated charges such as disconnection fees are calculated as part of the order. Platforms that cannot express MACD force agents to cancel and rebuild, which is the single most reliable way to corrupt an asset record and the billing that depends on it.
Where this page stops. This page is about the order lifecycle itself. Which downstream systems connect, what moves in which direction and who owns each interface is covered on Communications Cloud integration, and the endpoint engineering beneath that on API & systems integration.
Six stages. We design each one explicitly, including what it does when the stage before it went wrong.
The order arrives from any channel in the same shape, with eligibility, compatibility and serviceability already confirmed in the cart. Validating here rather than downstream is what prevents the largest category of fallout, because an order that should never have been taken cannot be rescued later.
The commercial order becomes a technical order, and fulfilment requests are generated for each system that has to act. This is driven by the product model, which is why decomposition quality is really catalog quality wearing a different hat.
An orchestration plan is instantiated: orchestration items grouped and sequenced across billing, provisioning, inventory and field service, with dependencies expressed so that parallel work runs in parallel and dependent work waits.
Items dispatch to their systems and responses advance the plan. Expected durations are compared against actual, so an order running late raises jeopardy before the customer notices rather than after they call.
Failures hit a modelled exception state with an owner, an SLA and a recovery path — retried where safe and idempotent, compensated where a completed step must be undone, escalated where a human genuinely has to decide.
The service goes live, the asset record is updated to reflect what now exists, billing is told, and commercial and network state are reconciled. The asset record is what care, billing and every future MACD order will read.
The systems this lifecycle calls are covered on Communications Cloud integration; if fallout is your dominant symptom, start with optimization.
Move, add, change and delete are the order types that separate a telecom order platform from a generic one — and the ones most often left until after go-live.
Move, add, change and delete — what each order type must handle
| Order type | What the customer is doing | What the platform has to get right |
|---|---|---|
| Move | Relocating a service from one location to another | Serviceability at the new address, technology change, continuity of identifiers and billing across the move |
| Add | Adding products or services to what they already have | Compatibility with the existing subscription, correct proration, and no disturbance to services already running |
| Change | Modifying an existing product — speed, plan, features | In-life discount and contract handling, proration, and whether the change needs network work or only a billing change |
| Delete | Disconnecting or ceasing a service | Early-termination and disconnection charges calculated as part of the order, asset closure, and dependent-service checks |
In Communications Cloud these are asset-based orders: created in Industries CPQ against the existing subscription and submitted to order management like any other order, with the relevant penalties and incidental charges calculated as part of the order rather than reconciled afterwards. Designing them alongside new-sale journeys — rather than after — is what keeps the asset record trustworthy.
Most engagements start with one of these and extend once it is proving itself in production.
Turning commercial orders into technical ones automatically, which depends more on the product model than on the decomposition rules themselves.
The sequenced execution of fulfilment across every system that has to act, with dependencies expressed rather than assumed.
Change orders as first-class citizens, built alongside new-sale journeys rather than retrofitted once someone notices upgrades do not work.
Making failure a modelled state with an owner and a recovery path, instead of an order that leaves the system.
One truthful answer to "where is my order", readable by care, self-serve and AI agents alike.
Install and engineer visits as steps inside the order rather than as a parallel process with its own status.
Operating changes, stated the way the teams who run orders would state them.
Routine orders need nobody
Orders matching known patterns decompose, orchestrate and activate without intervention, so the people working exceptions are working genuine exceptions.
Upgrades stop breaking the asset record
MACD runs against the existing subscription with charges calculated as part of the order, so history survives and billing reads something true.
One answer to "where is my order"
Order state is modelled and fed by fulfilment responses, so care, self-serve and AI agents all read the same status instead of three different ones.
Late orders announce themselves
Actual duration is compared against expected per step, so an order in trouble raises an alert before the customer calls rather than after.
Failures are recoverable without a rebuild
Modelled exception states, safe retries and designed compensation mean a partially fulfilled order can be recovered rather than unwound by hand.
Fallout can be driven down
Exceptions carry causes, so the queue becomes a backlog with a trend rather than a staffing line that grows with volume.
Related Twopir work
Related: Communications Cloud integration for the systems this lifecycle calls, AI & Agentforce for agents acting on order state, and Salesforce for telecom infrastructure for the wider operator picture.
An orchestration plan that only describes success is a diagram. The design work that matters is what happens at step four when step three succeeded and step five will not.
Decomposition quality is catalog quality. When orders will not decompose automatically, the cause is usually a product model that never separated commercial offers from technical services, and remediating the rules instead is wasted effort.
An exception with a state, an owner, an SLA and a cause can be reported on, routed and reduced. An exception in an inbox can only be worked, forever, by more people.
Change orders are not a phase two. Building them late is how asset records get corrupted, because agents invent cancel-and-rebuild workarounds in the meantime and those habits outlive the fix.
Expected durations come from measurement, not from optimism. A threshold nobody believes gets ignored, and an order that is genuinely late then looks exactly like every false alarm.
Care, self-serve and AI agents all read it, so it is designed once, mapped deliberately from internal state, and kept truthful — rather than assembled differently by each consumer.
Order decomposition prepares an order for orchestration by transforming a commercial order — what the customer bought — into a technical order describing what actually has to be delivered, and generating the fulfilment requests that downstream systems will act on. It is the mechanism that makes automated fulfilment possible, and its quality depends almost entirely on the product model: a catalog that properly separates commercial offers from technical services can decompose automatically, while a catalog of flat SKUs cannot. This is why order automation projects so frequently turn into catalog projects once they start.
An orchestration plan definition specifies how to fulfil an order across a set of fulfilment systems. It groups the processing tasks for the fulfilment requests created by decomposition into orchestration items, which run in the correct sequence — some in parallel, some waiting on dependencies — across systems such as billing, provisioning, inventory and field service. The plan is where the order's real behaviour lives: what happens first, what can happen simultaneously, what has to wait, and what the order does when one of those steps does not come back.
MACD stands for move, add, change and delete: relocating products or services from one location to another, introducing new products or services, modifying existing ones, and removing, disconnecting or discontinuing them. In Communications Cloud, MACD orders and asset-based orders are the same thing — created in Industries CPQ against the existing subscription and submitted to order management like any other order, with relevant penalties and incidental charges such as disconnection fees calculated as part of the order. It matters because most of an operator's order volume after the first year is change rather than new sale, and a platform that cannot express change forces agents to cancel and rebuild, which corrupts the asset record and everything downstream that reads it.
Straight-through processing is not a switch; it is the removal, one at a time, of every reason an order needed a human. In practice that means four things. Validate properly at capture, including serviceability in the cart, so orders that cannot be fulfilled are never taken. Model the catalog so decomposition is automatic rather than assisted. Design orchestration with real dependencies and real expected durations. And model exceptions as states with owners and recovery paths, so the failures that do occur are handled by the system where they safely can be. Most operators find the largest single gain is the first one, because it removes fallout that was manufactured upstream rather than caused downstream.
Jeopardy management is comparing an order's actual progress against its expected progress and raising an alert when it falls behind, before the customer notices. Each orchestration item has an expected duration; when actual exceeds expected, the order is flagged so somebody can intervene while intervention is still useful. Without it, late orders are detected by the customer calling to complain, which is both the most expensive detection mechanism available and the one that produces the worst outcome. The thresholds have to come from measured durations rather than from optimistic estimates, or the alerts get ignored and a genuinely late order looks identical to a false alarm.
An install or engineer visit is modelled as an orchestration item like any other fulfilment step. Orders requiring a truck roll raise a work order to Salesforce Field Service as part of the plan; appointment windows, technician status and completion flow back to release the next step. Because both sit on the Salesforce platform this integration is closer to configuration than to engineering, which is unusual in a telecom estate. The important design outcome is that the customer sees one order status covering the whole journey rather than an order status and a separate appointment status that can disagree with each other.
Yes, and that is the normal case. Communications Cloud orchestrates across whatever fulfilment systems you already have — it does not replace your OSS or your billing platform. What it needs from each of them is a reliable interface and defined failure behaviour: what is sent, what comes back, how long it may take, and what happens on a timeout. Where a system has no usable interface at all, that becomes an integration project in its own right, and it is worth identifying early because it usually sets the pace for everything else.
An order flow review traces your real orders from capture to activation, finds where they leave the automated path, and separates the causes that are upstream from the ones that are genuinely downstream.
Speak with a team that designs step four, not just step one
