What Salesforce Won't Show You.

Three small pushes on a close date. That's the signal. When a sales rep moved a deal's projected close date three or more times, even by a few days each time, that deal was four times more likely to end in a loss. The problem wasn't identifying that pattern. The problem was that no one had the data to see it.

A B2B SaaS company managing tens of thousands of active customer accounts, 25-plus sales reps, and mid-eight figures in annual subscription revenue had no way to watch their pipeline at that level of detail. Their CRM stored the current state of every opportunity. Their subscription system tracked every invoice and renewal. Neither system was telling sales leadership what was happening inside their deals.

That was the problem we were asked to solve.

THE PROBLEM

The company sells financial planning software to independent financial advisors, wealth managers, and broker-dealers. Deal cycles vary by product and buyer. Some close in days. Enterprise deals can stretch for months. Post-sale relationships determine whether customers renew, expand, or leave.

They used Salesforce for everything on the revenue side: prospecting, pipeline management, contracts, training calls, and support. They used Zuora to track subscription data: orders, invoices, renewals, seat changes, and new product purchases. Two systems. Two versions of revenue truth. Neither designed to talk to the other.

Finance leaders needed to explain ARR changes at the end of every month. Sales leadership needed to know which reps were struggling and why. Neither group had clean answers.

The manual workaround: two analysts spent a full week every month pulling data from both systems, reconciling it by hand, and building the ARR and MRR reports that leadership depended on. When the reports were done, they were already stale.

WHAT WE FOUND

The first instinct from the data team was that this was a tooling problem. More dashboards. A better BI layer. Maybe a new pipeline view. That framing was wrong.

The real issue was structural. Salesforce and Zuora are both excellent at what they do. Neither is built to answer the question of what happened over time.

Salesforce's architecture makes that concrete. The Opportunities table shows where a deal is now, not where it has been. Salesforce supports field history tracking, but only for fields that were explicitly configured before the data was created. If the admin hadn't set that up years earlier, the history was gone. What remained were partial history tables, prone to duplicates, and dependent on decisions made by people who had long since left the company.

Zuora added another layer. Its data model is built around the state of orders, invoices, and payments. MRR and ARR don't exist as fields. A seat add-on, a price increase, a new product purchase, and a renewal can all look similar in the raw data. Classifying them requires judgment, applied consistently, across every record, every month.

The data team had access to both systems. They had no way to make that data mean something to the people who needed it.

WHAT WE BUILT

We went in with a three-person team: a strategist, a BI analyst, and a data engineer. The engagement ran three months, with delivery timed to the company's new sales calendar year.

We started on-site. The first visit was with leadership: sales, finance, and account management together in the same room. Before touching any data, we needed to understand how the business worked.

We walked through every entity in Salesforce. Training calls. Support tickets. Leads. Stage progressions. Closed won. Closed lost. For each one, we asked what this event meant inside the context of how their team operated. A deal moving directly from discovery to contracting signaled something specific. A two-week close-date push meant something different from a six-week one. A customer who attended training within the first two weeks of signing carried a different implication than one who skipped it entirely. We took generic Salesforce record types and mapped each to a named business event that a salesperson or CFO would recognize.

We did the same with Zuora. When a subscription record changed in a particular pattern, it signaled a seat add-on, a new product, a price adjustment, or a churn event. None of those classifications existed in the raw data. We built them.

The result was a data model where every customer account had a readable story. Not just a snapshot of where things stood, but a sequence of what actually happened.

Our second on-site visit was a hackathon with the broader data and analytics team. The goal was buy-in. People who understood the business logic from the inside would be the ones maintaining and extending this system after we left. Getting them invested early wasn't optional.

With the classification work complete across both systems, every business event landed in a single table with a timestamp, a named event type, and a reference back to the original source record whenever more detail was needed.

Looker sat on top of the Redshift data mart as the visualization layer. The monthly ARR and MRR reports that had previously consumed two analysts for a week ran automatically. Finance got the same quality of output in minutes instead of days.

OUTCOMES

The clearest operational result was the reporting cycle. Two FTEs spending a full week every month building ARR and MRR reports by hand became an automated process. Finance leadership got consistent output without the manual overhead.

The more significant shift was in how sales leadership operated.

With the event log in place, we ran historical analysis on every closed deal. What distinguished closed-won from closed-lost? What happened differently in the weeks before a deal went dark?

“When a rep pushed a deal's close date three or more times, that deal was four times more likely to end in a loss.”

Sales managers got a live dashboard showing which reps had deals approaching those thresholds. A rep with two close-date pushes on an account became an actionable prompt: schedule a conversation before the third push happens. The dashboard didn't replace those conversations. It made sure they happened at the right moment, with the right context.

ARR decomposition became possible for the first time. When a key account's ARR increased by 10%, finance could now trace exactly what drove it: a seat add-on, a new product, a price adjustment. When ARR dropped, they could identify why. The explanations that used to require a week of manual work were available in a single report, and always current.

Account managers gained a view they'd never had. They could pull up any customer account and read the full event sequence from initial sale through current status. The story that had previously required multiple systems and guesswork was now one view.

WHAT THIS MEANS FOR OTHERS

Salesforce is not a database. Zuora is not a reporting system. Both tools are built to power the interfaces their users work in every day. They are not built to answer analytical questions about what happened over time.

That's the right design for their purposes. But it creates a gap between the operational record and the analytical truth. Closing that gap requires translation work: understanding how the business runs, naming the events that matter, and building a data model that reflects reality instead of mirroring the source system.

Most analytics projects skip that step. They pull the Salesforce export, build the dashboards, and hand them over. The reports look complete. They show deals, stages, and close dates. What they don't show is what the data means inside the context of how the team sells.

The event log approach changes that. When every business action is named, timestamped, and stored in sequence, the analytical surface opens up. You can identify which events precede expansion. Which ones precede churn. What distinguishes the accounts that grow from the ones that don't. Those questions are impossible to answer when you're working from a stateless snapshot of current-state records.

For any company running a complex sales motion alongside subscription revenue, these gaps almost certainly exist. The tooling is probably fine. The translation layer probably isn't.