Build an Operating Intelligence System in 90 Days

Most operators running B2B SaaS or D2C companies between $1M and $20M ARR face the same problem: the data exists but the intelligence does not. Revenue lives in the CRM. Margin lives in QuickBooks. Pipeline lives in spreadsheets. Ad performance lives in five different platform dashboards. No one has a complete picture. Decisions get made on gut feel, lagged reports, and incomplete information.

This is not a data problem. It is an architecture problem. And it is solvable in 90 days without a data engineering team.

This guide covers exactly how to build an operating intelligence system from scratch — from the first data audit through to a weekly operating review that your leadership team will actually use. The framework applies to B2B SaaS companies at $1M–$20M ARR and D2C brands with comparable revenue. The output is not a dashboard. It is a decision system.

Why Most Companies Do Not Have Operating Intelligence

The gap between data availability and operating intelligence is wider than most executives expect. According to Gartner's April 2026 research, organizations with successful data initiatives invest up to four times more in foundational data quality and governance than those that fail — yet only 39% of technology leaders are confident their current data investments will have a positive financial impact. The investment is happening. The foundation is not.

The reason is fragmentation. The average enterprise runs 897 applications, but only 29% of them are integrated, according to Integrate.io's 2026 data transformation research. At the $1M–$20M ARR stage, that fragmentation typically looks like this:

Each of these systems generates data. None of them generates intelligence. Intelligence requires connection, context, and a defined decision layer. That is what this framework builds.

The cost of fragmented data is material. Research consistently finds that companies lose 20–30% of annual revenue to inefficiencies caused by disconnected systems — poor decisions made on incomplete data, manual reconciliation that consumes 40+ staff hours per week, and reporting errors that compound into forecast inaccuracy. For a $5M ARR company, that is $1M–$1.5M in annual economic drag. It does not disappear on its own.

Operating Intelligence vs. Business Intelligence: The Distinction That Matters

Before building anything, operators need to be precise about what they are building. Most companies already have some form of business intelligence. Operating intelligence is different in three specific ways.

Traditional business intelligence is retrospective. It answers the question "what happened last quarter?" with dashboards and reports that finance or analytics teams produce. The cadence is monthly or quarterly. The audience is leadership in a review meeting. The output is a presentation.

Operating intelligence is current and forward-looking. It answers three different questions:

1. What is happening right now? Revenue pace, pipeline movement, margin by channel — updated continuously, not monthly.
2. Why is it happening? Root cause visibility: which segment is driving churn, which channel is inflating CAC, which cohort is expanding.
3. What should we do next? Specific, prioritized actions — not a 40-slide deck, but the one thing that moves the most important number this week.

The practical difference is decision velocity. A company running on business intelligence makes strategic decisions monthly. A company running on operating intelligence makes operational decisions weekly. Over 12 months, that compounds into a meaningful advantage in how quickly problems are caught and corrected.

The test of a working operating intelligence system: Can your team answer "what made money last week, what is at risk this month, and what one action will move the number most" in under 5 minutes — without pulling a report?

The 90-Day Build Framework: Overview

The 90-day framework is divided into three phases of equal duration. Each phase has a clear output and a specific success condition. You do not move to the next phase without meeting the previous one.

The sequence matters. Operators who try to build dashboards before auditing data quality produce dashboards that nobody trusts. Operators who try to establish a weekly cadence before defining metrics produce meetings that generate confusion, not decisions. The phases are ordered specifically to prevent both failure modes.

Days 1–30: Building the Data Foundation

The first 30 days have one objective: connect your core data sources and know what you actually have. Most operators skip this phase. They go straight to dashboards. The result is dashboards filled with numbers that contradict each other, which destroys trust in the entire system within weeks.

Week 1: The Data Audit

Before connecting anything, audit what you have. Walk through every system your company uses to run revenue and answer four questions for each:

1. What data does it hold? (revenue, pipeline, customer records, cost data, engagement data)
2. How current is it? (real-time, daily sync, weekly export, manual entry)
3. How clean is it? (duplicate records, missing fields, inconsistent naming conventions)
4. Who owns it? (the person responsible for data quality in that system)

Run this audit in a simple spreadsheet. The goal is not a perfect data catalog — it is a clear picture of your starting point. Most companies discover they have more data than they knew about and less reliable data than they assumed.

Week 2–3: Identify the Minimum Viable Data Stack

Not all data sources are equal. At $1M–$20M ARR, you need three categories of data to build a functional operating intelligence system:

If you have these four categories covered, you have the minimum viable data stack. You do not need more sources in the first 90 days. Additional data sources add complexity before the foundation is stable.

A common question at this stage is whether a data warehouse is required. For most companies at $1M–$10M ARR, the answer is no. Read the full breakdown in data warehouse vs. data lake vs. lakehouse if you are planning the architecture — but do not let that decision block Phase 1. Direct integrations are sufficient to start.

Week 4: Data Quality and Definitions

This is the week most operators skip. It is also the week that determines whether your operating intelligence system will be trusted or ignored.

For each metric you plan to track, write a one-paragraph definition that answers: how is it calculated, which system is the source of truth, how often is it updated, and what counts as an anomaly. This document becomes your metric dictionary.

The two definitions that cause the most confusion in practice are ARR and gross margin:

• ARR: Does it include pilots? Month-to-month contracts? Paused accounts? Define it once. Document it. Then enforce it.
• Gross margin: Are hosting costs included? Payment processing fees? Support team costs? Again — define it, document it, enforce it.

If your CFO and your VP of Sales use different ARR definitions, your operating intelligence system will produce two different numbers for the same question. That destroys credibility immediately. Resolve definitional conflicts in week 4, before you build anything else.

The ETL and data movement questions — specifically whether to use ETL or ELT for your data pipelines — matter more at scale, but even at the $1M–$5M ARR stage it is worth understanding the trade-offs before committing to a specific integration architecture.

Days 31–60: Building the Metric Layer

The metric layer is where data becomes intelligence. You are not building a data warehouse or a reporting tool. You are building a structured set of metrics, organized by decision domain, that tells operators exactly what is happening and flags what needs attention.

Week 5–6: Define Your Operating Metrics

Operating metrics fall into four domains. Each domain answers a different operating question. The full framework for a B2B SaaS or D2C operator looks like this:

Start with five metrics total — one from each of the first three domains and two from whichever domain is most critical to your current business stage. A Series A SaaS company focused on growth should weight pipeline and revenue metrics. A profitable D2C brand focused on efficiency should weight margin and operational metrics.

For a comprehensive breakdown of the metrics that belong in each domain, the RevOps KPI framework covers definitions, calculation methods, and benchmarks for each metric category.

Week 7: Build the Operating Dashboard

The operating dashboard is not a collection of charts. It is a structured view of the five metrics you defined in week 5–6, organized to answer the three operating questions (what is happening, why, what to do) in a single screen.

Three rules for an operating dashboard that gets used:

1. One number per question. Every metric on the dashboard answers a specific question. If a chart does not answer one of the three operating questions, remove it.
2. Status indicators, not raw numbers. Show green/amber/red status against target, not just the raw figure. A pipeline coverage ratio of 2.1x means nothing without context. "Pipeline coverage at 2.1x — below the 3.0x target" triggers a conversation.
3. One owner per metric. Every metric on the dashboard has a named owner responsible for the number and accountable for explaining movement. Without this, dashboards become blame-avoidance tools rather than decision tools.

The most common mistake at this stage is building the dashboard for the analyst, not the operator. Analysts want drill-down capability and data flexibility. Operators want a 30-second status read. Build for the operator. Analysts can build their own views from the underlying data.

Week 8: Run the First Operating Review

Do not wait until Day 60 to run the first operating review. Run it in week 8, even if the dashboard is not perfect. The purpose of the first review is not to get the right answers — it is to identify what questions the system cannot yet answer.

Structure the first operating review as follows:

1. Status read (5 minutes): Each metric owner gives a one-sentence status: on track, at risk, or off track — with the number.
2. Anomaly review (10 minutes): Any metric that moved more than 10% in either direction since last week gets explained. Root cause, not narrative.
3. Decision (5 minutes): One decision gets made as a direct result of the operating review. It gets documented with an owner and a deadline.

The 20-minute structure is intentional. Operating reviews that run 90 minutes become status reports with an audience. Operating reviews that run 20 minutes become decision meetings that people attend because they produce results.

Days 61–90: Building Decision Workflows and Operating Cadence

The final 30 days convert a functioning dashboard and review process into a system that operates largely without manual intervention. This is where an operating intelligence system crosses from useful to essential.

Week 9–10: Define Alert Thresholds

An alert threshold defines the specific condition under which a metric triggers an action — without requiring someone to remember to check the dashboard. Alert thresholds answer a simple question: at what point does a metric move from "worth watching" to "requires immediate response?"

For each of your five core operating metrics, define two thresholds:

• Yellow threshold: The metric has moved outside its normal range. An owner should investigate within 48 hours.
• Red threshold: The metric has crossed a critical boundary. An owner must respond within 24 hours with a documented action.

Example thresholds for a B2B SaaS company:

The thresholds above are starting points, not universal standards. Calibrate them to your specific business stage and growth rate. A company growing at 150% YoY has different alert sensitivities than a company growing at 30% YoY.

Week 11: Establish the Weekly Operating Cadence

The operating cadence is the heartbeat of the system. Without a cadence, operating intelligence degrades into a dashboard that nobody opens. With a cadence, it becomes the decision infrastructure that every leadership team meeting references.

A functional weekly operating cadence for a $5M–$20M ARR company looks like this:

The weekly operating report is distinct from the monthly board report. It is not comprehensive — it is precise. Five metrics, their status against target, one anomaly explanation, and one priority action. If your weekly operating report requires a reading time of more than 3 minutes, it is too long.

Week 12: Adoption and Iteration

The final week of the 90-day build focuses on adoption. A system that exists but is not used produces no value. Adoption at the leadership level requires three things:

1. The system must answer questions they actually ask. If your CEO asks "how is pipeline looking?" every Monday, the operating dashboard must answer that question in under 10 seconds. If it cannot, the dashboard gets replaced with an email chain.
2. The system must be more reliable than the alternative. If the operating dashboard and the finance spreadsheet produce different numbers for the same metric, people will use the spreadsheet. Definitional conflicts from week 4 must be resolved before this stage.
3. The system must produce at least one good decision per week. Document every decision that comes directly from the operating review. After 4 weeks, you will have a track record that builds organizational trust in the system.

The Three Most Common Build Mistakes

Most operating intelligence builds fail for predictable reasons. Understanding these failure modes before you start reduces the likelihood of hitting them.

Mistake 1: Building for Completeness Instead of Decisions

The instinct is to capture every metric. Revenue by cohort, pipeline by rep, CAC by channel by week, gross margin by SKU. The result is a 40-metric dashboard that nobody can read. Operating intelligence requires discipline about what to exclude. The question is not "can we track this?" The question is "what decision does tracking this enable?" If there is no clear answer, do not track it in the primary operating layer.

Mistake 2: Skipping the Data Quality Phase

This is the most common and most costly mistake. Operators who connect their CRM to a dashboard tool in week 1 without auditing data quality typically discover — 3 weeks later — that 30% of deal records are missing close dates, the revenue figure is double-counting invoices, and the CAC calculation includes organic traffic attributed to paid. The dashboard is live. Nobody trusts it. The build effectively restarts.

The standard advice is to skip the data quality work to move faster. The standard advice is wrong. Four weeks on data quality saves 4 months of credibility repair.

Mistake 3: No Decision Owner for Each Metric

A dashboard without owners is a status display, not a decision system. Every metric must have one named person who is responsible for explaining movement and accountable for driving corrective action when a threshold is breached. Committees do not own metrics. Individuals do. If you cannot name one person for each metric, your operating structure is the problem — not the intelligence system.

Architecture Decisions: What to Build vs. Buy

Operating intelligence requires decisions about architecture at two points: data movement and presentation. Both have build-versus-buy dimensions that operators need to resolve before starting the 90-day build.

Data Movement Architecture

For most companies at $1M–$10M ARR, there are three architecture options:

1. Direct integrations: Each source system connects directly to the presentation layer (dashboard tool). No warehouse. Fastest to deploy. Limited cross-source joins and historical depth. Appropriate for $1M–$5M ARR.
2. Centralized data warehouse: All sources sync to a single warehouse (BigQuery, Snowflake, Redshift). Full join capability, historical depth, governance controls. Requires data engineering resources. Appropriate for $5M+ ARR with analyst capacity.
3. Reverse ETL layer: Data moves from the warehouse back to operational tools (CRM, customer success platforms) to trigger actions. The reverse ETL pattern enables automated workflows that close the loop between intelligence and action.

The architecture choice determines how much of the operating intelligence system is automated versus manual. A direct integration setup requires manual alert monitoring. A warehouse-plus-reverse-ETL setup automates the alert-to-action workflow.

Presentation Architecture

The presentation layer is where operating intelligence becomes visible. Options range from embedded BI tools (Looker, Metabase, Tableau) to dedicated operating intelligence platforms. The key criterion is not feature richness — it is whether the tool produces the 20-minute operating review without a data analyst preparing a deck.

Most BI tools are built for analysis, not for operating cadence. They excel at ad-hoc exploration but require significant configuration to produce a consistent, automated operating review. That configuration work is non-trivial and typically requires dedicated analyst time each week to maintain.

How Fairview Handles the Operating Intelligence Build

Fairview is built specifically for the operating intelligence use case described in this guide. Rather than requiring operators to stitch together a BI tool, a data warehouse, and a separate alerting system, Fairview connects directly to the source systems that B2B SaaS and D2C companies already use and surfaces the operating metrics that matter without requiring a data engineering team to maintain the pipeline.

The Data Connection Layer connects to HubSpot, Salesforce, Pipedrive, Stripe, QuickBooks, Xero, Shopify, Google Ads, and Meta Ads — covering all four categories of the minimum viable data stack described in Phase 1 of this framework. Connection does not require an ETL pipeline or a data warehouse. The integrations are direct and maintained by Fairview.

The Operating Dashboard surfaces the four metric domains — revenue health, pipeline health, margin health, and operational health — in a single view, with status indicators against target and alert thresholds configurable to each company's specific numbers. The Pipeline Health Monitor tracks coverage ratios, deal velocity, and stage conversion without requiring manual CRM exports. The Margin Intelligence module calculates contribution margin by customer segment and channel without requiring a finance team to run the calculation manually each week.

The Weekly Operating Report is automated. Each Friday, Fairview compiles the five-metric summary described in Phase 3 of this framework — current status, week-over-week movement, threshold alerts, and one priority action — and delivers it to the leadership team. The operating review meeting runs from the dashboard, not from a prepared deck.

The Next-Best Action Engine surfaces specific recommended actions when a metric breaches a threshold — not just an alert that something is wrong, but a prioritized recommendation for what to do about it. This is the decision-workflow layer described in Phase 3 of this guide.

For companies at the $1M–$20M ARR stage described in this guide, Fairview replaces the architecture decision entirely. There is no warehouse to configure, no ETL pipeline to maintain, and no analyst required to prepare the weekly operating review.

Measuring the Success of Your Operating Intelligence System

After 90 days, the operating intelligence system should be measurable against three outcomes:

1. Decision velocity: How many operating decisions were made directly from the operating review in the last 30 days? Target: at least 4. If fewer than 4 decisions were made, the review is producing status updates, not decisions.
2. Time to detection: When a metric breached a threshold in the last 30 days, how quickly was it detected? Target: same day for automated alerts, within 48 hours for manual review. If problems are discovered in the monthly board deck rather than the weekly operating review, the system is not functioning.
3. Forecast accuracy: Is your revenue forecast for the current quarter within 10% of actuals at Day 60 of the quarter? A working operating intelligence system should improve forecast accuracy over time, because leading indicators (pipeline coverage, deal velocity) are visible and monitored consistently.

The research on this is unambiguous. According to Forrester research on revenue operations, companies that deployed integrated RevOps intelligence grew revenue three times faster than those that did not. The mechanism is not magic — it is decision velocity. More decisions, made faster, from better information.

A working operating intelligence system does not make a company's strategy better. It makes the execution of existing strategy visible — and visible execution gets corrected, improved, and compounded over time.

Frequently Asked Questions

What is an operating intelligence system?

An operating intelligence system is a structured combination of connected data sources, a defined metric layer, and decision workflows that gives operators real-time visibility into what is making money, what is leaking margin, and what to do next. It differs from traditional business intelligence in that it is action-oriented and forward-looking, not just historical reporting. The three outputs of a working operating intelligence system are: current status across revenue, pipeline, and margin; root cause explanations for anomalies; and specific recommended actions.

How long does it take to build an operating intelligence system?

A functional operating intelligence system can be built in 90 days when the work is scoped correctly. Days 1 to 30 establish the data foundation: connecting sources and auditing data quality. Days 31 to 60 build the metric layer: defining KPIs, creating dashboards, and running the first operating review. Days 61 to 90 wire in decision workflows and establish a weekly operating cadence. Companies that skip the data quality phase in weeks 1–4 typically extend the timeline by 2–3 months due to credibility problems with the resulting dashboards.

What is the difference between operating intelligence and business intelligence?

Business intelligence is retrospective. It answers "what happened last quarter?" with dashboards and reports produced monthly or quarterly. Operating intelligence is current and forward-looking. It answers "what is happening right now, why is it happening, and what should we do next?" — with a weekly cadence and specific recommended actions. BI is a reporting function. Operating intelligence is a decision function. Both have value; they serve different purposes in the organization.

What data sources do I need to build an operating intelligence system?

The minimum viable data stack for a B2B SaaS or D2C company requires four categories: a revenue source (Stripe, Chargebee, or Shopify), a CRM or pipeline source (HubSpot, Salesforce, or Pipedrive), a financial system (QuickBooks or Xero), and one acquisition cost source (Google Ads, Meta Ads, or HubSpot Marketing). These four categories cover revenue health, pipeline health, margin health, and acquisition efficiency — the complete operating picture. Additional sources can be added in later iterations after the foundation is stable.

Do I need a data warehouse to build an operating intelligence system?

Not at the $1M–$10M ARR stage. Direct integrations between your source systems and your presentation layer are sufficient to build a functional operating intelligence system. A data warehouse adds value above $10M ARR when data volume, cross-functional complexity, and analytical depth require centralized storage and transformation. The architecture decision should follow business need, not precede it. Many companies spend 6 months implementing a data warehouse before they have defined which metrics they need — and end up with infrastructure that does not serve the operating intelligence use case they originally intended.

What metrics should an operating intelligence system track?

Start with five metrics across four domains: one revenue health metric (ARR or MRR growth rate), one pipeline health metric (pipeline coverage ratio), one margin health metric (gross margin percentage), and two metrics from whichever domain is most critical to your current stage. For growth-stage companies, add pipeline velocity. For efficiency-stage companies, add CAC payback period. The goal is not comprehensiveness — it is five metrics that a COO or founder can read in 30 seconds and act on immediately.

Key Takeaways

• Operating intelligence is an architecture problem, not a data problem. Most companies have the data. The gap is the connection layer, the metric definitions, and the decision workflows that convert data into action.
• The 90-day framework is sequential for a reason. Data foundation before metric layer. Metric layer before decision workflows. Skipping phases does not accelerate the build — it guarantees a rebuild later.
• Five metrics beat forty. An operating dashboard with five well-defined, well-owned metrics produces more decisions than a 40-metric dashboard with no owners and no thresholds.
• Data quality is not optional. The data audit in weeks 1–4 determines whether your operating intelligence system gets used or ignored. Invest in it.
• The weekly operating review is the output. Every element of this framework — the data connections, the metric definitions, the alert thresholds — exists to enable a 20-minute weekly review that produces one decision. If the review does not produce decisions, the system is not working.

Building an operating intelligence system is not a technology project. It is an organizational commitment to operating on current information rather than historical reports. The 90-day framework gives structure to that commitment. The result is an organization that finds problems before they compound, allocates resources to what is working, and makes operating decisions at the speed the business requires.

---