Recovery Overview
Lost-revenue exposure, ownership and where to act
📅 1–7 Oct 2019
🗼 1,000 cells · 334 BTS
● Live sample data
💸 Lost revenue potential — the recovery picture
Every session that ends with a problem release-cause is revenue that could have been earned. This dashboard quantifies that exposure, maps it to the network element responsible, and turns it into a prioritised, costed recovery plan. Figures are revenue-at-risk estimates (failed sessions × average revenue of a successful session).
Revenue at risk by root cause
7-day exposure per failure category, coloured by responsible element
By responsible element
Who owns the fix
Revenue at risk by region
Where to prioritise field work
Recovery at a glance
From exposure to action
Revenue forecast — rolling 6 months ahead
Projection from the current run-rate. The recoverable revenue is split into two tracks: reallocation / refarming (recovers the LackOfCapacity losses by shifting capacity from idle to congested cells — near-zero capex, fast) and capex fixes (coverage, core, hardware, etc. — slower). Same total, no double-counting.
Organic growth
Reallocation ramp
Capex ramp
Latent demand (assumed)
Monthly revenue trajectory
Baseline vs with-recovery — shaded area is the recovered revenue
Monthly figures
Projected revenue per month
| Month | Do nothing | + Realloc | + Capex | + Demand | Uplift |
|---|
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.
Why revenue is being lost
Each failed session is classified by its release-cause into one of the ORION failure categories, and attributed to the element that must fix it. Start with the biggest bars.
Failed sessions by root cause
Volume of failures feeding the loss
Top failure signatures
Most frequent problem release-causes in the data
| Release cause | Maps to | Sessions |
|---|
Root-cause breakdown
Each cause, its owner, failure volume and revenue at risk — prioritised
| Priority | Root cause | Owner | Sessions | Revenue at risk (7d) | Annualised |
|---|
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.
🎯 Top 25 cells to upgrade first
Cells ranked by recoverable revenue (revenue-at-risk from failed sessions), with payback on an illustrative upgrade cost. Filter by root cause to hand each team its own work-order list.
| # | Cell | Region | RAT | Failed | Primary cause | Recoverable/yr | Upgrade cost | Payback | Recommended action |
|---|
Recovery action plan
Root cause and recommended actions per failure category, prioritised by revenue at risk. Each checklist is owned by the responsible team.
Where to deploy field teams
Revenue at risk and recovery efficiency by region — to direct capex and crews to the highest-payback areas.
Recoverable revenue per 1,000 population
Recovery efficiency — prioritise high-density, high-loss regions
Network load by region
Data carried per region (TB) — context for capacity fixes
Regional recovery detail
Captured revenue, revenue at risk, population and recovery efficiency per region
| Region | Captured revenue (7d) | Revenue at risk (7d) | At-risk % | Population | At risk / 1k pop |
|---|
Where the lost revenue is — network coverage map
Every base station plotted by its real coordinates, colored on one scale — green = healthy → red = high lost revenue. Toggle layers, filter by cause, and use the slider to focus on the worst sites.
Layers:
Filter by root cause:
Show sites with revenue at risk ≥
Capacity utilisation — where there's spare headroom
Each cell's used load vs the busiest cell (peak = 100%): voice as Erlangs, data as Mbps. Cells under 50% are under-utilised — candidates for consolidation, refarming or energy savings.
Measure:
Cells by utilisation
Distribution of cells across utilisation bands (the <50% bars are the opportunity)
Most under-utilised cells
Lowest-load cells with their voice / data split
| Cell | Region | RAT | Voice | Data | Utilisation |
|---|
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.
Revenue-first upgrade priority
Every cell placed on technical load (utilisation) × commercial value (revenue). Spend capex where load and value are high; defer low-value congestion; protect high-value cells with headroom. Move the thresholds to set the bar.
Load bar (top %)
Value bar (top %)
Upgrade matrix
load (x) × value (y) — colour = recommended action
🚀 Upgrade now — top sites
High load + high value (the spend-first list)
| Cell | Region | RAT | Util | Revenue | Class |
|---|
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).
Underutilised capacity — monetization gap
Cells with spare capacity, valuable users (ARPU) but low current revenue — revenue you can capture without new capex via campaigns, products or capacity reallocation. gap = headroom × user value × (low current revenue).
Top monetization-gap cells
Idle capacity worth filling
Opportunity list
Headroom, user value and current revenue per cell
| Cell | Region | Headroom | ARPU | Revenue | Gap |
|---|
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).
5G rollout & CAPEX prioritisation — by revenue
Rank sites by a composite rollout score = weighted blend of demand, 5G-ready devices, monetisation and congestion. Re-weight the factors to your strategy, set a CAPEX budget to pick the optimal site set, and export the rollout plan.
Demand
5G devices
Monetisation
Congestion
CAPEX budget
· €50k / site (assumed)
Rollout hotspots
Sites by rollout score — selected (in-budget) sites are ringed
lower scoremidtop candidate· ⭕ = selected in budget · size = revenue
Prioritised rollout list
Ranked by score; ✓ = within budget
| # | Site | Region | Score | Revenue | Util | 4G% | In budget |
|---|
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).
Precision 4G→5G subscriber migration
Individual subscribers with a 5G-capable device who are under-monetised (high data usage, low spend) — the highest-probability conversions to a 5G plan. Eliminates the capable-device / under-monetised mismatch.
Migration candidates by region
Where the ready-to-convert base sits
Top conversion targets
5G device · high data · low ARPU
| Subscriber | Device | Data | Spend (7d) | Region | Score |
|---|
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".
Differentiated QoS for high-value subscribers
High-value subscribers experiencing degraded experience (elevated session-failure rate) — prioritise their QoS under congestion to protect revenue and reduce churn.
At-risk high-value subscribers by region
Where to prioritise QoS / interventions
Protect first — top exposures
High value × high failure rate
| Subscriber | Spend (7d) | Failure rate | Region | Device | Priority |
|---|
"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.
The source of the loss — session failures
Revenue recovery starts here: every failed session below is lost-revenue potential. Success rates come straight from release-cause codes.
Session success by service
Successful vs. failed sessions (from release-cause codes)
Success rate detail
Share of clean releases per stream
The records behind the loss
Raw records arrive as daily CSV files (e.g. 2019-10-01-voiceImsi-record-1-244273.csv). Each carries an rcc release-cause — when it isn't a clean release, that row is revenue at risk. Below are real rows, including failures.
Voice record voiceImsi
internalCellId · duration(ms) · imsi · msisdn · rat · rcc · revenue · roamer · direction · tac
Packet data — user plane packetDataUPImsi
application · category · bytesUp/Down · imsi · cellId · url · revenue · tac · rat
How a failed record becomes a recovery action
The same keys join to reference tables, turning a raw failure into an attributed, costed action.
🔔 Smart Alerts — automatic anomaly detection
ORION continuously scans every site and cell and flags statistically abnormal behaviour — revenue-leak hotspots, congestion risk and under-monetised cells — each against its own peer baseline (robust z-score / median-absolute-deviation). This is the batch, on-sample view of the roadmap's real-time alerting.
Active anomalies
Highest severity first
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.
🧠 AI Executive Briefing
A grounded, plain-language summary of this week's revenue position — generated from the live figures, with the drivers explained. Read the instant briefing below, or generate an AI-written narrative.
🔮 Predictive Capacity Planning
Projects every cell's load forward under a demand-growth assumption and predicts when each cell will breach capacity — so upgrades are scheduled before congestion causes revenue loss, not after. Tune the assumptions and the capacity cliff and pre-emptive schedule update live.
Capacity cliff — cells crossing the action threshold
How many cells need action in each month ahead
Pre-emptive upgrade schedule
Soonest-breaching cells first
| Cell | Region | RAT | Load now | Proj. | Action in | Breach in | Rev/wk |
|---|
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.
🤖 Prescriptive Actions — toward self-healing
Closes the loop: for each problem cell AxS ranks the single highest-value action, applies policy guardrails (auto-approve within budget, else human approval), and lets you simulate execution to see recovery accumulate. In production the approved actions dispatch to OSS/BSS with rollback and audit.
Action queue
Ranked by expected annual recovery
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.