🔄

Section 3.1

Order Management Overview

What order management means in telco and why the three-layer model (COM/SOM/ROM) exists.

What Is Order Management in Telco?

Order management in telecommunications is the discipline of capturing, validating, decomposing, orchestrating, and fulfilling customer requests across business and network systems. Unlike retail e-commerce — where an order is essentially a payment instruction followed by shipment — telco orders trigger a cascade of technical provisioning across dozens of systems, network elements, and inventory databases.

When a customer orders "SuperFibre 200 Home", the order management stack must translate that simple commercial request into OLT port configuration, VLAN assignments, IP address allocation, QoS policy application, CPE provisioning, billing account setup, and inventory updates — all orchestrated in the correct sequence with proper dependency management and rollback capabilities.

Order Management (Telco)

The end-to-end capability of receiving a customer request (new, modify, cease), decomposing it through catalog-driven rules into actionable work items across commercial, service, and resource layers, orchestrating their execution in the correct dependency order, and tracking the order through to completion or rollback. Governed by TM Forum eTOM process area 1.1.1 (Order Handling).

The complexity stems from a fundamental truth: what the customer buys is not what the network delivers. A product is a commercial abstraction. Beneath it lie services and resources that must be individually provisioned, tracked, and managed. Order management is the bridge between these worlds.

Why Telcos Need Layered Order Management

Many industries manage orders with a single order entity. Telcos cannot, because the concerns at the commercial layer, service layer, and resource layer are fundamentally different in ownership, lifecycle, granularity, and timing.

Commercial layer: Deals with products, prices, contracts, customer commitments, and SLAs. Owned by BSS/CRM teams.
Service layer: Deals with customer-facing services (CFS) and their orchestration. Owned by service management / OSS teams.
Resource layer: Deals with physical/logical network resources, device configuration, and activation. Owned by network engineering / OSS teams.

The Three-Layer Order Model: COM / SOM / ROM

TM Forum's architecture defines three distinct order management domains, each with its own scope, data model, API, and orchestration engine. Together, they form a decomposition chain from commercial intent to network reality.

Orders flow downCompletion flows up

BSS Front-Office (CRM / CPQ / Billing)

BSS

CRM

CPQ

Billing

TMF622 POST

decomposes

Commercial Order Management (COM)

BSS

Product Order

TMF622

Product Catalog

TMF620

SLM

TMF637 / TMF638

TMF641 POST

decomposes

events

Service Order Management (SOM)

OSS

Service Order

TMF641

Service Catalog

TMF633

SLM

TMF638

REST API

decomposes

events

Resource Order Management (ROM)

OSS

Resource Order

TMF652

Resource Catalog

TMF634

Resource Inventory

TMF639

NETCONF / CLI

Network Infrastructure

INFRA

OLT / Switch

BNG / Router

DHCP / IPAM

Orders

Catalogs

Inventory / SLM

Figure 3.1 — The three-layer order model: Commercial (COM), Service (SOM), and Resource (ROM) order management

Beginner

Commercial Order Management (COM)

COM is the entry point for all customer orders. It captures what the customer wants to buy — products, bundles, options, and pricing — and manages the commercial lifecycle of the order including validation, feasibility, pricing confirmation, and customer commitment.

COM operates at the Product layer. Its primary entities are Product Orders containing Product Order Items, each referencing a Product Offering from the catalog. COM is the system of record for the commercial order and owns the relationship with CRM/CPQ. It uses TMF622 Product Ordering API.

Beginner

Service Order Management (SOM)

SOM receives decomposed orders from COM and manages service-level fulfilment. It works at the CFS (Customer-Facing Service) layer, orchestrating the creation, modification, or cessation of services that underpin the ordered products.

SOM receives service orders via TMF641 Service Ordering API. Each service order item maps to a CFS specification from the service catalog. SOM orchestrates dependencies between service order items (e.g., Internet Access must be provisioned before WiFi Management), manages the service lifecycle, and delegates resource-level work to ROM.

Beginner

Resource Order Management (ROM)

ROM handles the physical and logical resource allocation, configuration, and activation required to deliver services. It works at the RFS (Resource-Facing Service) and Resource level, interfacing directly with network elements and inventory systems.

ROM receives resource orders via TMF652 Resource Ordering API. Each resource order item maps to an RFS or Resource specification. ROM allocates resources from inventory (ports, VLANs, IPs), drives configuration to network elements via activation adapters (NETCONF, CLI, API), and reports completion back to SOM.

How the Layers Interact

Order Flow Through the Three Layers

Customer Places Order

Channel / CPQ

The customer selects a Product Offering (e.g., "SuperFibre 200 Home") through a channel (online portal, retail store, call centre). CPQ validates the configuration and hands it to COM.

COM Captures & Validates

COM (BSS)

COM creates a Product Order, validates against catalog rules, confirms pricing, checks credit, and manages any manual approval steps. Once approved, COM decomposes the product order into service order items using the Product-to-CFS mapping from the catalog.

SOM Orchestrates Services

SOM (OSS)

SOM receives service order items for each CFS required (e.g., Internet Access, WiFi Management, CPE Management). It determines the execution plan: which items can run in parallel, which have dependencies, and what the correct sequence is. SOM further decomposes CFS items into RFS items using the service catalog.

ROM Allocates & Activates

ROM (OSS)

ROM receives resource order items for each RFS. It allocates resources from inventory (free OLT ports, VLAN IDs, IP addresses), drives configuration to network elements, and confirms activation. Completion status flows back up to SOM.

Completion Cascade

ROM → SOM → COM

As ROM completes resource orders, SOM marks service orders complete. As SOM completes service orders, COM marks the product order complete. Inventories are updated at each layer. The customer receives confirmation.

Source-of-Record Ownership

Order Management Source-of-Record Map

Entity	System of Record	System of Engagement	System of Reference	Notes
Product Order	COM	CRM / Channel Portal	Product Catalog	COM is the single source of truth for all commercial order state
Service Order	SOM	COM (submitter)	Service Catalog	SOM owns service order lifecycle; COM submits but does not own
Resource Order	ROM	SOM (submitter)	Resource Catalog	ROM owns resource order lifecycle; SOM submits but does not own
Product Instance	Product Inventory	CRM / Self-Service	Product Catalog	Created/updated as a side-effect of order completion
Service Instance	SLM	SOM	Service Catalog	Created/updated when SOM completes service order items
Resource Instance	Resource Inventory	ROM	Resource Catalog	Created/updated when ROM allocates and activates resources

TM Forum APIs for Order Management

Core Order Management APIs

API	Name	Layer	Purpose
TMF622	Product Ordering	COM	Create, query, and manage product orders
TMF641	Service Ordering	SOM	Create, query, and manage service orders
TMF652	Resource Ordering	ROM	Create, query, and manage resource orders
TMF620	Product Catalog	COM reference	Look up product offerings and decomposition rules
TMF633	Service Catalog	SOM reference	Look up CFS/RFS specifications and decomposition rules
TMF634	Resource Catalog	ROM reference	Look up resource specifications
TMF637	Product Inventory	COM output	Record product instances after fulfilment
TMF638	SLM	SOM output	Record service instances after provisioning
TMF639	Resource Inventory	ROM output	Record resource instances after allocation

Event-Driven Order Updates

TM Forum APIs support both synchronous REST operations (POST to create, GET to query, PATCH to update) and asynchronous event notifications via TMF Event Management. Order state changes (e.g., order item completed, order failed) are typically communicated via events using a publish/subscribe pattern, allowing upstream systems to react without polling.

Common Order Types

While the three-layer model supports any type of change, telcos typically classify orders into standard categories that drive different processing paths:

Order Type Classification

Order Type	Description	COM Action	SOM/ROM Impact
New / Provide	Customer orders a new product for the first time	All items action = add	Full decomposition and provisioning of all layers
Modify / Change	Customer changes an existing product (upgrade, downgrade, add feature)	Mix of add, modify, noChange items	Delta decomposition — only changed items flow to SOM/ROM
Cease / Disconnect	Customer cancels a product entirely	All items action = delete	Full decommissioning in reverse order (ROM first, then SOM)
Migrate / Move	Customer moves to a new address or technology platform	Cease old + Provide new (or complex modify)	Decommission old resources, provision new resources at new location
Suspend / Resume	Temporary service suspension (e.g., non-payment)	Status change, no structural change	Service-level state change; resources may remain allocated

Real-World Order Management Challenges

Order Fallout

In real telco environments, a significant percentage of orders (sometimes 10-30%) encounter issues that prevent automatic completion. These "fallout" orders require manual intervention by operations teams. Common causes include: resource exhaustion (no free ports), data quality issues (address not found), system timeouts, and network element errors. Effective order management includes robust fallout handling, work queue management, and jeopardy monitoring.

Order amendment: Customer changes their mind after order submission — the system must handle in-flight modifications
Partial completion: Some order items succeed while others fail — requires compensation logic
Cross-system consistency: Product, service, and resource inventories must remain synchronized
SLA management: Orders have promised delivery dates that must be monitored and escalated
Bulk orders: Enterprise customers may order hundreds of lines simultaneously
Dependency on external parties: Field technicians, third-party suppliers, port migrations

What This Module Covers

This module takes you through each layer in depth:

Module 3 Learning Path

Section 3.1 — Overview (You Are Here)

The three-layer model, why it exists, and how layers connect.

Section 3.2 — Commercial Order Management

COM

Deep dive into COM: order capture, validation, commercial lifecycle, TMF622.

Section 3.3 — Service Order Management

SOM

Deep dive into SOM: CFS decomposition, service orchestration, TMF641.

Section 3.4 — Resource Order Management

ROM

Deep dive into ROM: resource allocation, activation, TMF652.

Section 3.5 — Order Orchestration & Decomposition

End-to-end orchestration, dependency patterns, rollback, jeopardy management.

Sections 3.6–3.10 — Five Domain Examples

Technology-specific order lifecycles: Broadband B2C, Fixed B2B, Mobile 4G B2C, SD-WAN B2B, Mobile 5G B2B.

Section 3.1 Key Takeaways

Telco order management uses a three-layer model: COM (commercial), SOM (service), ROM (resource)
Each layer has different concerns, owners, lifecycles, and granularity
Orders decompose top-down: Product → Service → Resource, driven by catalog rules
Completion cascades bottom-up: Resource → Service → Product
The catalog defines decomposition rules; orders execute them; inventories record the results
Each layer has its own TM Forum API: TMF622 (COM), TMF641 (SOM), TMF652 (ROM)
Source-of-record ownership is critical: each layer owns its own order and inventory data
Real-world challenges include order fallout, amendments, partial completion, and jeopardy management