🔄

Section 3.2

Commercial Order Management (COM)

How commercial orders are captured, validated, and managed from CPQ through to fulfilment.

What Is Commercial Order Management?

Commercial Order Management (COM) is the entry point for all customer-facing order activity in a telco. It sits at the boundary between the customer experience world (CRM, CPQ, digital channels) and the technical fulfilment world (SOM, ROM). COM's job is to capture, validate, enrich, and manage the commercial lifecycle of a product order — ensuring that what the customer requested is feasible, properly priced, and ready for downstream fulfilment.

COM operates exclusively at the Product layer — it knows about Product Offerings, Product Specifications, and Product Instances, but it does not know about CFS, RFS, or network resources directly.

The BSS capability responsible for receiving product orders from sales channels, validating them against catalog and business rules, managing the commercial order lifecycle (including approvals, amendments, and cancellations), and initiating downstream fulfilment by decomposing product order items into service order items. COM is the system of record for the Product Order entity.

COM in the Architecture

COM order processing flow: from channel capture to SOM handoff

Sales Channels

Online Portal

CPQ

Retail POS

B2B API

Commercial Order Management (COM)

BSS — Product Layer

Order Capture

TMF622 POST

acknowledged

Decomposition

Product → CFS Mapping

reads

Product Catalog

TMF620

Submit to SOM

TMF641 POST

inProgress

Service Order Items

Service Order Management (SOM)

Receives decomposed service orders

SLM

TMF637 / TMF638

on completion

Service Order (TMF641)

COM decomposes the product order using the Product Catalog, then hands off CFS-level service order items to SOM via TMF641

Figure 3.2 — Commercial Order Management flow: from channel capture to SOM handoff

COM receives orders from multiple channels — online self-service portals, retail point-of-sale systems, call centre applications, partner portals, and B2B API integrations. Regardless of the channel, COM normalises these into a standard Product Order structure before processing.

COM Source-of-Record Responsibilities

Entity	System of Record	System of Engagement	System of Reference	Notes
Product Order	COM	CRM / Channel Portal / CPQ	Product Catalog (TMF620)	COM creates and owns the product order throughout its lifecycle
Product Order Item	COM	CPQ (initial configuration)	Product Offering / Specification	Each item references a catalog offering and captures selected options
Order Pricing	COM (confirmed)	CPQ (quoted)	Product Offering Price (TMF620)	CPQ quotes the price; COM confirms it at order time
Product Instance	SLM / Product Inventory (TMF637)	COM (triggers creation)	—	COM triggers product instance creation but SLM (Product Inventory) is the SoR

Order Capture from CPQ and Channels

The order capture process begins when a customer (or agent acting on behalf of a customer) completes the Configure-Price-Quote (CPQ) process and confirms their selection. CPQ hands off a fully configured, priced quote to COM, which converts it into a formal Product Order.

Order Capture Flow

Customer Selects Offering

Channel / Storefront

Customer browses the product catalog and selects a Product Offering (e.g., "SuperFibre 200 Home"). The channel application queries TMF620 to display eligible offerings.

CPQ Configures & Prices

CPQ

CPQ validates the selected configuration (mandatory options, incompatibilities, address eligibility), resolves pricing (base price, discounts, promotions, taxes), and presents a quote to the customer.

Customer Confirms Order

Channel / CPQ

Customer accepts the quote, agrees to terms and conditions, and authorises payment. CPQ submits the confirmed quote to COM as a Product Order creation request via TMF622.

COM Creates Product Order

COM

COM receives the TMF622 POST /productOrder request, assigns an order ID, sets initial state to "acknowledged", and begins validation. The Product Order now exists as a formal entity in the COM system.

COM Validates & Enriches

COM

COM performs business rule validation (credit check, fraud screening, duplicate order detection, address qualification), enriches the order with internal references, and confirms commercial feasibility.

COM Initiates Fulfilment

COM → SOM

Once validated, COM decomposes Product Order Items into Service Order Items using catalog mappings, and submits them to SOM via TMF641. COM state transitions to "inProgress".

Channel-Agnostic Order Model

A well-designed COM system uses the same Product Order data model regardless of the originating channel. Whether the order comes from a mobile app, retail POS, or B2B API, the internal representation is identical. This is sometimes called the "canonical order model" and is a key principle of channel-agnostic architecture.

Order Types in Detail

COM must handle several distinct order types, each with different processing rules, validation requirements, and downstream decomposition patterns. The order type is typically determined by the combination of order item actions within the product order.

A new provide order creates product instances that did not previously exist for this customer. All order items have action = add.

Customer has no existing product of this type (or is adding a second instance)
Requires full address qualification and serviceability check
May require credit check if the customer is new
Full decomposition into service and resource layers
Highest complexity — most order fallout occurs on new provide orders

New Provide Example

Customer signs up for "SuperFibre 200 Home" at a new address. Product Order contains: 1x Broadband Access (add), 1x Router Rental (add), 1x WiFi App (add). All items are new — full provisioning of all CFS and RFS layers required.

Commercial Order Lifecycle States

TMF622 defines a standard set of order states. The order-level state is derived from the aggregate state of its items — e.g., if all items complete the order completes; if some succeed and others fail the order is "partial". Order items have their own independent lifecycle states.

TMF622 Product Order States

State	Terminal?	Meaning
Acknowledged	No	Order received, ID assigned, initial schema validation passed
In Progress	No	Validation passed, service orders submitted to SOM — typically the longest state
Held	No	Paused — manual approval, customer contact, or jeopardy condition
Pending	No	Awaiting future event (scheduled date, appointment, third-party action)
Assessing Cancellation	No	Cancellation requested — evaluating which fulfilled items need reversal
Completed	Yes	All items fulfilled, inventory updated, billing activated
Partial	Yes	Some items completed, others failed — requires operational decision
Failed	Yes	Order could not be completed, compensation/rollback executed
Cancelled	Yes	Cancelled by customer or business rule before completion
Rejected	Yes	Failed validation — never entered fulfilment

COM and Subscription Lifecycle Management

COM has a critical relationship with Subscription Lifecycle Management (SLM) — the capability that maintains the runtime truth of what each customer currently has. Technically underpinned by Product Inventory (TMF637), SLM is the system of record for active product instances and their configuration. COM interacts with SLM in two directions:

Read (for modify/cease orders): When processing a modify or cease order, COM reads the current product instance from SLM to understand the existing state. This is necessary to calculate the delta between current state and desired state.
Write (upon completion): When a product order completes, COM triggers the creation or update of the corresponding product instance in SLM. For a new provide, a new instance is created. For a modify, the existing instance is updated. For a cease, the instance is terminated.

Current vs Desired State

A powerful pattern in order management is the "current state vs desired state" model. For modify orders, COM retrieves the current product instance (current state), compares it with the ordered configuration (desired state), and generates a delta — only the differences need to flow to SOM/ROM. This delta-based approach significantly reduces fulfilment complexity for change orders.

TMF622 Product Ordering API

TMF622 — Product Ordering Management

TMF622 provides a standardized REST API for creating, updating, querying, and cancelling product orders. Key resources: POST /productOrder (create), GET /productOrder/{id} (retrieve), PATCH /productOrder/{id} (update), DELETE /productOrder/{id} (request cancellation). The API supports filtering, pagination, and field selection for efficient querying.

TMF622 is the API that external channels (web portals, mobile apps, partner systems) call to submit product orders. It defines a standard JSON payload for the Product Order and Product Order Item, including all the attributes needed to describe what the customer wants.

POST /productOrder — Create a new product order
GET /productOrder/{id} — Retrieve order status and details
GET /productOrder — List/search orders with filters
PATCH /productOrder/{id} — Update an order (e.g., request cancellation)

TMF622 Product Order Payload

Field	Type	Description
id	string	Unique order identifier (assigned by COM)
externalId	string	ID from the originating system (channel/CPQ)
state	string	Current order state (acknowledged, inProgress, completed, etc.)
orderDate	dateTime	When the order was placed
requestedStartDate	dateTime	When the customer wants the service to start
requestedCompletionDate	dateTime	When the customer expects completion
channel	object	The sales channel that originated the order
relatedParty	array	Customer, account, agent associated with the order
productOrderItem	array	The line items in the order (see below)
note	array	Order notes from agents, systems, or customers

TMF622 Product Order Item Fields

Field	Type	Description
id	string	Unique item identifier within the order
action	string	add \| modify \| delete \| noChange
state	string	Item-level state (independent of order state)
quantity	integer	Number of instances to provision
productOffering	ref	Reference to the Product Offering from catalog (TMF620)
product	object	The product instance being ordered or modified
product.productCharacteristic	array	Selected characteristic values (speed, quota, etc.)
product.productRelationship	array	Relationships to other product instances
itemPrice	array	Confirmed pricing for this item
orderItemRelationship	array	Dependencies on other items in this order
appointment	ref	Installation/delivery appointment if required

The product Field in Order Items

The product field inside an order item is crucial. For add actions, it describes the desired product instance to be created (with selected characteristics). For modify actions, it contains the existing product instance ID plus the desired changes. For delete actions, it references the existing product instance to be ceased. This field is the bridge between the order world and the inventory world.

Decomposing Product Orders into Service Orders

Once COM has validated and approved a product order, it must decompose the product order items into service order items for SOM. This decomposition is catalog-driven — COM reads the Product Specification to determine which CFS types are required and creates corresponding service order items.

Decomposition Example

Product Order Item: "SuperFibre 200 Home" (add). COM reads the Product Specification "Residential Broadband Access" and finds it requires 3 CFS: CFS:Internet-Access (mandatory), CFS:WiFi-Management (optional — included in this offering), CFS:CPE-Management (mandatory). COM creates a Service Order with 3 Service Order Items and submits it to SOM via TMF641.

Product-to-Service Decomposition Mapping

Product Order Item	Action	Service Order Item(s) Generated	CFS Type
Broadband Access (add)	add	SOI-1: Internet Access	CFS:Internet-Access
Broadband Access (add)	add	SOI-2: WiFi Management	CFS:WiFi-Management
Broadband Access (add)	add	SOI-3: CPE Management	CFS:CPE-Management
Speed upgrade (modify)	modify	SOI-1: Internet Access (modify speed)	CFS:Internet-Access
Add Static IP (add)	add	SOI-4: Static IP	CFS:Static-IP
Cancel broadband (delete)	delete	SOI-1,2,3: All services (delete)	All CFS types

Decomposition Is Not Trivial

Catalog-driven decomposition sounds simple, but edge cases abound. Modify orders require "delta detection" — comparing current state to desired state. Bundles with shared components require deduplication. Technology-dependent decomposition (e.g., GPON vs HFC) may require address-specific logic. Some implementations perform decomposition in COM itself; others delegate it to a separate "order decomposition engine" that sits between COM and SOM.

Common COM Challenges

Order amendment: Customer wants to change an in-progress order. COM must determine which downstream work can be modified vs what must be cancelled and re-submitted.
Order priority management: VIP customers, enterprise SLAs, and regulatory orders may require priority processing. COM must implement priority queuing without starving standard orders.
Multi-product orders: A single product order may contain multiple products (broadband + TV + voice). Each product decomposes independently but may share common services or have inter-product dependencies.
Scheduled orders: Orders with a future requested start date must be held until the appropriate time, then released for fulfilment with enough lead time for provisioning.
Order versioning: As an order progresses and is amended, COM must maintain a history of order versions for audit and dispute resolution.
Partial fulfilment decisions: When some items in a multi-item order fail, COM must decide: wait for resolution, complete available items, or fail the entire order.

Section 3.2 Key Takeaways

COM is the entry point for all customer orders and operates at the Product layer
COM receives orders from multiple channels via TMF622 and normalises them into a standard Product Order model
Order types include new/provide, modify, cease, and migrate — each with different processing rules
COM performs validation (catalog rules, credit, fraud, address) before initiating fulfilment
Product Order lifecycle states: acknowledged → inProgress → completed/failed/cancelled
COM decomposes Product Order Items into Service Order Items using catalog-driven mappings
COM is the system of record for Product Orders; SLM (Product Inventory / TMF637) is the SoR for product instances
The BFF pattern enables channel-optimised APIs while maintaining a standard internal COM interface
Bypassing COM (using CRM or billing as order manager) causes validation gaps, broken lifecycle tracking, and billing disconnects