6.412 min read

Request-to-Change Flow

What Is Request-to-Change?

The Request-to-Change (R2C) process handles modifications to existing services — upgrades, downgrades, add-ons, relocations, and cancellations. While Lead-to-Cash focuses on new service delivery and Trouble-to-Resolve focuses on fault resolution, R2C addresses the ongoing lifecycle management of a customer's portfolio.

R2C is often underestimated in complexity. Modifying an existing service is frequently harder than provisioning a new one, because the system must understand the current state, calculate the delta, manage in-flight dependencies, and ensure billing accuracy across the transition.

Request-to-Change (R2C)

The end-to-end business process for modifying an existing customer service. R2C encompasses change request capture, impact analysis, delta calculation, partial fulfilment, and billing adjustment. It covers upgrades, downgrades, add-ons, removals, relocations, and full cancellations.

eTOM Alignment

R2C reuses many of the same eTOM processes as L2C (Fulfilment vertical) but introduces additional complexity around change impact analysis and delta ordering. Key eTOM processes include: Order Handling (1.1.1.6), Service Configuration & Activation (1.1.2.1), and Resource Provisioning (1.1.3.1) — all executed with "modify" action types rather than "add."

How R2C Differs from New Orders (L2C)

At first glance, R2C might look like L2C with a different starting point. But the differences are fundamental. In L2C, you are building from a blank slate. In R2C, you are modifying a live, running service — which means you must understand the current state, avoid disrupting what is already working, and handle the transition gracefully.

New Order (L2C) vs Change Order (R2C)

Aspect	New Order (L2C)	Change Order (R2C)
Starting State	No existing service	Existing service with active CFS/RFS instances
Catalog Lookup	Look up what to create	Compare current state to desired state
Order Type	Add order items only	Mix of Add, Modify, Delete order items
Decomposition	Full decomposition from product to resource	Delta decomposition — only changed elements
Risk	Failure means no service (annoying)	Failure may disrupt existing service (critical)
Billing	Activate new billing record	Modify existing billing record (proration)
Rollback	Cancel the order	Rollback to previous working state
Inventory Impact	Create new instances	Update existing instances, create/delete as needed

The Delta Problem

The biggest challenge in R2C is delta calculation: determining exactly what has changed between the current state and the desired state. If the customer upgrades from 100Mbps to 1Gbps broadband, the system must determine that only the speed characteristic needs to change — not the entire CFS/RFS structure. Getting this wrong leads to unnecessary reprovisioning, service disruption, and billing errors.

The Complete R2C Flow

Request-to-Change: End-to-End Flow

Change Request Capture

CRM / Self-Service

Customer requests a modification via any channel (call, portal, retail). The agent identifies the customer and their current product portfolio.

Current State Retrieval

Product Inventory / Service Inventory

The system retrieves the current product instance from Product Inventory, including all active CFS and RFS instances from Service and Resource Inventory.

Desired State Configuration

CPQ / Product Catalog

The customer configures the desired changes via CPQ. The system validates the new configuration against catalog rules, eligibility, and feasibility.

Delta Calculation

COM / Order Engine

The system compares current state to desired state and calculates the exact delta: which components are being added, modified, or removed.

Impact Analysis

SOM / Service Inventory

Assess the impact of the change on active services. Determine whether the change can be made non-disruptively or requires a maintenance window.

Delta Order Creation

COM

Create a change order containing only the delta order items (add/modify/delete actions). Submit for fulfilment.

Partial Fulfilment

SOM / ROM

Execute only the changed elements. Modify existing CFS/RFS instances, add new ones, or remove obsolete ones. Preserve unchanged elements.

Billing Adjustment

Billing

Adjust billing records: apply proration for mid-cycle changes, update recurring charges, and handle one-time change fees.

Types of Service Changes

Not all changes are created equal. The complexity and risk of an R2C flow depends significantly on the type of change being made. The following taxonomy covers the most common change types in telco BSS/OSS:

Changing a characteristic of an existing service component. Examples: increasing broadband speed from 100Mbps to 1Gbps, upgrading a mobile plan from 10GB to unlimited data. The product structure remains the same; only characteristics change.

Product structure unchanged — same CFS/RFS hierarchy
Characteristic values updated (speed, capacity, tier)
May require resource reconfiguration (e.g., QoS policy change)
Billing: update recurring charge, apply proration
Usually non-disruptive (hitless change)

Example: Broadband Speed Upgrade

Customer upgrades from 100Mbps to 500Mbps. Delta: modify speed characteristic on CFS "Internet Access" from 100 to 500. RFS "Broadband Line" speed profile updated. Resource-level: QoS policy on BRAS/BNG reconfigured. No structural change to the service hierarchy.

Delta Ordering and Partial Fulfilment

The concept of delta ordering is central to R2C. Rather than resubmitting the entire product configuration, the system calculates what has changed and creates an order containing only the differences. This is more efficient, less risky, and easier to roll back.

Imagine you ordered a pizza with pepperoni and mushrooms. Now you want to add olives and remove mushrooms. You would not re-order the entire pizza — you would just say "add olives, remove mushrooms." That is delta ordering: only specifying what changed.

The delta is calculated by comparing the current product instance (from Product Inventory) with the desired configuration (from CPQ). Each order item in the resulting change order carries an action type:

Add — a new component that does not exist in current state
Modify — an existing component with changed characteristics
Delete — an existing component to be removed
No Change — an existing component that stays as-is (not included in the order)

The same delta logic cascades through decomposition: product-level deltas become CFS-level deltas, which become RFS-level deltas, which become resource-level deltas. Each level only processes its relevant changes.

Two common implementation patterns exist for delta calculation: snapshot comparison and event-driven delta. In snapshot comparison, the system takes a snapshot of the current state, compares it with the desired state, and generates the delta. In event-driven delta, each change event (add characteristic, remove component) is captured individually and compiled into a delta order.

TMF622 (Product Ordering) supports delta ordering natively through the action field on order items: add, modify, delete, and noChange. The order payload includes both the current and target values for modified characteristics, enabling downstream systems to apply the change precisely.

Change Impact Analysis

Before executing a change, the system must assess its impact on the running service. This is critical because some changes can be made seamlessly (hitless), while others require a brief service interruption or even a maintenance window.

Change Impact Categories

Category	Description	Example	Handling
Hitless	Change can be applied with zero service impact	Adding a static IP, changing a billing plan	Execute immediately
Brief Interruption	Change causes a momentary disruption (seconds)	Speed upgrade requiring port reconfiguration	Execute with customer notification
Maintenance Window	Change requires significant downtime	Technology migration (ADSL to fibre)	Schedule with customer, coordinate cutover
Service-Affecting	Change may impact other customers on shared resources	Core network reconfiguration	Requires change management approval

Impact analysis uses the service and resource topology from inventory. By tracing the CFS-to-RFS-to-Resource graph, the system can determine which resources will be affected and whether those resources are shared with other services or customers.

Service-Affecting Changes

Any change that touches shared infrastructure must go through formal change management. This includes changes to aggregation equipment, core routers, or shared platforms. The change management process assesses risk, schedules the change window, and ensures rollback procedures are in place.

In-Flight Order Modification

One of the most challenging scenarios in R2C is modifying an order that is already in progress. This happens when a customer changes their mind after placing an order but before fulfilment is complete — or when a feasibility issue requires order amendment.

In-flight modification requires the orchestration engine (SOM/ROM) to:

Determine the current execution state of the in-flight order
Identify which order items have been completed, are in progress, or are pending
Calculate the delta between the original order and the modified request
Compensate for already-completed items that need to be undone (rollback)
Adjust pending items to reflect the new desired state
Resume execution with the modified order

Compensation Logic

In-flight modification often requires compensation — undoing work that has already been completed. For example, if a broadband line has been provisioned at 100Mbps but the customer now wants 500Mbps, the system must deprovision the 100Mbps configuration and provision 500Mbps. Not all systems support compensation natively; many require manual intervention.

Advanced

Saga Pattern for In-Flight Changes

In-flight order modification is a classic distributed saga problem. Each completed step in the fulfilment flow must have a defined compensation (undo) action.

The saga pattern defines that for every forward action (e.g., "provision broadband line at 100Mbps"), there is a compensating action ("deprovision broadband line"). When an in-flight modification occurs, the orchestrator executes compensating actions for completed steps that need to change, then replays the modified steps forward. This requires careful design of idempotent and compensatable actions at every level of the SOM/ROM orchestration.

Relationship to L2C and T2R

R2C does not exist in isolation. It shares infrastructure and processes with both L2C and T2R flows, and they frequently interact:

R2C Interactions with L2C and T2R

Scenario	Interaction	Example
R2C triggers L2C	A change requires provisioning a completely new service component	Adding TV service to existing broadband (new CFS)
T2R triggers R2C	Fault resolution requires a permanent service modification	Replacing a faulty CPE with a different model requires config change
L2C includes R2C	A new order for an existing customer modifies their existing portfolio	Upgrading broadband as part of a bundle sale
R2C triggers T2R	A change unintentionally degrades service quality	Speed change causes packet loss, triggering assurance flow

Architecturally, this means the order management system (COM/SOM/ROM) must support all three order action types (add, modify, delete) and be able to handle mixed orders that combine new provisioning with modifications to existing services.

Billing Implications of Changes

Every R2C action has billing implications. The billing system must handle the transition from old charges to new charges accurately. This is where proration — calculating partial charges for mid-cycle changes — becomes critical.

When a customer upgrades mid-billing cycle, they should be charged the old rate for the days before the change and the new rate for the days after. This is proration. For example, if a customer upgrades from a $50/month plan to a $100/month plan halfway through the month, they should be charged $25 (half month at old rate) + $50 (half month at new rate) = $75 for that billing period.

R2C Design Best Practices

Always retrieve current state from inventory — never rely on cached or order-time data for the current product/service/resource state
Calculate deltas at every decomposition level — product delta → CFS delta → RFS delta → resource delta
Design for rollback — every change action must have a defined compensation action in case of failure
Classify change impact — hitless vs disruptive, and handle each category differently
Support effective dating — not all changes should be immediate; allow future-dated changes
Handle contract implications in CPQ — do not let contract-affecting changes reach fulfilment without customer acknowledgement
Test mixed orders — orders combining add, modify, and delete actions are common in practice and must work correctly
Implement idempotent operations — if a change order is retried (after partial failure), it should not duplicate work

Common R2C Pitfalls

Pitfall: Full Reprovisioning for Simple Changes

Some legacy systems handle changes by tearing down the entire service and reprovisioning from scratch. This is a "sledgehammer" approach that causes unnecessary service disruption, wastes network resources, and creates billing gaps. Always implement true delta ordering.

Pitfall: Inventory Drift

If the R2C process does not properly update inventory after a change, a gap opens between what inventory says and what is actually provisioned. Over time, this "inventory drift" makes future changes and assurance unreliable. Every R2C action must update Product, Service, and Resource Inventory atomically.

Pitfall: Ignoring In-Flight Conflicts

If a customer has a pending order in progress and submits a new change request, the system must detect the conflict. Processing both orders independently can lead to race conditions and inconsistent state. Implement order conflict detection and queuing.

Request-to-Change — Key Points

R2C handles modifications to existing services: upgrades, downgrades, add-ons, relocations, cancellations
Modifying existing services is often harder than new provisioning due to delta calculation and impact analysis
Delta ordering creates change orders containing only what has changed — not the full product
Impact analysis determines whether a change is hitless, briefly disruptive, or requires a maintenance window
In-flight order modification requires compensation logic (saga pattern) for already-completed steps
R2C interacts with L2C (new components) and T2R (fault-driven changes) — they are not isolated flows
Billing must handle proration, effective dating, and contract impact for every change
Accurate, up-to-date inventory is the foundation for reliable R2C processing