RevenueOps agent
Watches revenue lifecycle signals across billing, CRM, product usage, and customer health.
Operating brief
design targetRevenueOps should be a recommendation-and-escalation agent first. Revenue outcomes are slower and multi-causal, so the architecture emphasizes evidence packs, playbook selection, and human approval before customer-visible actions.
Every agent uses the same loop: ingest, normalize, analyze, detect, decide, log. The useful design work is deciding what evidence enters the context, which actions exist, which actions stay dry-run, and how the ledger proves that the agent helped.
Agent design diagram
click nodesThe diagram is the high-level system boundary for this agent. Click a node below it to inspect what belongs in that layer and what should stay outside the agent.
RevenueOps loop
Detect churn risk, failed-payment recoveries, expansion signals, and pipeline hygiene issues. Select the right playbook.
Signals, detectors, and outputs
design inventoryThis is the detector inventory to design first. Each detector needs a source signal, a user-visible output, and a measurement that can be written back to the ledger.
Failed payment recovery
- Signal
- Failed invoice, expiring card, retry status, customer tier.
- Output
- Retry, reminder, or account-owner task.
- Ledger metric
- Recovered MRR and days to recovery.
Autonomy gate
playgroundUse this as a policy-design sketch. The values are not final production thresholds; they show which classes of action should be eligible for auto-execution and which should escalate.
Auto-execute
autoThe action is reversible, confidence is above the floor, and impact stays inside the policy envelope.
- Class
- Billing recovery
- Reversibility
- full
- Design note
- Eligible for auto-action when Stripe permits retry and the account has no support hold.
Context and memory design
agent envelopeResearch converges on context engineering as the quality lever: keep a stable policy prefix, put fresh evidence near the task, retrieve only relevant lessons, and expose a small tool surface.
Stable prefix
Revenue lifecycle definitions, tier rules, dunning policy, escalation policy, customer-contact boundaries, and CRM field contract.
Per-run evidence
Subscription state, invoice history, usage trend, recent support context, account owner, lifecycle stage, and renewal timing.
Memory retrieval
Past interventions by segment, failed playbooks, accepted expansion flags, and customer-specific communication constraints.
Tool surface
Read Stripe, read CRM, create internal task, draft message, submit dunning retry, submit policy envelope.
Evals and rollout
ship safelyBehavior checks
- No unsafe sendCustomer-visible actions never auto-send in v1, even with high confidence.
- Evidence completenessChurn and expansion proposals cite billing, usage, and customer-context evidence or mark the gap.
- Commercial boundaryDiscounts, plan changes, and concessions always escalate.
- Outcome attributionLedger separates direct recovery from multi-causal retention or expansion outcomes.
Open design questions
- Which CRM lifecycle fields are authoritative enough for autonomous tasks?
- What is the minimum evidence pack before a churn-risk card appears?
- Who owns final approval for customer-visible messaging: account owner, founder, or a RevOps queue?
Revenue lifecycle join
Join Stripe, CRM, and product usage into one account-state view with freshness and owner mapping.
Internal-only playbooks
Ship failed-payment retry and owner-task creation through the policy engine.
Evidence packs
Add churn-risk and expansion briefs with human approval and explicit missing-evidence markers.
Slow learning
Review outcomes weekly, not nightly. Distill only when a human marks the intervention as useful.
Research inputs
sourcesThese are the sources used to shape the page. The resulting design keeps the vendor-specific advice at the architecture level: tool surfaces, guardrails, context, orchestration, outcome logging, and domain metrics.