3.215 min read

Commercial Order Management (COM)

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 fulfillment 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 fulfillment.

In TM Forum's ODA (Open Digital Architecture), COM maps to the Product Order Management functional block. It 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 fulfillment 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

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	Product Inventory (TMF637)	COM (triggers creation)	—	COM triggers product instance creation but 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 Fulfillment

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.

Order Validation and Feasibility

Before COM sends an order downstream for fulfillment, it performs multiple validation checks. These checks prevent orders from entering the fulfillment pipeline that will inevitably fail or require manual correction.

COM Validation Checks

Check	Description	Failure Action
Catalog Validation	Verify all referenced offerings exist, are active, and configuration is valid (mandatory options selected, no incompatibilities)	Reject order with specific validation error
Address Qualification	Verify the service address exists, is serviceable, and the requested product is available at that address	Reject or flag for manual review
Credit Check	Verify customer creditworthiness for the requested products (especially for postpaid/contract products)	Reject, request deposit, or route to manual approval
Fraud Screening	Check for indicators of fraudulent activity (velocity checks, identity verification)	Hold for investigation or reject
Duplicate Detection	Check if an identical or conflicting order already exists for this customer/address	Alert agent or reject duplicate
Inventory Pre-check	Verify key resources are likely available (e.g., ports in the exchange) — optional at COM level	Flag potential feasibility issue
Business Rule Validation	Apply business-specific rules (maximum products per account, contract compatibility, regulatory checks)	Reject with business rule violation

Feasibility vs Validation

There is an important distinction between validation (can this order be processed?) and feasibility (can this order be fulfilled?). Validation is a COM concern — checking data completeness and business rules. Feasibility is partly a COM concern (address qualification, credit) and partly a SOM/ROM concern (resource availability, network capacity). Some architectures perform a "technical feasibility" check before order submission by querying SOM/ROM via TMF API, while others only discover feasibility issues during actual fulfillment.

Commercial Order Lifecycle States

TMF622 defines a standard set of order states that every Product Order transitions through. These states are critical for order tracking, reporting, and integration with downstream systems.

TMF622 Product Order state machine: order lifecycle transitions

Figure 3.2b — TMF622 Product Order state machine showing all lifecycle transitions

Product Order State Machine

Acknowledged

COM

Order has been received and assigned an ID. Initial validations (schema, required fields) have passed. This is the starting state for all orders.

In Progress

COM + SOM + ROM

Order has passed all validation checks and fulfillment has been initiated. Service orders have been submitted to SOM. This is typically the longest-duration state.

Held

COM (manual queue)

Order processing has been paused due to an issue requiring resolution: manual approval needed, customer contact required, external dependency pending, or jeopardy condition detected.

Pending

COM

Order is awaiting a specific future event: scheduled installation date, customer appointment confirmation, or third-party action. Processing will resume when the condition is met.

Completed

COM

All order items have been successfully fulfilled. Product Inventory has been updated. Billing has been activated. Customer notification sent. This is a terminal state.

Failed

COM

Order could not be completed and all compensation/rollback actions have been executed. Customer and internal stakeholders have been notified. This is a terminal state.

Cancelled

COM

Order was cancelled before completion — either by the customer or by a business rule. Any in-progress fulfillment must be reversed. This is a terminal state.

TMF622 State Model

TMF622 defines the state values as: acknowledged, rejected, pending, held, inProgress, cancelled, completed, failed, partial, and assessingCancellation. The "partial" state covers scenarios where some order items completed but others failed. The "assessingCancellation" state handles the period where a cancellation request is being evaluated (some items may already be fulfilled and need reversal).

Note that order items have their own independent lifecycle states, separate from the overall order state. The order state is typically derived from the aggregate state of its items: if all items are completed, the order is completed; if any item is held, the order may transition to held; if some items completed but others failed, the order state is "partial".

COM and Product Inventory

COM has a critical relationship with Product Inventory (TMF637). Product Inventory is the system of record for what the customer currently has — their active product instances and their configuration. COM interacts with Product Inventory in two directions:

Read (for modify/cease orders): When processing a modify or cease order, COM reads the current product instance from Product Inventory 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 Product Inventory. 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 fulfillment 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.

COM Integration Patterns

COM Integration Points

System	Direction	API / Pattern	Purpose
CPQ / Channel	Inbound	TMF622 POST	Receive new product orders
CRM	Bidirectional	TMF629 / Custom	Customer and account data, order status updates
Product Catalog	Outbound query	TMF620 GET	Retrieve offerings, specifications, and decomposition rules
Product Inventory	Outbound query + update	TMF637	Read current state (modify orders); update on completion
SOM	Outbound	TMF641 POST	Submit service orders for fulfillment
SOM	Inbound events	TMF641 Events	Receive service order completion/failure notifications
Billing	Outbound	TMF678 / Custom	Activate billing for completed orders
Notification	Outbound	TMF681 / Custom	Send customer notifications (confirmation, updates, completion)

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 fulfillment 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 fulfillment decisions: When some items in a multi-item order fail, COM must decide: wait for resolution, complete available items, or fail the entire order.

Implementation Considerations

In most telco architectures, COM is implemented as part of the BSS stack. It may be a standalone Order Management System (OMS) or a module within a broader BSS suite that includes CRM and billing. The key point is that COM is a BSS capability, not an OSS capability.

Modern architectures increasingly implement COM as a set of microservices aligned to TM Forum ODA component specifications. This enables independent scaling (order capture may spike during promotions while fulfillment processing remains steady), technology flexibility, and alignment with cloud-native deployment patterns.

Rather than exposing the raw TMF622 API directly to all channels, many implementations use a Backend-for-Frontend (BFF) pattern. Each channel (web, mobile, retail, B2B) has its own BFF that provides a channel-optimized API. The BFF translates channel-specific requests into standard TMF622 calls to COM. This keeps COM clean while allowing channels to evolve independently.

Why BFF Matters

A mobile app needs a very different API shape than a B2B system integration. The mobile app might need a simplified "order broadband" endpoint, while the B2B API might need full TMF622 compliance. The BFF pattern lets COM maintain a single, standard internal API while offering tailored external APIs per channel.

What Breaks When COM Is Missing or Bypassed

Some organisations attempt to skip COM entirely — routing orders directly from CRM or a channel application to SOM, or embedding order management logic inside the billing system. This is a common anti-pattern in legacy environments, and it creates severe operational and architectural problems.

Impact of Bypassing COM

Capability	With COM	Without COM (Bypassed)
Order lifecycle tracking	Full lifecycle state machine (acknowledged → inProgress → completed/failed) with audit trail	No standardised order lifecycle. Order state tracked ad-hoc in CRM notes or spreadsheets.
Channel normalisation	All channels submit orders via TMF622; COM normalises them into a consistent model	Each channel implements its own order format. SOM must handle multiple inbound formats.
Commercial validation	Credit checks, eligibility rules, catalog validation, fraud screening applied before fulfilment	Validation is scattered or skipped. Invalid orders reach SOM and fail during fulfilment, causing costly fallout.
Order decomposition	Product-to-CFS decomposition uses catalog rules to generate service orders	Decomposition logic leaks into SOM or channels. Changes to product structure require code changes in multiple systems.
Billing coordination	COM triggers billing activation on order completion with correct product and pricing context	Billing activation is manual or triggered inconsistently. Customers are charged before service is active, or not charged at all.
Order amendment	In-flight amendments managed through versioned order items with delta processing	Amendments require cancelling and re-submitting the entire order. No partial modification capability.
Product Inventory updates	COM updates Product Inventory on completion, maintaining the commercial record of what the customer has	Product Inventory may not be updated, or is updated by the wrong system. CRM and billing show conflicting subscription data.
Reporting & analytics	Standardised order metrics: cycle time, fallout rate, order-to-activation time	No consistent order reporting. Management has no visibility into order pipeline or fulfilment performance.

The "CRM-as-COM" Anti-Pattern

The most common bypass pattern is using CRM as the order management system. CRM platforms often include basic order capture, but they lack the fulfilment orchestration, decomposition logic, and lifecycle state management that a true COM provides. The result is that CRM becomes overloaded, order tracking is poor, and the boundary between customer management and order management is blurred — making it impossible to replace either system independently.

The "Billing-as-COM" Anti-Pattern

In some legacy environments, the billing system captures orders because a dedicated COM does not exist. This creates circular dependencies: billing must be configured before the order is complete, but the order determines what billing configuration is needed. It also means that the billing system becomes the de facto Product Inventory, which violates source-of-record principles and makes billing replacement extremely risky.

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 fulfillment
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; Product Inventory 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