Join OTP the operating platform for people and AI agents
Back to Blog
Founder Notes 2026-06-21 · David Steel

Franchise reporting is always late for five structural reasons, and each one has a fix

The phrase I hear from multi-unit operators more than any other is: "by the time we see a problem in the numbers, we've already lost months."

That is not a data problem. It is a structural problem. The reporting is late because the org is built in a way that makes lateness inevitable. Fix the structure, and the lateness goes away.

About 19.3% of franchisees control 58.8% of all franchise locations today (FRANdata/IFA 2026). The fastest-growing tier, operators with 50 or more units, grew 118% from 2010 to 2018. Those operators are running a portfolio business. Their unit economics are good. Their visibility is not. The lag between a location going soft and the corporate team knowing about it is where value leaks.

Here are the five structural reasons franchise reporting is always late, and what the fix actually looks like for each one.

1. Each location produces its own numbers in its own format

When your locations each build their own weekly report, you get twelve variations of the same report. Different column names. Different time ranges. Different definitions of "lead." By the time someone at the corporate level consolidates those into a single view, days have passed and the consolidated number is already stale.

The fix is a shared chart standard. Every location's scorecard runs the same KPI definitions, the same time frames, the same calculation method. When you are the franchisor, you set those standards once. Every location inherits them. You do not negotiate KPI definitions with individual units.

This is what presets do in OTP's portfolio feature, which is available now in early access for enterprise orgs. The portfolio sets the standard chart. Each member org (each location) inherits it. The franchisor can lock the preset so units cannot redefine what "appointment rate" means locally. The operating standard becomes structural, not a policy document nobody enforces.

2. The people generating reports are not the people who need to act on them

At most multi-unit operators, the person who pulls the unit's weekly numbers is an operations coordinator or a location manager. The person who needs to act on those numbers is a regional director or a portfolio ops lead. There is a translation step in the middle, and that translation step takes time and loses context.

The fix is removing the middle step by making the source data the report. Instead of a person pulling numbers and packaging them for someone else, the scorecard updates as the underlying activity happens. The ops lead reads the scorecard directly. No translation. No lag introduced by the handoff.

At Sneeze It, Tally is the seat that handles this. Tally's job is to push KPI values from the places where work actually happens into the shared scorecard, so that the number on the chart is the number in the source. Radar reads those values during every briefing. The briefing is live because Tally keeps the values current.

For a franchise system, the equivalent design is a seat at each location whose job is exactly this: keep the scorecard current. That seat can be a human or an agent depending on how data-intensive the location's reporting is. The key is that someone holds the role, not that a human is doing it manually.

3. Underperformance is invisible until it compounds

A location that is trending down 8% over six weeks does not look like a crisis in week two. It looks like noise. By week six, when the trend is clear, the location has already burned through two months of slower performance. The financial reports confirm what the trend data already showed, just too late to do anything about it.

The fix is tracking the trend, not just the current number. A scorecard that shows a KPI, a target, and a trend arrow is more useful than a scorecard that shows only the current value. The question is not "where are we" but "where are we going and how fast."

This is also where location-to-location benchmarking changes the conversation. When Unit 7 is at 73% of its appointment target and Unit 12 is at 102%, the question becomes "what is Unit 12 doing that Unit 7 is not," rather than "is Unit 7 in trouble." The benchmark makes the gap visible before it becomes a crisis. This is one of the explicitly named requirements for multi-unit operators, and it is one of the most powerful things a portfolio view delivers.

OTP's super-metrics are designed for exactly this: a KPI on the portfolio that aggregates member-org KPIs into a system-wide number. A franchisor can hold a system-wide appointment rate as a super-metric while each location holds its own. When the system-wide number moves, the portfolio view tells you which locations moved it.

4. The call center or lead-response layer is invisible to corporate

For fitness, med spa, home services, and other service franchises, speed-to-lead is often the most important operational KPI. A location that responds to leads within five minutes books at a completely different rate than a location that responds in two hours. This is not theory. It is the kind of performance gap that compounds across 20 or 50 locations into millions of dollars of missed revenue over a year.

But speed-to-lead at the unit level rarely makes it into the corporate report. It is not in the financial statement. It is buried in a call center tool or a CRM that nobody at the portfolio level has access to. By the time the booking rate drops enough to show up in the unit's revenue, the problem has been running for months.

The fix is making call center performance a first-class KPI on the location scorecard, which means it rolls into the portfolio's super-metrics alongside revenue and headcount.

At Sneeze It, Arin is the seat that owns call center performance. Arin reads the appointment data daily, tracks speed-to-lead against a 30% conversion target, and surfaces gaps before they compound. That seat belongs on every location's chart. And when it does, it feeds into a portfolio view where a corporate ops lead can see which locations are winning on speed-to-lead and which are leaking leads before they ever become appointments.

5. There is no seat accountable for the portfolio view itself

This is the deepest reason franchise reporting is always late. There is no single person whose job is to hold the system-wide view current. The regional directors each hold their region. The CFO holds the consolidated financials. The ops coordinator holds the weekly round-up. Nobody holds the live cross-location view.

When nobody holds it, it is always one step behind the people who do hold something. The financial report is current. The regional director's notes are current. The cross-location view is assembled on demand, which means it is assembled after the fact.

The fix is adding a seat whose job is the portfolio view. At Sneeze It, Radar holds this. Radar's job as chief of staff is to hold the current state of all the seats and all the numbers, and surface the picture at the start of every day. Radar does not generate the data. Radar compiles it from the seats that own it, Dash for analytics, Tally for scorecard values, Crystal for project delivery, Dirk for pipeline, Pulse for retention, and Pepper for client communication.

For a franchise system, the equivalent is a corporate chief-of-staff seat whose job is the portfolio view. That seat surfaces the system-wide scorecard every morning before the ops team starts their day. The ops team arrives at a briefing, not at a blank spreadsheet they have to build before they can think.

When Dirk, Nick, or Pulse are generating insights at the location level, those insights feed upward because someone at the portfolio level is reading the output. The connection between the location's activity and the corporate view is structural. It does not depend on a coordinator remembering to pull the report.

What this looks like as a system

The five fixes are not independent. They form a stack.

A shared chart standard (fix 1) makes it possible to remove the translation layer (fix 2). Trend-and-benchmark visibility (fix 3) makes the call-center layer worth tracking (fix 4). And the portfolio seat (fix 5) is what ties everything together into a view that is current, comparable, and actionable.

OTP's portfolio feature, available now in early access for enterprise orgs, is where this stack lives as a product. Each location runs its own org with its own seats and its own scorecard. The franchisor org is a portfolio that groups the locations, holds the presets that standardize the chart across every member, and shows the super-metrics that roll up the unit-level numbers into system-wide visibility.

The goal is simple to say and hard to build without a structural fix: let the franchisor see a problem at one location before that location's manager does. Not after the monthly financials. Not after the regional director's quarterly review. Before.

The mission underneath all of this is the same one we run at Sneeze It: let agents carry the operational work, so people are free for the work that matters. In a franchise system, the work that matters is coaching underperformers before they become failures, replicating what the high performers are doing, and making the operating standard real rather than theoretical.

The reporting lag is what gets in the way of all three. Fixing the structure is how you close it.

See the live chart

You can ask the OTP MCP to show you what a portfolio org looks like: which orgs are grouped under a portfolio, what super-metrics are defined, and how presets are structured across member orgs.

In Claude Desktop or Cursor or any MCP client, add this block:

"otp": {
  "command": "npx",
  "args": ["-y", "@orgtp/mcp-server"]
}

Restart the client. Then ask: "Use OTP to show me how a portfolio org groups its member orgs and what super-metrics are defined at the portfolio level."

What you get back is the actual data model, not a diagram. That is the difference between a product description and a product you can interrogate.

DS
David Steel

Founder of OTP. Runs an AI agent army at a digital agency. Building OTP because nobody else seems to be building it. Notes from inside the build, not from the conference circuit.

More about David →

More posts on the blog index.

All posts