About 19.3% of franchisees control 58.8% of all franchised locations. That number stopped surprising me once I understood what it actually means operationally: a relatively small group of people learned to run location-level accountability at scale, and everyone else is still figuring out how.
The ones who figured it out did not get there by working harder. They made a series of decisions about visibility, and each decision either compounded or collapsed on the one before it.
Here is the decision tree. Every multi-unit operator I have talked to hits each fork in roughly the same order.
Fork one: central control or distributed control?
The first fork comes around location three or four. The operator notices that each location has started interpreting the operating standard in its own way. Staff at one unit do the morning close-out differently than staff at another. Speed-to-lead varies by who happened to be at the front desk. The brand is technically the same. The operations are not.
The instinct is to centralize everything: one ops director watching all locations, one shared inbox, one shared team. Some operators go this route. What they find is that local problems take longer to surface because every signal has to travel up through the central layer before anyone sees it. By the time financial results show a problem, the problem is already months old. The people who know what is happening (the staff at the unit) do not have accountability for the number. The person with accountability (the ops director) does not have proximity to the cause.
The instinct to distribute everything also fails. Eleven location managers running eleven independent operations without a shared standard and a shared view produce eleven versions of the brand, and the franchisor cannot tell which units are building equity and which are eroding it.
The answer is not central or distributed. The answer is distributed accountability with centralized visibility. Each location runs its own operation. Corporate sees everything.
Fork two: one giant spreadsheet or one system per location?
The visibility problem drives operators to the second fork.
One option is to pull everything into one reporting layer: a spreadsheet, a BI dashboard, a weekly roll-up call where each unit manager reports their numbers to the ops director. Operators with five locations can run this. Operators with ten start to feel the seams. The data is always a few days old. The context is never in the spreadsheet. The number drops, but the spreadsheet cannot tell you why.
The other option is to give each location its own system and accept that you will have ten different sources of truth you can never actually compare.
Neither fork leads anywhere good on its own.
What the multi-unit operator actually needs is a third option that does not exist in most systems: each location runs its own full accountability chart with its own seats, its own metrics, and its own operating cadence, while a portfolio layer above those locations aggregates their KPIs into shared super-metrics the operator can actually act on.
That is what OTP's portfolio feature is.
What the portfolio actually does
A portfolio in OTP is a parent organization that groups several member organizations under one roof. Each member org is a full OTP chart: a hybrid of human seats and AI agent seats, each seat with a clear role and a set of KPIs on a shared scorecard. The portfolio rolls those KPIs up into super-metrics that live at the corporate level.
For a ten-location operator, the structure looks like this. Each location is a member org. Each location runs its own chart. At location A, the seats might include a human general manager, an Arin agent handling speed-to-lead coaching for the calling team, a Dash agent aggregating ad performance, and a Pulse agent flagging clients who have gone quiet. At location B, the same structure, tuned to the local numbers and local staff.
The portfolio above those ten orgs sees one view: AUV rolling across all units, same-store trends by location, lead volume by unit, show rate by location. When location C's show rate drops, the ops director sees it in the portfolio view before the monthly P&L makes it legible. That is the visibility lag problem, structurally solved.
Fork three: consistency or autonomy at the unit level?
The third fork is the one that breaks most multi-unit systems, and it is the one that took me longest to understand clearly.
Franchises sell brand consistency. The franchisee pays for the right to operate under a proven system. The franchisor's job is to make sure the system holds. But unit-level managers need enough autonomy to respond to local conditions. The two pulls are real, and they are in genuine tension.
In most systems, the way this tension resolves is through documentation: an operations manual, a training program, periodic audits. None of those tools stop a unit from drifting between audits. The brand goes out of compliance "without corporate realizing it," as one franchise consultancy put it. By the time the audit surfaces the drift, the damage is already in the customer base.
OTP's presets feature is the structural answer. The portfolio sets the default chart configuration for all member orgs: which seats exist, which metrics those seats track, what the targets are. Member orgs inherit those defaults. Corporate can lock the ones that are non-negotiable for brand consistency. A location manager can adjust the settings that are left open for local discretion, but cannot touch the locked ones.
The operating standard is set once, at the portfolio level, and it propagates automatically to every location that joins the portfolio. When the standard changes, the change moves through the same channel. The brand stays coherent without requiring an audit cycle to enforce it.
Fork four: what happens when a location underperforms?
The fourth fork is where the system either earns its keep or falls apart.
In a visibility-lagged system, underperformance is a surprise. A location misses its numbers, the ops director investigates, months of context has to be reconstructed from memory and stale data. The cause is usually attributed to staffing or local market conditions, which are the explanations that are hardest to disprove because they are impossible to compare across locations.
In a portfolio view, underperformance is not a surprise. The super-metric for that location has been trending below the portfolio average for weeks. The ops director has been watching it. When the conversation happens, it happens with data: this location's Arin agent is logging the same call volume as the other locations, but the booking rate is lower. This location's Dash agent is showing higher cost-per-lead than the portfolio median. The underperformance is multi-causal, but the causes are visible and sortable. The conversation is about which seat's number to address first, not about what went wrong last quarter.
Location-to-location benchmarking is not a luxury feature for multi-unit operators. It is the core of the job. It is how you know whether underperformance is a local problem or a system problem, whether the fix belongs to the unit or to the portfolio. Without it, every underperforming location gets the same explanation and the same intervention, regardless of the actual cause.
The picture at ten locations
At Sneeze It, we do not run a franchise. We work with multi-location fitness and wellness brands as advertising partners. But the operating structure is the same problem. We have Radar running as chief of staff, surfacing what needs my attention each morning. We have Tally pushing KPI values to the scorecard so the numbers are always current without anyone manually updating a spreadsheet. We have Dirk tracking the sales pipeline, Pepper managing email triage, Bogdan holding COO accountability on his own rows, Janine holding the financial rows on hers.
Each seat does one job. Each seat reports one set of metrics. The scorecard tells me, on any given Monday, which seats are green and which need a conversation.
That structure is exactly what a ten-location portfolio looks like, scaled out. Each location runs its own version of the chart. The portfolio above it sees all the numbers in one place. A location's Arin agent coaches the calling team to improve speed-to-lead. The portfolio super-metric for speed-to-lead across all locations reflects the change within the same reporting cycle. Corporate does not have to wait for the quarterly review to see whether the coaching worked.
The agents carry the operational work. The humans are free for the work that matters.
The two things that make this work at scale
The first is that each member org in the portfolio is a full org, not a data feed. A location in OTP is not just a row in a table that reports numbers upward. It is a chart with seats, with accountability, with its own operating cadence. The portfolio aggregates those charts. It does not replace them.
This distinction matters because it is the one that keeps local accountability real. If each location is just a reporting node, the local team has no skin in the numbers. They file the report and move on. If each location runs its own chart with its own seats accountable for their own rows, the local team owns the outcomes, and the portfolio view gives corporate a way to see those outcomes without waiting for the report to be filed.
The second is that presets do the brand-consistency work structurally rather than procedurally. The operating standard is not a document you hope people read. It is the default chart configuration every new location inherits the moment it joins the portfolio. The lock on the non-negotiable settings means that drift is impossible for the things that matter most, and local flexibility is preserved for everything else.
A note on where this feature is right now
OTP's portfolio feature is available now in early access, gated behind the Labs toggle at /settings/labs. It is the enterprise tier. I am actively building the franchise series around it because the multi-unit operator problem is the clearest application of the portfolio architecture, and I want to get the design right with real operators before it goes broader.
If you run multiple locations and the four forks above describe what your Monday mornings feel like, write to me at dsteel@orgtp.com. I want to hear where visibility breaks for you specifically.
See the live chart
From any OTP org with portfolio access, you can query the current member orgs, their linked super-metrics, and the preset configuration that flows down to each location.
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 the portfolio view for sneeze-it, including any super-metrics and which member orgs are linked."
What comes back shows you the exact structure a multi-unit operator would see: the parent portfolio, the member orgs beneath it, and the super-metrics that aggregate across all of them. That is the ten-location view, visible in a single query.
Series: Franchise. Post 22 of an in-progress series. Related: A franchise is a portfolio