Unified RevOps Intelligence for a B2B SaaS Company

The problem

The finance and operations team at a 40-person B2B SaaS company spent eight hours every week pulling data from HubSpot, QuickBooks, a Google Sheet shared across three teams, and two other internal tools. By the time the weekly revenue report was ready, the numbers were already 48 hours old. Leadership was making decisions on stale data.

Context

B2B SaaS companies at the 30-50 person stage typically accumulate data tools faster than they accumulate data strategy. HubSpot goes in for CRM, QuickBooks for finance, a project management tool for delivery, and Google Sheets for everything that does not fit cleanly anywhere else. Each tool is a reasonable decision in isolation. Together, they create a fragmented picture that no one person can hold in their head at once.

In this case, the ops lead had become the human integration layer. She understood how to pull from each system, reconcile discrepancies, and produce a coherent number. That knowledge was valuable - and it was entirely trapped in one person. The company had previously attempted to solve this with a manually maintained Excel consolidation template. It worked for two quarters before deal structure changes broke the formulas. After that, it was rebuilt from scratch twice, and eventually abandoned. The problem was not the tool. It was the assumption that a static template could keep pace with a changing business.

What we built

Technical approach

We used n8n as the orchestration layer because it offered native connectors for HubSpot, QuickBooks, and Google Sheets, and allowed us to build the normalization logic as visible, inspectable nodes rather than buried code. The Python normalization layer sits between the raw API responses and the data store - it handles type coercion, currency normalization, and the business logic that translates HubSpot deal stages into recognized revenue categories consistent with QuickBooks.

The natural language interface runs via Claude through an MCP server. We chose this approach over a traditional BI dashboard because the client's leadership team asked different questions each week - they did not want to learn a query language or navigate a filter panel. The MCP server exposes typed tools for each data source: one for pipeline data, one for recognized revenue, one for refund and churn metrics. Claude composes these tools in response to plain language questions and returns answers with source attribution. A vector store caches the embeddings of common query patterns, which keeps response latency low for frequently asked questions. We chose n8n over alternatives like Make because the error visibility and retry logic on n8n's pipeline nodes was meaningfully better, which matters when you are dealing with five live API connections that can each fail independently.

The automation timeline

Challenges and how we solved them

The most significant technical challenge was QuickBooks. The company had been using the platform for four years, and the account categorization had shifted multiple times as the business evolved - service lines had been renamed, merged, and split. Historical data reflected three different categorization schemes. Running a year-over-year comparison without normalization would have produced numbers that looked wrong even when they were technically correct.

We built a normalization mapping layer that translated historical account categories into a consistent schema without modifying any source data. The mapping is maintained as a configuration file rather than hardcoded logic, so the client can update it themselves when their chart of accounts changes in future. This was a deliberate design choice: the system needed to be maintainable by the finance team, not just by us. The second challenge was rate limiting on the HubSpot API during the initial data pull for historical periods. We resolved this by staggering the ingestion schedule and building an incremental sync that only pulls changed records after the first full load.

Results

The finance team reclaimed eight hours per week. Leadership now has a single URL they open on Monday morning. The company moved from weekly manual reporting to continuous operational awareness.

The downstream effects became apparent over the following two months. Without the Monday reporting bottleneck, the weekly leadership meeting shifted from reviewing what had happened to discussing what to do next. The CEO reported making two pricing decisions in the first quarter that she attributed directly to having real-time visibility into trial conversion rates - data that had previously been buried in a spreadsheet that was updated once a week. The ops lead, freed from the reporting cycle, spent that reclaimed time building out a customer health scoring model that the team had been discussing for over a year but had never had the capacity to start.

Key learning

The most valuable part of unified RevOps is not the dashboard - it is the question-answering interface. Once leadership could ask questions in plain language and get immediate answers, the cadence of review meetings changed entirely. They stopped scheduling time to review reports and started having conversations about decisions. That shift is harder to quantify than hours saved, but it is the outcome that matters most. If you are evaluating whether this kind of system is right for your business, the right question to ask is not "how long does our reporting take" but "how many decisions are we delaying because we do not have the right number in front of us right now."