Order Management Overview
Last updated 14 Oct 2026
At a glance
Telco order management turns a customer request into network change. What the customer buys is not what the network delivers, so the order is handled in three layers: COM for the commercial order, SOM for services and ROM for resources. Orders decompose down the layers; completion rolls back up.
The picture
BSS Front-Office (CRM / CPQ / Billing)
BSSCRM
CPQ
Billing
Commercial Order Management (COM)
BSSProduct Order
TMF622
Product Catalog
TMF620
SLM
TMF637 Product Inventory
Service Order Management (SOM)
OSSService Order
TMF641
Service Catalog
TMF633
Service Inventory
TMF638
Resource Order Management (ROM)
OSSResource Order
TMF652
Resource Catalog
TMF634
Resource Inventory
TMF639
Network Infrastructure
INFRAOLT / Switch
BNG / Router
DHCP / IPAM
How it works
What order management does
Order management receives a request (new, modify, cease), decomposes it through catalog rules into work at the commercial, service and resource layers, runs that work in dependency order, and tracks it to completion or rollback. In eTOM it sits under Order Handling.
A retail order is close to a payment followed by a shipment. A telco order is a cascade. "SuperFibre 200 Home" becomes OLT port configuration, VLAN and IP assignment, a QoS policy, CPE set-up, a billing account and inventory updates, in the right sequence, with a way back if a step fails.
Why one order entity is not enough
| Commercial | Service | Resource | |
|---|---|---|---|
| Concern | Products, prices, contracts, commitments | Customer-facing services (CFS) and their orchestration | Network resources, device configuration, activation |
| Owner | BSS / CRM teams | Service management / OSS teams | Network engineering / OSS teams |
| Timing | Minutes: captured, priced, confirmed | Hours to weeks | Hours to weeks: ports, field visits, equipment |
| Granularity | One order item | Several CFS items | Many resource items |
One "200 Mbps Broadband" item may become three service order items and seven or more resource order items. There is no 1:1 between what the customer sees and what the network does, which is why each layer has its own order, API and inventory.
The three layers
| Layer | Works on | Order API | Reads | Writes |
|---|---|---|---|---|
| COM | Product Order and its items, each referencing a Product Offering | TMF622 | Product Catalog (TMF620) | Product Inventory (TMF637) |
| SOM | Service Order: CFS items, decomposed into RFS | TMF641 | Service Catalog (TMF633) | Service Inventory (TMF638) |
| ROM | Resource Order: RFS and resources | TMF652 | Resource Catalog (TMF634) | Resource Inventory (TMF639) |
The pattern repeats at every layer: the catalog defines the decomposition rules, the order executes them, the inventory records the result.
One order through the layers
Customer orders
Channel / CPQThe customer picks "SuperFibre 200 Home" in a channel. CPQ validates the configuration and hands it to COM.
COM captures and validates
COMCOM creates the Product Order, checks catalog rules, price and credit, handles approvals, then maps product items to CFS items from the catalog.
SOM orchestrates services
SOMSOM receives the CFS items (Internet Access, Wi-Fi Management, CPE Management), decomposes them to RFS and plans what runs in parallel and what waits.
ROM allocates and activates
ROMROM assigns free OLT ports, VLAN IDs and IP addresses, configures the network elements and confirms.
Completion rolls up
ROM → SOM → COMROM completes, so SOM completes, so COM completes. Each layer updates its inventory on the way. The customer is told.
Each API supports synchronous REST (POST to create, GET to query, PATCH to update) and asynchronous events. State changes such as "item completed" or "order failed" are usually published as events, so the layer above reacts without polling.
Order types
| Type | COM item actions | Effect in SOM / ROM |
|---|---|---|
| New / provide | All add | Full decomposition and provisioning at every layer |
| Modify / change | Mix of add, modify, delete, noChange | Only the delta flows down |
| Cease / disconnect | All delete | Decommission in reverse: ROM first, then SOM |
| Migrate / move | Cease old and provide new, or one complex modify | Old resources released, new ones provisioned at the new place |
| Suspend / resume | Status change, no structural change | Service state changes; resources may stay allocated |
What makes it hard
- Amendments: the customer changes the order while it is in flight.
- Partial completion: some items succeed and others fail, so something must be compensated.
- Consistency: product, service and resource inventories must stay in step.
- Dates: promised delivery dates must be watched and escalated.
- Volume and third parties: enterprise bulk orders, field engineers, suppliers and number ports.
Who owns what
| Entity | System of Record | System of Engagement | System of Reference | Notes |
|---|---|---|---|---|
| Product Order | COM | CRM / channel portal | Product Catalog | TMF622. COM holds all commercial order state. |
| Service Order | SOM | COM (submitter) | Service Catalog | TMF641. COM submits it but does not own it. |
| Resource Order | ROM | SOM (submitter) | Resource Catalog | TMF652. SOM submits it but does not own it. |
| Product instance | Product Inventory (SLM) | CRM / self-service | Product Catalog | TMF637. Created or updated when the product order completes. |
| Service instance | Service Inventory | SOM | Service Catalog | TMF638. Written as SOM completes service order items. |
| Resource instance | Resource Inventory | ROM | Resource Catalog | TMF639. Written as ROM allocates and activates. |
In practice
Few brownfield estates have three clean layers. Commonly the CRM or billing system doubles as the order manager, or COM sends work straight to activation with no SOM. Each layer that is missing pushes its job into a neighbour: COM learns network technology, or ROM scripts carry service logic.
The trade-off
What it solves
It separates commercial, service and resource concerns, so each can change at its own pace, and gives each layer one owner for its order and inventory.
What it does not solve
- Poor catalog models. Every layer decomposes only as well as its catalog allows.
- Inaccurate inventories, especially for customers provisioned before the stack existed.
- Field and third-party delays, which the layers can track but not shorten.
What it adds
- Three order state machines, three sets of events and three fallout queues to keep consistent.
- Three catalogs and their decomposition rules to model, test and govern together.
- Cross-layer compensation when something fails late in the chain.
Architecture decision
How many order layers does this estate need now?
All three: COM, SOM and ROM
Choose when several technologies or network domains, modify and cease orders matter, and assurance needs to link network faults to customers.
COM and SOM, with domain controllers below
Choose when each network domain already has a controller or platform API that assigns and configures for itself.
COM only, driving activation directly
Choose when one product family on one technology, mostly new connections, and a funded plan to add the service layer before the second technology.
Breaks if A layer is skipped without a plan to add it. Its logic settles in the neighbouring system, and every later product inherits the shortcut.
Takeaways
Key Takeaways
- Telco order management has three layers: COM (commercial), SOM (service) and ROM (resource)
- The layers differ in concerns, owners, timing and granularity, so one order entity cannot serve all three
- Orders decompose top-down by catalog rules; completion rolls up bottom-up
- Each layer has its own order API (TMF622, TMF641, TMF652) and its own inventory
- Fallout, amendments and partial completion are everyday work, not edge cases
Check yourself
A product order completed in COM ten minutes after capture, but the customer has no service for a week. Is something wrong?Show answerHide
Yes. The commercial steps can finish in minutes, but the product order should stay inProgress until SOM reports completion. Closing it on capture hides the real state from care, billing and the customer.
Why does a cease order decommission ROM first and SOM second?Show answerHide
It reverses the build order. Resources are deactivated and returned to the pool, then the services that depended on them are ceased, so no service is left pointing at resources that are gone.
Which system holds the truth that a customer has an active broadband service, and which holds the order that created it?Show answerHide
Service Inventory (TMF638) holds the active service instance; SOM holds the service order. At the product layer, Product Inventory holds the product instance and COM the product order.
Put this to work