Layer 2: Data, or How We Centralize Revenue and Ops Metrics in Three Weeks

When leadership asks how many active clients you have, the answer should take 30 seconds. In most mid-market firms it takes 20 minutes. Someone opens the CRM, then the accounting tool, then a spreadsheet the ops lead maintains by hand, then the PM tool to confirm which of those clients are actually in delivery this week. By the time the number lands in the room, the meeting has moved on.

This post is about the second layer of the AIOS, and about the three-week technical plan we use to retire that 20-minute reconciliation. The goal is not a new data warehouse, and not a migration. The goal is one readable place that can answer the five operating questions leadership actually asks, on demand, from one interface.

The centralization problem, stated precisely

Every mid-market firm we work with has the same topology. Revenue lives in the accounting tool. Pipeline lives in the CRM. Operations live in spreadsheets. Client delivery lives in the PM tool. Cash lives in the bank feed. Support lives in the ticketing system. Each of those systems is the correct home for its own data. None of them has a view of the others.

The cost is not that any one number is wrong. The cost is that every leadership question requires three to six tabs and a mental reconciliation. "How many active clients do we have" is four tabs. "What is quarter-to-date revenue net of refunds" is three tabs and a spreadsheet.

The reconciliation itself is where the damage happens. Each tab gets opened by a different person, on a different cadence, with a different definition of "active" or "closed" or "revenue." Leadership ends up debating definitions instead of making decisions. The real cost of this pattern has numbers attached to it, but the qualitative version is simpler: the firm is paying a tax on every question it asks itself.

Layer 2 removes that tax. It does not remove the underlying tools.

Why we do not migrate

The first instinct most firms have is to consolidate the tools. Move everything onto one platform. Replace the CRM, the accounting tool, the PM tool, the spreadsheets, with a single system of record.

We do not do that, and we recommend against it. A platform migration is a twelve-to-eighteen-month project that touches every workflow, breaks every integration, and retrains every user. It has its own failure modes, and it rarely solves the centralization problem anyway. A year later there is still a spreadsheet, because there is always a spreadsheet.

Our rule at this layer is borrow before you build. The CRM already has the pipeline. The accounting tool already has the revenue. The bank feed already has cash. What is missing is a layer above them that can read from all of them and present the result as one thing.

That layer is what we install in Layer 2. It reads. It does not write back. It does not replace. The CRM stays the CRM. The accounting tool stays the accounting tool. Leadership gets one place to ask questions, and the underlying systems keep running the way they already do.

This is the same principle we apply across how we sequence the 5 layers. Install in layers, not in leaps. A read layer above existing tools is a layer. A platform migration is a leap.

Week 1: inventory and access

The first week of a Layer 2 install is not technical. It is reconnaissance.

We map every system of record. For a typical mid-market firm this is six to nine systems: CRM, accounting, banking, PM, support, HR or payroll, one or two function-specific tools (a marketing platform, a billing platform), and the spreadsheets that matter. Spreadsheets get the same treatment as software here. If a finance lead maintains the utilization model in Google Sheets and leadership cites it in monthly review, it is a system of record.

For each source we capture four things.

First, what lives there that nothing else knows. The CRM has the pipeline stage definitions the sales team actually uses. The accounting tool has the revenue recognition rules. The spreadsheet has the ops lead's mental model of capacity. These are the facts the centralized layer has to respect, because the firm already trusts them.

Second, the refresh cadence. Some sources update in real time. Some update nightly. Some update when a specific person remembers to update them. A read layer pulling from a source updated weekly and a source updated in real time has to be honest about which is which.

Third, data quality. Does the CRM have 2,000 dead leads that no one has pruned in three years? Does the PM tool have projects still marked "active" that closed in 2024? We note these. We do not fix them at this layer.

Fourth, API access and credentials. Most modern business tools have APIs or at least scheduled exports. We confirm which method each source supports, provision read-only credentials, and name an owner. The owner is the person we go to when credentials rotate or when a schema changes. This sounds mundane. It is the single most common place Layer 2 projects stall.

By the end of week 1 we have a source map, a set of read-only credentials in a secure store, a named owner for each source, and a short memo on the data quality issues leadership should know about before they start trusting the numbers. If any of those are missing, we do not start week 2. The Blueprint phase catches most of these gaps, but Layer 2 is where they become concrete.

Week 2: pull and normalize

Week 2 is the pipeline work. For each source we build a scheduled job that pulls data into a centralized store. Daily schedule is the default. Some sources justify hourly. Almost none justify real time.

We describe the store generically because the right implementation depends on the firm. For some installs it is a managed relational database. For some it is a reporting layer built into an existing tool, extended with additional sources. For some it is a set of scheduled exports landing in a shared location, read by a thin query layer. What matters is not the product. What matters is that every metric has one canonical home, and that home is readable from one place.

The harder work is the normalization. Each source has its own schema, its own IDs, its own definition of a client, its own definition of revenue. The centralized store needs a shared schema with five core entities: clients, revenue, work-in-flight, cash, and pipeline. Every incoming record from every source maps to one of these.

The mapping is where the firm's actual operating model gets encoded. "Client" in the CRM might mean a logo. "Client" in the accounting tool might mean a billing entity. "Client" in the PM tool might mean an engagement. Leadership has to pick one definition and live with it. This is usually a 30-minute conversation that saves six months of disagreement downstream. We facilitate it. We do not decide it.

Once the mapping is written down, the pipelines run. Each source feeds the normalized schema on its declared cadence. The store becomes the single place that can answer a question about clients, revenue, work-in-flight, cash, or pipeline, without anyone opening a second tab.

We do light validation here. Row counts against source. Spot checks on known records. A handful of reconciliation queries against the source of truth for each entity. We do not try to build a full data quality framework. That is a Layer 3 and Layer 5 concern. MIT Sloan Management Review on scaling analytics is a useful reference for the version of this problem that lives one layer up.

Week 3: the read layer

Week 3 is the interface. The centralized store is only useful if leadership can actually use it.

The read layer is a single place where the five operating questions get answered. Active clients. Revenue quarter-to-date. Pipeline. Work-in-flight. Cash position. For each question there is one query, one result, and a visible timestamp showing when the underlying data last refreshed.

The specific form of the interface varies. For some firms it is a dashboard. For some it is a morning email. For some it is a chat interface layered on top of the normalized store. What matters less is the form and more the acceptance bar: leadership can answer any of the five questions from one place in under 30 seconds. The acceptance bar for a layer is how we decide Layer 2 is actually installed and not merely built. If the 30-second test fails, the layer is not done, regardless of how much of the architecture is in place.

We keep the interface narrow in week 3. Five questions. Not fifty. The temptation is to ship a 40-chart dashboard that answers every question anyone has ever asked. That work is Layer 3. A narrow Layer 2 that answers five questions correctly is worth more than a broad one that answers fifty with footnotes. Bain's operations writing on decision-grade information makes the same argument in more general form.

By the end of week 3, leadership stops reconciling tabs. The 20-minute question becomes a 30-second question. Nothing underneath has been replaced. The CRM, the accounting tool, the PM tool, and the spreadsheets keep running. The tax has been removed.

The honest constraints

Three weeks is the happy path, and the happy path is not universal.

It assumes three things. The Context layer is installed, so the business model, team shape, and operating cadence are already written down. Every source of record has an API or a scheduled export. Leadership has named an owner for each source and is willing to commit those owners to the project for the duration.

If any of those three assumptions is wrong, three weeks becomes six. A firm without Layer 1 will spend two weeks debating what "client" means before we can normalize anything. A firm with a source that has no API and no export (this is rarer than it used to be, but still real, especially in regulated verticals) will spend an extra week building a scrape or an upload path. A firm where leadership cannot name owners will spend week 1 in meetings instead of in the work.

Two more things this layer does not do.

It does not fix data quality. If the CRM has 2,000 dead leads, the centralized layer will show 2,000 dead leads. Faster and more clearly, which is useful, but cleaning them is a separate engagement. Leadership sometimes assumes centralization will reveal a cleaner underlying reality. It reveals the reality that is already there.

It does not build intelligence on top of the numbers. The morning brief, the variance detection, the narrative synthesis, those are Layer 3. They need Layer 2 to be trustworthy first. Installing Layer 3 on a shaky Layer 2 teaches the firm that the AIOS is wrong, and that lesson is expensive to unlearn. HBR's work on technology and analytics programs that survive the first year is consistent with what we see on the ground.

Three weeks on the happy path. Six weeks when assumptions miss. Zero weeks if the firm is not ready for a layer install yet, in which case we say so and we do not start. That honesty is part of how we work.

If you are wondering whether your firm is in the three-week bucket or the six-week bucket, that is what the Fit Check is for. It tells us, and it tells you, before anyone commits to a timeline. A Blueprint goes one step further and writes down the exact source map, the exact normalization schema, and the exact acceptance bar your Layer 2 install will be measured against.

Three weeks only works because we know, before week 1 starts, what "done" looks like.

-Jeremy