Designing a usage-based upsell lead system

WHAT THIS TESTS The interviewer wants an end-to-end design that ties product telemetry to ARR, with attention to data quality, privacy, and a measurable feedback loop, rather than a vague mention of analytics.

A GOOD ANSWER COVERS Start with the signals that predict upsell: accounts repeatedly hitting plan limits, growing seat or API usage, adoption of features gated to higher tiers, and rising overall engagement. Instrument these as structured usage events. Ingest them through a streaming pipeline or scheduled batch into a warehouse or feature store. Compute an upsell score, beginning with transparent heuristics and rules before any model, so sales can trust and act on the reason. Surface ranked candidates to the sales team through a CRM sync or an internal dashboard, attaching the why for each lead. Finally, record whether each surfaced lead converted, which both measures impact on ARR and improves the scoring over time.

COMMON WRONG ANSWERS Leaping straight to a machine-learning model without first defining interpretable signals sales will believe. Forgetting privacy and consent for usage data. Building scoring with no feedback loop, so you never learn whether leads convert. Pushing raw event firehoses to sales instead of ranked, explained leads.

LIKELY FOLLOW-UPS How do you avoid alert fatigue for the sales team? How would you measure the system's contribution to ARR? When would you graduate from heuristics to a model?

ONE CONCRETE EXAMPLE A SaaS tool emits events when an account hits its monthly export cap. The pipeline aggregates that an account has hit the cap three months running while seats grew twenty percent. A rule scores it a strong upsell candidate, syncs it into the CRM tagged 'repeatedly hitting export limit, growing team,' and a rep reaches out. The conversion outcome flows back, letting you tune the thresholds and prove revenue lift.