Recovery Overview

This is a scripted agent: the intent is parsed for objective, budget, region and cause; each stage runs ORION's own engines (alerts, loss by cause, ranked cells with cost and payback, the CAPEX classifier, the options engine) and the plan is a greedy allocation by payback inside the budget. Numbers are therefore the same as elsewhere in ORION and computed on the 7-day sample with illustrative costs. A production deployment adds model-based narration and real execution and measurement feeds; the agent never changes the network — it records a decision for human approval.

Scenario projection from the 7-day run-rate — not a trained time-series forecast (the sample is one week). Baseline = current monthly revenue compounded by the organic-growth assumption; "with recovery" phases the recoverable revenue (the at-risk total) in over the chosen ramp. Adjust the sliders to model your own assumptions.

Estimate model: revenue-at-risk = failed sessions × average revenue of a successful session of the same type. Categories derive from the ORION RCC lookup (Appendix B); "UserError" shows zero because no user-error release-causes appear in this sample period. Subscriber-owned causes need commercial, not network, fixes.

Utilisation is shown relative to the busiest cell (peak = 100%) because the sample's equipped-capacity fields (equippedMaxVoiceCapacity / equippedMaxDataCapacity) are sequential placeholders. With real equipped values this becomes a true used ÷ capacity %, and the same chart isolates genuinely under-provisioned vs over-provisioned cells.

Classification = load × value quadrant: Upgrade now (high/high), Protect & grow (low load / high value), Optimize before investing (high load / low value — don't sink capex into low-yield congestion), Maintain (low/low). Value = revenue (a real monetization signal); utilisation is relative-to-peak (see Cell Utilization).

Gap is normalised 0–100. It surfaces the doc's "monetization gap" — technical readiness exceeding commercial exploitation — and feeds the reallocation track of the Revenue Forecast. ARPU here is revenue ÷ distinct subscribers per cell (a proxy until rated/CRM data is loaded).

Rollout score (0–100) = weighted percentile blend of demand (revenue), 5G-ready devices (4G-usage share — sparse in this sample; raise the weight to surface 4G-heavy sites), monetisation (ARPU) and congestion (utilisation). Budget mode greedily selects the top-scoring sites at €50k/site (illustrative). Supports the CTO/CFO/CMO investment case (UC1) and the yearly-CAPEX decision (UC7).

Method, data & honest limits. Capacity availability = headroom against the site's equipped capacity, expressed as utilisation relative to the busiest site in the sample (a topology-based proxy — claims about actual radio-resource utilisation require OSS performance KPIs, which are an enrichment, not part of the core). Revenue utilisation = rated revenue against comparable sites (same technology, similar subscriber base), revenue per subscriber and revenue per GB. Monetization potential = share of active subscribers with 5G-capable devices, the revenue and traffic those devices generate, and the gap to the better-performing comparable sites. Sites are single-technology in this sample, so the "capable devices still using an older technology" signal is measured at cluster level (capable-device traffic carried on non-5G sites in the same cluster). Underutilization alone never produces a recommendation: the assessment requires available capacity and evidence of addressable demand; demand without capacity is handed to UC-2. The resource-transfer panel pairs vacant resources with congested sites in the same region as a planning suggestion, without cost figures. Trend compares the last three days with the first three of the 7-day window; post-action measurement and verification are simulated against the real baseline — production uses real history, configurable windows and campaign identifiers from CRM. ORION verifies the recommendation; it does not claim causal attribution.

Method, data & honest limits. All indicators come from the sample's own transactions and topology: every site resolves to one technology (2G/3G, 4G or 5G) from its cells, so 4G revenue is the rated revenue of 4G sites, not a share; existing 5G is the three 5G sites in the topology; 5G-device readiness is the share of a site's active subscribers whose transactions carry a 5G-capable device type, and the revenue and traffic those devices generate are measured directly; trend compares the last three days with the first three of the 7-day window. Demand = active subscribers, data traffic and trend; Commercial = rated revenue, revenue per subscriber and the candidates' share of the cluster's revenue. Clusters are the site groupings used across ORION (region split by a 3×3 geographic grid); the decision is taken at cluster level because sites are grouped for implementation. The capacity input is an indicative translation of 5G-capable subscribers into Mbps and carriers under a stated assumption — a planning input, not a design. No cost or payback figures are shown in this use case by design. On this sample the 95 4G sites are similar in size, so site-level differences are small and the cluster level carries the story. Post-deployment measurement and verification are simulated against the real 7-day baseline — production computes them from real history with configurable windows. ORION verifies whether the recommendation was supported; it does not claim the deployment caused the change.

Method & caveat. Investment score = weighted percentile blend of revenue (current monetisation), demand (load) and future (5G-device readiness); the 4G lens weights revenue, the 5G lens weights device readiness. Revenue opportunity ≈ annual revenue × f(revenue potential, load) — the incremental unlocked by investing. Sites are classified on load × revenue-potential (load terciles; top-45% potential). CAPEX is illustrative (€50k/site). This is a revenue-reasoning planning aid on the 7-day sample; production adds trained demand growth, real equipped-capacity and rating data.

Demo & method. Readiness is a composite of four percentile-ranked signals per area — audience (subscriber base), spare capacity (100 − utilisation), value (ARPU) and experience (100 − at-risk %) — blended by the weights above. 4G-device share is shown as context: it is sparse in the 7-day sample, so it informs rather than drives the score until the full TAC catalogue is connected. This is a static readiness index for targeting; the full use case also measures adoption lift with pre/post launch comparison, which needs multi-month history the 7-day sample doesn't have — simulated below for the demo.

Method & caveat. Per area, four readiness dimensions are percentile-ranked and blended by a service-specific weight profile: usage (subscriber base/activity), device (5G-device readiness = 4G share), capacity (spare headroom = 100−util) and demand (ARPU/value). Areas split into waves by readiness tercile. The business case is a scenario model: addressable = base × f(readiness); uptake = addressable × service ceiling × f(readiness); incremental revenue = uptake × ARPU-uplift × 12 (shown as a low–base–high range, not a promise); cost = a per-area launch cost + a capacity surcharge where headroom is tight; payback = cost ÷ monthly incremental revenue. Cost assumptions should be confirmed with finance; ORION improves launch targeting and economics, not perfect demand prediction.

Method, data & honest limits. Launch areas are clusters of sites (region split by a 3×3 geographic grid) — the decision level sits above the individual cell, as the use case requires; the site list behind each area is shown in the detail. Demand = active subscribers, data usage per subscriber and traffic trend; Device readiness = 5G-capable device share and count, a derived proxy (the sample carries no per-site device field; it is built from the region's real 4G/5G revenue share, modulated by ARPU and calibrated to the real measured 19.4% 5G-capable devices); Network availability = the share of the target population's activity in locations where 5G is available, derived from topology only (anchored to the 9 real 5G cells, all in Northwest, plus distance to them) — it never infers congestion or quality; Commercial readiness = rated revenue, revenue per active subscriber and revenue of the addressable population. Data usage per subscriber is derived from relative site traffic. Trend, post-launch measurement and verification are simulated on this 7-day sample — production computes them from real history against a configurable baseline, and adds product-catalogue / CRM enrichment to exclude subscribers already on the proposition. Comparison areas are evidence for verification, not a causal claim.

Propensity = data-usage rank × (1 − spend rank), for 5G-capable devices only. Subscriber IDs are pseudonymised (last 4 digits) — production would key on a tokenised subscriber reference. Device 5G-capability from the TAC catalogue (iPhone 13, Galaxy S23 5G, Galaxy A25). Plan/contract data (CRM) would sharpen "under-monetised".

"High value" = top revenue quintile; "degraded" = failure rate in the top quartile (from release-cause codes — a QoE proxy until true QoE/latency metrics are ingested). Priority = value × failure rate. Feeds retention and QoS-policy workflows.

Method, data & honest limits. High-value = top 20% (or 10%) of the 85,000 subscribers by 7-day rated revenue (thresholds configurable). Populations are high-value subscribers grouped by their primary area (the site cluster where most of their transactions are served) — the same clusters used for launch areas — so the subscriber view and the location view describe the same people. Concentration is computed from the real serving cell of every voice, SMS and data transaction: the share of a population's activity inside its own area, the high-value share of the area's revenue and high-value density. Usage = data volume, transaction activity and share of activity on 4G/5G. Value = rated revenue, revenue per subscriber and the population's share of regional revenue. This view uses no OSS performance KPIs and no session-failure rates and makes no claim about throughput, congestion or radio quality. Limits of the sample: every subscriber is active on all 7 days; device is known for roughly a third of subscribers; no service-type or latency data exists; the synthetic sample spreads each subscriber's activity across many sites, so concentration differences between areas are small (production data shows real clustering). Revenue trend, post-implementation measurement and verification are simulated on this 7-day sample — production computes them from real history against a configurable baseline. Comparison populations are evidence for verification, not a causal claim. Subscriber identifiers are pseudonymised (last 4 digits).

Method. Each metric (site revenue-at-risk, cell utilisation, cell ARPU) is compared to its peer distribution; a modified z-score ≥ 2.0 (MAD-based, or ≥ 80% load) is flagged Warning, ≥ 3.0 (or ≥ 90% load) Critical. Figures are from the 7-day sample and illustrate the detection logic — a production deployment runs this continuously on live feeds and pushes alerts to email / messaging with severity, probable cause and affected revenue.

Method & caveat. Each cell's current load is compounded at the chosen monthly growth rate; the month it crosses the action threshold (pre-emptive upgrade) and 100% (breach) is reported. With a 7-day sample the growth rate is an assumption you set — a production deployment trains per-cell seasonal time-series models on multi-month history and attaches confidence intervals. Load is relative to each cell's observed peak until equipped-capacity is supplied.

Guardrails. "Apply" here is a simulation — it never touches a live network. Actions with payback within the auto-approve ceiling are marked auto-approvable; slower-payback (larger) ones require explicit approval. A production deployment executes approved actions through OSS/BSS APIs with human-in-the-loop approval, automatic rollback and a full audit trail; autonomous action stays inside explicitly configured policy boundaries.