Automated Intelligence Revenue System (AIRS)
Turns product usage signals into prioritised, explainable revenue action.
A revenue intelligence system design connecting behavioural product data, governed analytical models, explainable scoring, orchestration, and operational sales interfaces.
Data architecture, analytical modelling, ML workflow, and product design
Current system design
Replaces stale product exports with prioritised accounts, clear reasoning, and sales-ready next steps.
Current system design
What the system is meant to change.
For
Product-led teams that need to connect usage, account health, and revenue signals into prioritised actions.
Replaces
Product usage, account health, CRM, and billing signals often live in separate systems. Revenue teams work from stale exports or intuition because no governed layer converts that behaviour into prioritised action.
Produces
A governed daily view of prioritised accounts, score explanations, and recommended next actions, designed around sales capacity rather than an arbitrary probability threshold.
Treat scoring as one governed step inside a revenue workflow.
Product events, CRM accounts, and billing state land in BigQuery and are modelled with dbt. A feature pipeline supports baseline comparison and XGBoost scoring, SHAP provides local explanations, and Airflow coordinates delivery into sales briefings and Power BI.
Product and account data
Explainable scoring
Revenue action
Design constraints
- 01Model product, CRM, and billing data at a stable account and scoring-date grain.
- 02Compare a simple rules or logistic baseline before accepting a more complex model.
- 03Keep explanations tied to governed features rather than generated sales language.
- 04Design delivery around team capacity and duplicate-safe orchestration.
Engineering decisions
- 01Stable analytical grain: Account and scoring date form the contract across features, scores, explanations, and delivery.
- 02Baseline before complexity: Rules and logistic regression provide a reference before evaluating whether XGBoost adds decision value.
- 03Capacity-aware thresholds: Precision and lift at the team’s workable daily volume matter more than an arbitrary probability cut-off.
- 04Explain before outreach: SHAP-backed reasons support account review; generated outreach remains outside current evidence.
System behaviour and reliability
- 01Product, CRM, and billing data are modelled at account and scoring-date grain.
- 02Contract checks protect keys, freshness, accepted values, and feature ranges.
- 03Baseline and candidate models produce comparable account scores.
- 04Local explanations translate model signals into controlled operational language.
- 05Airflow coordinates scoring and delivery into a decision interface.
- 06The design uses stable account and scoring-date keys.
- 07Batch writes are designed around merge semantics instead of blind append.
- 08Notifications require deterministic delivery keys to prevent duplicate outreach.
Evaluation approach
- 01Use temporal train, validation, and untouched test windows.
- 02Compare PR-AUC, precision@k, recall@k, lift@k, Brier score, and calibration.
- 03Keep generated factual statements traceable to allowed evidence fields.
Interface views for the workflow and its decisions.
Design representation — replace these views with production screenshots as the product matures.
A proposed decision surface showing priority, evidence, explanation, and the next review step.
A feature-level view designed to make the ranking inspectable before anyone acts on it.
What exists now, what remains limited, and what comes next.
This separation is intentional: planned evaluation and reliability work is not presented as completed evidence.
Current evidence
Limitations
- 01No measured model or business-performance claim is published yet.
- 02Outreach generation remains outside current evidence until its evaluation benchmark exists.
Next validation
- 01Compare a rules baseline, logistic regression, and XGBoost on a temporal split.
- 02Select thresholds using precision, recall, and lift at the team’s daily capacity.
- 03Publish an idempotency test before presenting the orchestration as production-ready.
- 04Evaluate generated outreach for evidence coverage and unsupported claims.
Send the current workflow, source material, report, or product idea.
A polished specification is not required. The rough version is enough to establish the problem boundary and useful next step.