Group-versus-rest: how the cycle-time comparison is computed

What this article is for

The Operations hero opens on one number: your network's median cycle time, in days, next to a pill that reads something like "P34 (lower is better)." That pill is not a static label. It is the live output of a calculation engine that hashes your network's operators, pulls every eligible operator outside your network, reduces each business down to one honest value, checks that neither side is thin enough to be identifying, and only then computes where your network sits. This article is the plumbing underneath that one comparison: what "group" and "rest" actually mean, how the percentile gets built, and why the hero sometimes shows a plain sentence instead of a number.

This article covers the cycle-time comparison specifically. It does not re-walk the whole Operations page row by row, that is covered in Operations: your network's process health at a glance, and it does not re-explain the hero's layout, tones, and secondary tiles, that is covered in The cycle-time hero: how your network compares to the industry. Read this one when you want to know exactly how "P34" or "Cycle time appears as members share job data" came to be true.

Group-versus-rest, not group-versus-industry-average

The name matters. This comparison is group-versus-rest: your network's own operators on one side, and every other eligible operator on the platform, network-wide, on the other. It is not your network measured against a single published industry-average figure sourced from an outside report. The "rest" side is built fresh, from the same underlying operator data every other network on Verinode contributes, filtered down to the operators eligible to stand in for it (more on that filter below).

Two consequences follow from that:

• Your own network's rows are never subject to an eligibility check. It is your own network's data being read back to you, not a peer's, so every one of your network's qualifying operators counts.
• The "rest" side changes as the platform's overall operator base changes. As more operators outside your network start reporting cycle time, the comparison your network is measured against gets broader and more representative on its own, with nothing for you to configure.

Step 1: hashed joins, how "your network" gets assembled

Your network's roster comes from your own group's membership table, a plain list of operator records. Verinode never joins that roster directly against the cross-network intelligence tables using those raw identities. Every operator identity is run through a one-way cryptographic hash before it ever touches the intelligence schema, and the hashed form is what actually gets matched against the peer cycle-time data. The hash only runs one direction: given an operator you can compute their hash, but the intelligence tables carry no path back from a hash to a name, a login, or a business record. HQ's server never queries the intelligence layer using anything but a hash.

Once your roster is hashed, the engine reads every relevant row and splits it two ways: rows whose hash matches a member of your roster (always counted, no eligibility gate), and rows whose hash does not (only counted if that hash also clears the eligibility allow-set in Step 2).

Step 2: the eligibility allow-set, the demo and real chokepoint

Verinode maintains a separate showcase world for onboarding and product demonstrations, entirely apart from the live network of real, contributing businesses. Every candidate row on the "rest" side has to pass a single allow-set check before it counts at all: it has to have matured into benchmark eligibility, and it has to belong to the same world, demo or real, as your own network.

Which world your network belongs to is fixed by how your account was set up. A real franchise network's rest-of-industry comparison is only ever built from other real, matured operators, never from showcase data, even if the real peer pool is still thin. A demo or evaluation network sees the reverse: only demo peers, so a sales walkthrough never accidentally surfaces a real operator's business figures.

This check is a single chokepoint, and it fails loud rather than fails open. If the allow-set itself cannot be read for any reason, the engine treats the rest-of-industry side as empty for that request rather than falling back to an unfiltered pull of every operator on file. A real network never sees a comparison quietly built from demo data, even in a degraded state. The honest failure is a "not enough data yet" read, never a wrong one dressed up as real.

Step 3: one value per operator, before any percentile gets computed

Cycle time is a job-grain metric: the underlying table carries one row per completed job, not one row per operator. A high-volume location can close hundreds of jobs while a smaller one closes a handful, and if the engine pooled every job row straight into a percentile calculation, that high-volume location would quietly dominate a number that is supposed to represent "the typical job cycle."

Before computing anything, the engine collapses every operator down to exactly one figure: that operator's own median cycle time across their jobs. Only after that reduction does it sort the resulting one-value-per-operator list and compute percentiles. This applies identically to both sides, your network's own operators and the eligible rest-of-industry operators. One operator, one vote, regardless of how many jobs any single operator has closed.

Step 4: the percentile, and why lower is the good direction here

Once each side is reduced to one median cycle time per operator, the engine computes three figures per side, the 25th percentile, the median, and the 75th percentile, of those per-operator values. The hero surfaces the group side's median as the headline number. It does not currently display the P25/P75 spread or the rest side's own P25/P75 on this page, only the single group median headline and the industry median quoted in the subtext line underneath it.

The percentile pill is a different calculation: it is where your network's median cycle time lands within the rest-of-industry distribution, expressed as a number from 0 to 100. Concretely, it is the share of eligible outside operators whose own median cycle time is at or below your network's median.

Because a shorter cycle time is the better outcome, this cuts against the usual percentile intuition. A low percentile number here is good news: it means most of the outside cohort is running slower than your network, so your network sits near the fast end of the distribution. A high percentile number means the opposite, more of the outside cohort is turning jobs faster than you are. That is exactly why the pill spells it out explicitly, "P34 (lower is better)," rather than leaving you to remember the direction.

The pill's color follows the same logic: it renders in the green Expand tone when your network's median cycle time is at or below the rest-of-industry median, and in the red Analyse tone when it is slower. When either side has no data at all, the pill renders in a neutral tone, there is nothing yet to color as ahead or behind.

Step 5: the privacy floor, checked on both sides

Once the engine has one clean per-operator median for your network and for the eligible rest of the industry, it checks a hard floor before it will publish anything. Both sides have to be built from at least a minimum number of distinct contributing operators, counted by operator, never by job, or the entire comparison is withheld for that request.

Two things about this floor are worth knowing precisely:

• The floor is qualitative by design. Verinode does not publish the exact operator count it takes to clear it, on this page or anywhere else on the platform, because publishing the mechanics would invite someone to game it. Operational metrics like cycle time sit at Verinode's base floor, the tier used across the platform's process-timing figures. Financial and cost-structure metrics elsewhere in HQ, like margin and the cost ratios on Margin & Cash, sit behind a materially higher floor, because a P&L figure is more identifying than a days-to-complete figure. Cycle time is never held to that higher bar.
• The floor checks BOTH sides, including your own network's. This is easy to miss. The check is not only "is there enough of the outside industry to compare against." If your own network does not yet have enough distinct reporting operators to clear the same bar, the engine withholds your network's own median too, not just the industry comparison. A very small or newly onboarded network can see the hero read as if there is no cycle-time data at all, even when a handful of members have genuinely reported job data, because publishing that network's own median from too few contributing operators would itself be identifying.

When either side fails the floor, every figure that depends on it, your network's own median, the rest-of-industry median, and the percentile between them, comes back null for this request. The hero never shows a partial number with a small-sample caveat attached. It falls back to its plain-language empty state instead: "Cycle time appears as members share job data." No pill renders in that state either.

Step 6: the coverage classification, computed but not printed on this page

Underneath the privacy floor, the engine also computes a separate, secondary signal: a confidence classification describing how much data currently backs a comparison that has already cleared the floor. It moves through the same qualitative ladder used elsewhere in HQ, an early read, a more established read once more contributors are behind it, and so on, up to the strongest read the engine produces when a broad base of operators sits on both sides.

On the Operations hero, this classification is computed for every cycle-time request but is not printed as a labeled pill the way it is on some other HQ surfaces. On this page, whether the comparison is ready shows up only as: does the percentile pill appear at all, or does the hero fall back to its empty state. You will see this same classification printed directly as a result-tile label, though, if you run a cycle-time comparison through Cohort Builder, it uses the identical underlying calculation with a custom operator selection in place of your full roster.

Putting it together

1. 1Read the headline and the pill together. A green pill with a low percentile number means your network is genuinely faster than most of the eligible outside cohort. A red pill means the opposite. Lower is always the better direction for this particular metric, which is why the pill spells that out for you.
2. 2If the hero reads "Cycle time appears as members share job data" instead of a number, that is the privacy floor, not a broken page. It means either your own network or the eligible outside cohort has not yet cleared the bar Verinode holds for publishing an operational comparison.
3. 3Remember the floor checks your own network's side too. If your network is small or newly onboarded, the fix is more of your own members contributing cycle-time data, not waiting on the rest of the industry.
4. 4If you want the same math against a narrower slice, a region, a subset of top performers, anyone who took a specific training, run it through Cohort Builder, which prints the same underlying comparison alongside an explicit confidence label.

Best-practice example

Say your network's hero reads a headline of 9 with a green pill reading "P22 (lower is better)." Read that as: your network's typical job takes about 9 days start to close, and that figure sits in the fast 22nd percentile of every eligible operator outside your network, most of the outside cohort is running slower than you are. That is worth a callout at the next ops review, and worth checking against the Capacity Pressure row underneath the hero to confirm the network is not achieving that pace by running crews at an unsustainable load.

Contrast that with a network still onboarding its first few locations. The hero may show a headline of 0 and the plain sentence instead of a pill, even though two or three members already have a cycle-time figure on file, because the group side of the floor has not cleared yet. That is not a stalled page. It is the same floor working exactly as designed on your own network's side of the comparison, not just the industry's, and it resolves on its own as more of your network reports job data.

Related articles

• The cycle-time hero: how your network compares to the industry
• Operations: your network's process health at a glance
• Capacity Pressure: where the network is running hot
• Process Maturity: SOP coverage across the network
• Shared SOPs: the network's process library
• Fleet, bulk-buy candidates
• How network margin benchmarks are computed and protected
• Benchmark methodology and the privacy boundary
• Coverage labels and the anonymity floor
• Cohort Builder
• What HQ sees: the network privacy boundary
• Network benchmarks: how the section works