Commercial Order Management (COM)
Last updated 14 Oct 2026
At a glance
Commercial Order Management (COM) is where every customer order enters fulfilment. It turns a confirmed quote from any channel into a Product Order, validates it, manages its commercial lifecycle (approvals, amendments, cancellation) and starts fulfilment by mapping product items to service items. It works only at the product layer.
The picture
COM order processing flow: from channel capture to SOM handoff
Sales Channels
Commercial Order Management (COM)
BSS — Product Layer
TMF622 POST
Product → CFS Mapping
TMF620
TMF641 POST
Service Order Management (SOM)
Receives decomposed service orders
TMF638
COM decomposes the product order using the Product Catalog, then hands off CFS-level service order items to SOM via TMF641
How it works
Where COM sits
COM sits between the customer-facing world (CRM, CPQ, digital channels) and technical fulfilment (SOM, ROM). It knows Product Offerings, Product Specifications and product instances. It does not know CFS, RFS or network resources. Orders arrive from portals, retail, call centres, partners and B2B APIs, and COM normalises them all into one canonical Product Order, so the internal model does not depend on the channel.
Capture to fulfilment
Select
Channel · TMF620The channel queries the catalog for eligible offerings; the customer picks one.
Configure and price
CPQCPQ checks mandatory options, incompatibilities and address eligibility, resolves price, discounts and tax, and presents a quote.
Confirm
TMF622The customer accepts terms and authorises payment. The confirmed quote is submitted as POST /productOrder.
Create
COMCOM assigns an order ID and sets the state to acknowledged.
Validate and enrich
COMCredit check, fraud screening, duplicate detection, address qualification and internal references.
Start fulfilment
TMF641COM maps each product item to CFS items from the catalog and submits a service order to SOM. The product order moves to inProgress.
Order types are set by item actions
| Type | Item actions | What COM must handle |
|---|---|---|
| New / provide | All add | Full address qualification and, for new customers, credit. Most fallout happens here. |
| Modify | add, modify, delete, noChange | Reads the current instance; only the delta goes to SOM. May need pro-rata billing. |
| Cease | All delete | May be future-dated to contract end; may trigger termination fees and a final bill. |
| Migrate / move | Cease plus provide, or one complex order | Make before break where possible; technology may differ at the new address; contract continuity. |
modify, speed), Static IP (add), Router Rental (noChange), Wi-Fi App (noChange). Only the speed change and the static IP flow to SOM.Lifecycle states (TMF622)
Items have their own states. The order state is derived from them: all items complete, the order completes; some succeed and some fail, the order is partial.
| State | Terminal | Meaning |
|---|---|---|
| acknowledged | No | Received, ID assigned, schema valid |
| inProgress | No | Validated, service orders with SOM. Usually the longest state |
| held | No | Paused for approval, customer contact or jeopardy |
| pending | No | Waiting for a date, appointment or third party |
| assessingCancellation | No | Working out which fulfilled items must be reversed |
| completed | Yes | All items fulfilled, inventory updated, billing active |
| partial | Yes | Some items done, others failed; needs an operational decision |
| failed | Yes | Could not complete; compensation run |
| cancelled | Yes | Stopped by the customer or a rule before completion |
| rejected | Yes | Failed validation; never entered fulfilment |
COM and the installed base
COM uses Product Inventory (TMF637), the record behind SLM, in two directions. It reads the current product instance for modify and cease orders, compares it with the ordered configuration and sends only the difference downstream. It writes on completion: a new instance for a provide, an update for a modify, termination for a cease.
In TMF622 the product field in each order item is that bridge. For add it describes the instance to create; for modify it carries the existing instance ID plus the changes; for delete it references the instance to cease. Other item fields that matter: action, productOffering (the catalog reference), productCharacteristic, itemPrice, orderItemRelationship and appointment.
Handing off to SOM
Decomposition into CFS is catalog-driven: COM reads the Product Specification to find which CFS it needs. "SuperFibre 200 Home" becomes Internet-Access, Wi-Fi-Management and CPE-Management, sent as one service order. Edge cases are real: modify needs delta detection, bundles with shared components need deduplication, and technology choice may depend on the address. Some estates decompose in COM; others use a separate decomposition engine between COM and SOM. 8.3 takes it from there.
Everyday complications
- Amendment in flight: decide which downstream work can be changed and which must be cancelled and resubmitted.
- Priority: VIP, enterprise SLA and regulatory orders go first without starving the rest.
- Multi-product orders: broadband, TV and voice decompose separately but may share services or depend on each other.
- Scheduled orders: held until released with enough lead time to provision.
- Versioning: every amendment kept for audit and disputes.
- Partial fulfilment: wait, complete what works, or fail the whole order.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Product Order | COM | CRM / channel portal / CPQ | Product Catalog (TMF620) | TMF622. COM creates and owns it for its whole lifecycle. |
| Product Order Item | COM | CPQ (initial configuration) | Product Offering / Specification | Each item references a catalog offering and carries the selected options. |
| Order price | COM (confirmed) | CPQ (quoted) | Product Offering Price (TMF620) | CPQ quotes; COM confirms at order time. |
| Product instance | Product Inventory (SLM) | COM (triggers create and update) | — | TMF637. COM triggers the change; it does not own the instance. |
In practice
Channel-specific needs are met by backend-for-frontend (BFF) APIs in front of a single TMF622 interface. The mobile app and the B2B portal each get a shape that suits them, and COM keeps one order model.
Modify and cease orders expose the installed base. If existing customers were provisioned before COM and Product Inventory existed, there is no current instance to diff against, and the first modify for each of them falls out or needs a manual migration step.
The trade-off
What it solves
It gives every channel one order model, one set of commercial rules and one lifecycle, and it is the single owner of the commercial order from capture to completion.
What it does not solve
- Product modelling. COM validates and decomposes only as well as the catalog defines offerings and their CFS.
- An installed base that was never recorded in Product Inventory.
- Technical fulfilment. Service and resource work belong to SOM and ROM.
What it adds
- Cancellation and amendment of orders already partly fulfilled downstream.
- Keeping the product order state honest while SOM and ROM run for days.
- A canonical order model that every channel and BFF must map into.
Architecture decision
Where should product-to-CFS decomposition run?
In COM
Choose when the product-to-CFS mapping is simple and stable, and COM can read it from the catalog without technology-specific logic.
In a separate decomposition engine between COM and SOM
Choose when bundles share components, modify orders need complex delta detection, or several COMs (per business unit) feed one SOM.
Breaks if Decomposition starts using address or technology logic inside COM. Commercial systems become tied to the network, and every access technology change becomes a BSS release.
Takeaways
Key Takeaways
- COM is the entry point for every customer order and works only at the product layer
- It normalises all channels into one Product Order over TMF622
- Order type follows from item actions: add, modify, delete, noChange
- The order state is derived from item states; partial is a real terminal state
- COM reads Product Inventory to compute the delta for change orders and writes it on completion; Product Inventory, not COM, owns the instance
Check yourself
A customer adds a static IP to an existing broadband product. Which items does the product order contain, and what reaches SOM?Show answerHide
The broadband item as
noChangeormodify, the static IP asadd, and the rest asnoChangefor context. Only the changed items (the static IP, plus any real modification) produce service order items for SOM.Two of three items in an order completed; the third failed after retries. What state is the product order in, and who decides what happens next?Show answerHide
partial. Someone in operations or a business rule decides whether to accept the completed items, retry, or compensate; COM records the decision and the outcome.
Billing starts charging the moment an order is captured in the CRM. What is missing?Show answerHide
COM as the owner of the order lifecycle, and Product Inventory as the trigger for billing. Charging should start from a completed product instance, not from capture.