design

Revenue Assurance Lead — design notes

The Revenue Assurance Lead (Cluster Relationship Manager) workspace, and the second scope the same person holds.

Persona: Adaeze Nwosu · Revenue Assurance Lead. One login, two hats, switched from the account menu.

Two scopes, one identity

On the Polaris org chart the South West Revenue Assurance Manager also holds the acting Product Manager, Revenue Assurance position. Support supervision belongs to that second position, not to a separate person, so it is a scope of this flow rather than a flow of its own. There is no “Support Supervisor” role.

The role switcher lists both scopes at the top and swaps the sidebar between them:

• Revenue Assurance Lead — grouped Core / Supporting / Team / Rider happiness. Core: Cluster Scorecard, Command Center, Cases, Swap and Energy Billing, Wallet and Collections, Overdrafts and Reconciliation, Fee Exceptions and Waivers, Payments and Virtual Accounts. Supporting: Asset Revenue (ARRR), Payouts and Revenue Share, Promos and Incentives, Disputes and Adjustments, Reports and Period Close, Parked riders. Team: Team performance, Riders, Relationship managers, Scorecards, Activity. Rider happiness: Overview, Top performers, SRRR / ARRR compliant, Benefits and rewards.
• Product Manager, Revenue Assurance — Live board, Breach and backlog, Queues and agents, Quality, Categories, SLA and OLA, Routing rules, Templates, Broadcasts.

Nav items are tagged data-scope="ra" or data-scope="pm", so setScope() shows one set and hides the other without restructuring the sidebar.

Cluster Scorecard (the portfolio view)

The first item in Core is the Cluster Scorecard — the RA Lead’s (and the VP’s) portfolio screen. Every other tab is single-scope or region-blended; this one puts the operating units side by side so the winners and laggards read in ten seconds.

• Standard filter bar — period (Daily / Weekly / MTD / QTD / YTD) plus cluster and mesh scope. It drives the whole view; the same bar is now the standard control across the RA tabs.
• KPI strip — Revenue, SRRR, Covenant compliance, Active riders. Each shows the period-to-date figure and a delta against the prior equivalent period (flows compare period-to-date vs the prior period’s same portion; rates compare in points). Revenue is a period-to-date total, not a run-rate.
• Cluster league table — one row per cluster, ranked by revenue, each with an 8-week SRRR sparkline and a verdict badge; a row drills into its meshes (each mesh carries its own 8-week sparkline). Selecting a single cluster scopes the whole view to it.
• Compliance × SRRR scatter — one dot per mesh, coloured by cluster, sized by riders, with a 95% target reference line. It shows the relationship the tables can’t: compliance drives realization.

The structure is cluster-first and generalises to N clusters — a new cluster is one more league row, sparkline and scatter dot; the KPIs recompute from the cluster list. Today the business is effectively one cluster (Sango Ota ≈ 97.7% of riders; Mowe is a 14-rider outpost), and the view says that out loud.

Visual grammar

A pass over every card fixed encoding to match the data’s job, rather than defaulting to bars: lines for time series (SRRR trend, reversal rate, monthly payouts, the 4-week compliance trend), 100% stacked bars for part-to-whole (compliance mix, payout recipient split, asset disposition), bars kept only for rankings and histograms, gauges for ratios-against-target, and a scatter for the compliance→SRRR relationship. Percentile tiles (p10 / p50 / p90) replace bare averages where the tail is the story (resolution time, overdraft age, swap-days spread).

Swap and Energy Billing — physical-vs-billed reconciliation

The swap-fee model is a daily access fee, charged once on the first completed swap of the day and giving unlimited swaps after, so the revenue unit is the rider-day, not the swap. Detection joins three layers per rider-day: the battery physically picked up (a BMS-id change in the tricycle telemetry), the swap logged in the app, and the daily fee paid. A tricycle that swapped a real battery on a day it paid no fee, with no active waiver, is a leak. The logged channel bills essentially 100% of what it records (one unbilled rider-day in a fortnight), so every case in the queue is a physical pickup that bypassed billing.

• Recovery queue — one row per flagged rider (severity, unbilled days, amount owed, status), worked to Recovered / Dismissed with a header “Recover all open” action. A “By rider / By station manager” toggle flips the same data to rank the managers on the desk by the unbilled exposure that occurred on their shifts.
• Case detail is a full page (.pg-back + .pg-head with actions), never a drawer: the rider’s owed amount, RM, per-leak-day pickup times, the station and the manager who was logging everyone else’s swaps that day, an August swapped-vs-billed strip, and a collusion flag when the same manager recurs across a rider’s free days. Actions: recover the fee to the wallet, escalate the station manager, or dismiss a false positive.
• Serial hygiene — the BMS-id field carries read corruption (letters substituted for digits), so a pickup counts only as a change to a new well-formed 12-digit serial that persists across frames; corrupted single-frame reads are dropped before counting, and gap-days are cleared as honest low-usage unless the battery genuinely changed.

The confirmed figures are a full-month telemetry audit of the highest-signal riders; the fleet estimate firms up when the per-tricycle sweep runs nightly (the raw telemetry hypertable is too large to scan a full month interactively).

Wallet and Collections — balances and charge

The Wallet KPI “In rider wallets” opens a full balances page (not a modal): every funded rider with their prepaid balance, a populated rider search, a date filter, and an inline amount + Charge that posts a DEBIT against the wallet exactly as a completed swap does. Selecting a rider opens their detail page with balance, relationship manager, plate number and swap station, a charge control, and Swap history / Payment history tabs filtered by the date range.

Payouts — Earnings Reform (interim)

The Payouts tab reflects the Earnings Reform live from 17 Aug 2026: swap commission moves to 0.90% of net ₦12,000 (was 1.00% of gross ₦12,900), split RM-side 0.50% / agent-side 0.40%; a 4-day covenant gate governs the RM/cluster share; activation moves to 40% of the fee with half escrowed to day 90. This is an interim policy view; the operational rebuild (live per-station RM earnings, escrow-at-risk, the real unallocated pool) and its move under Command Center → Payout is a tracked follow-up.

What the supervision scope owns

The configuration the rider support agent console deliberately cannot touch: the category taxonomy with its sub-categories and default priorities, the customer SLA and the internal OLA per receiving department, and the category-to-department routing table. The agent console consumes all three. Agents never choose an escalation destination; a category does.

Architecture

This flow renders every view from JS into a single #view container via navTo, and uses one generic dialog through openDlg() / closeModal() with Escape wired once. Ported supervision views carry a sup prefix to avoid collisions with this flow’s own handlers.

Data grounding

Every tab is a point-in-time snapshot grounded in the Rechaj data warehouse (read-only SQL), not invented numbers: SRRR and revenue by cluster / mesh / RM, covenant compliance on the swap-days rule (Sango Ota ≥5 of 7; Redeem Camp / Mowe ≥6 of 7), overdraft float and reconciliation, virtual-account inflow and wallet posting, revenue-distribution payouts, promo awards vs SRRR lift, fee-exception requests, unique-swap-day loyalty tiers, and RADR telemetry for parked kekes. The scorecard’s cluster/mesh figures, period-over-period deltas and sparklines are live warehouse pulls; the current partial week is excluded from period aggregates so it does not zero out compliance. Filters (period, cluster, mesh, and the tab-specific ones) recompute so they behave like the live page will.

Known follow-ups

• Scatter colour is categorical by cluster; beyond ~3 clusters the (green-centric) design system needs a categorical ramp added — a design-system decision, not blocking at two clusters.
• Payouts operational rebuild + relocation under Command Center → Payout (see above).
• Demographic capture is thin (~8% of riders have gender/age), so the Rider happiness demographic view is honest about the gap rather than profiling on absent data.