Multi-Site & Bulk Ordering

Multi-Site & Bulk Ordering

One of the most challenging aspects of B2B BSS is multi-site ordering — the ability to take a single commercial request (e.g. "deploy SD-WAN to our 50 offices") and decompose it into site-level orders that are individually feasible, independently trackable, and collectively managed as a single engagement.

In B2C, an order is a simple, atomic unit: one customer, one product, one address. In B2B, a single commercial order may represent dozens or hundreds of site-level deliveries, each with its own feasibility status, provisioning timeline, and technical configuration. The BSS/OSS stack must orchestrate this complexity while presenting a coherent view to both the CSP's operations team and the enterprise customer.

This section covers the architecture of multi-site ordering: how commercial orders decompose to sites, how phased rollouts work, how per-site orchestration flows through COM → SOM → ROM, and how to handle the inevitable partial failures.

Site-Level Decomposition

The fundamental pattern in multi-site ordering is decomposition: a single commercial order is broken down into per-site order items, each of which flows through the fulfilment stack independently. The commercial order provides the "umbrella" — tracking overall progress, contract compliance, and billing — while each site-level item has its own lifecycle.

• Parent Order — The commercial order representing the entire multi-site engagement; linked to the contract and billing
• Site Order Item — A child of the parent order, scoped to a single site; contains site-specific product configuration and address
• Site Reference — Each site order item links to a geographic site entity (TMF674) with validated address, coordinates, and site metadata
• Per-Site CFS/RFS — Each site generates its own Customer-Facing Service and Resource-Facing Service instances during fulfilment
• Rollout Phase — Sites may be grouped into delivery waves; each wave has a target completion date

Phased Rollout Patterns

Delivering 50 sites simultaneously is rarely practical — or desirable. Enterprise deployments almost always follow a phased rollout pattern, where sites are grouped into waves and delivered sequentially. The two primary patterns are site-by-site (sequential) and wave-based (parallel groups).

Per-Site COM → SOM → ROM Orchestration

Each site-level order item flows through the standard COM → SOM → ROM orchestration stack, but with site-specific context. The commercial order captures what the customer wants at each site; the service order translates it into how it is delivered; the resource order provisions the actual network elements.

TM Forum Standards for Multi-Site Ordering

Failure Handling: Partial Activation and Rollback

In multi-site ordering, failure is not a question of "if" but "when." Some sites will fail feasibility. Some will have provisioning errors. Some will be delayed by external dependencies (building access, permits, third-party circuits). The BSS/OSS stack must handle partial success gracefully — a concept that barely exists in B2C.

• Independent site lifecycle — Each site order item has its own state machine; a failure at one site does not block others
• Partial billing — Billing starts per site as each site goes active; the customer is not charged for sites still in progress or failed
• Retry and remediation — Failed sites enter a remediation queue; they can be retried, redesigned, or escalated without affecting active sites
• Rollback per site — If a site activation fails after partial provisioning, the rollback is scoped to that site only (deactivate circuit, reclaim IP addresses, cancel CPE shipment)
• Substitution — If a site cannot be served (e.g. no coverage), the customer may substitute a different address; the site order item is updated, not the parent order
• Wave gating — A wave is considered complete when X% of sites are active (e.g. 80%); remaining sites carry over to the next wave or enter a remediation track
• Customer visibility — The enterprise portal shows per-site status with clear indicators: active, in progress, delayed, failed, pending customer action
• SLA impact assessment — If site failures delay the overall rollout beyond the contracted completion date, the system must flag this for proactive customer communication and potential SLA remediation

Rollback Strategies

Rollback in a multi-site context is more nuanced than simply "undo everything." The strategy depends on where in the fulfilment process the failure occurred and whether the failure is at a single site or across a wave.

Source-of-Record for Multi-Site Entities

Multi-site ordering introduces additional entities that must have clear source-of-record ownership. Ambiguity in ownership leads to data inconsistency — particularly when a site order item is modified or cancelled.

Bulk Ordering Considerations

Beyond multi-site ordering, enterprises sometimes need bulk ordering — placing large volumes of similar orders simultaneously. This differs from multi-site ordering in that the orders may not be for different sites but rather for different users or assets at the same location (e.g. 500 SIP lines for a call centre, or 1,000 mobile handsets for a workforce rollout).

1. Template-based ordering — Define a template (product config, pricing, SLA) and apply it to a list of recipients or locations via CSV upload or API batch
2. Batch processing — The BSS must handle high-volume order ingestion without overwhelming downstream SOM/ROM systems; queue management and rate limiting are essential
3. Progress tracking — Bulk orders need aggregate progress reporting: 850/1000 lines activated, 120 in progress, 30 failed
4. Exception management — Failed items within a bulk order must be individually retryable without re-submitting the entire batch
5. Billing alignment — All items in a bulk order may need to start billing on the same date, regardless of individual activation times (contractual billing start date)

End-to-End Visibility

Enterprise customers expect full transparency into the status of their multi-site deployment. This means the BSS must aggregate status from COM, SOM, ROM, and activation systems into a single, coherent view. The enterprise portal should show:

• Overall rollout progress (e.g. 35/50 sites active)
• Per-wave status with target vs actual completion dates
• Per-site status with colour-coded indicators (active, in progress, delayed, failed, pending customer action)
• Upcoming milestones (next wave start date, CPE delivery dates, scheduled site visits)
• Alerts for sites requiring customer action (building access, power, contact confirmation)
• Historical timeline showing when each site was activated