Daily Revenue Reporting System
Built SalesRabbit's daily revenue reporting system as Director of Revenue Operations, replacing a two-day manual monthly MRR pull with a real-time, event-based dataset that isolates exactly why revenue moved, down to the customer, subscription, and product line.
Problem
SalesRabbit's CFO once asked Mickey a simple question: "What's our MRR right now?" Mickey didn't have an immediate answer. For a SaaS company, MRR is one of the most basic health metrics there is — not having it on hand was an uncomfortable moment, and it exposed how fragile revenue reporting actually was.
The gap wasn't a lack of data — it was process. Revenue reporting was a manual pull done once a month by the director of finance: downloading an MRR report out of Ordway into a Google Sheet, roughly two days of work each time. Leadership was making decisions off numbers that could be weeks stale by the time anyone saw them.
It also wasn't one-size-fits-all. Sales needed to know which customers to target for expansion. Engineering needed to know which products were worth investing in. Finance needed reliable projections for the board. A single static monthly report couldn't efficiently serve all of them, and building a new one-off report every time a new question came up wasn't sustainable.
Approach
Mickey built this as Director of Revenue Operations, solo, layering on top of foundational work already in place from SalesRabbit's earlier Ordway implementation and the Ordway-to-BigQuery pipeline he'd built and maintained.
The core decision was to stop modeling revenue as a snapshot and start modeling it as a transaction history. He built an "MRR Events" table — one row per customer, subscription, product, and date combination, each carrying the specific MRR delta it caused, rather than just a current-state balance.
That event-based structure could answer nearly any revenue question on demand — current MRR, expected churn next month, revenue attributable to a specific product over any window, which vertical was hit hardest — without a new report needing to be built from scratch each time a new question came up.
Getting the data model right turned out to be the easier half. The harder problem was presentation: people wanted a simple, self-explanatory report, not a lecture on the mechanics behind it. Hiding that complexity without losing the rigor underneath was as much the job as building the pipeline itself — a lesson that played out directly in how the report was adopted (see Outcome).
Technical depth
- A live Tray webhook streamed every subscription change from Ordway into BigQuery in real time, producing a complete, gapless history rather than periodic snapshots.
- dbt handled the SQL transformation layer, producing a final BigQuery table that fed downstream reporting tools: Looker, Tableau, and Drivetrain.
- MRR changes were decomposed using partial derivatives across list price, quantity, and discount — isolating mechanically why MRR moved, not just that it did, at the customer/subscription/product/field/day level.
- Two independent classification layers ran on top of that granularity: subscription-level change types (users or products added/removed, subscriptions created/canceled/renewed, tier "mutations," price/discount changes, billing-cycle and contract-length changes), and MRR-movement categories (new, reactivation, upsell, cross-sell, downsize, downgrade, canceled, expired, pending renewal/churn).
- That granularity meant compound same-day changes resolved cleanly instead of netting into one ambiguous number — e.g., a customer adding one product (a cross-sell) while receiving a larger discount on another product in the same agreement (a downsize) showed as both, correctly separated, on the same day.
- The SQL handled highly customized plans — common even among non-enterprise customers — as routine edge cases rather than exceptions.
- Tracked all live and historical subscriptions: 10,000+ subscriptions and customers cumulative, all-time, including churned accounts, with the ability to reconstruct the exact revenue state for any past day.
- Supported three distinct product lines, including additional ones added later through acquisitions — new acquisitions were automatically incorporated into the reporting without requiring the underlying logic to be rebuilt.
Outcome
Cut revenue reporting from roughly two days of manual work once a month to a near-real-time daily report.
Became the company's foundational revenue dataset — reviewed daily by the executive team and made fully transparent company-wide, where it was actively used, not just available.
The analytics team relied on it for downstream modeling — why MRR moved, which customers were at risk, what was working — analysis that wasn't possible on the old monthly snapshot.
The CFO regularly commented that he "didn't know why it needed to be so difficult." Mickey helped him see that the underlying revenue questions genuinely weren't simple — the system could answer nearly any of them — but what he actually needed was a curated view with the right filters applied, not the raw dataset. Once he had that, the friction disappeared.
SalesRabbit's director of account management wanted to use the report but kept requesting a metric it didn't originally support: net revenue retention between any two arbitrary days, not just from the start of a month. Mickey built the categorization logic needed to support that, and adoption followed quickly once it was available.
The broader lesson, visible in both stories: a technically comprehensive system doesn't guarantee adoption on its own. Ongoing training, iteration, and a willingness to adapt when a stakeholder isn't getting value mattered as much as the underlying engineering.