Where stage medians come from: the nightly rollup

What this article covers

Every stage-time number you see on HQ, a "5.2d Assigned → Started" tile on Network, a "Standard 3d" row on Process Standards, a Met/Near/Missed grade in Conformance, comes from the same nightly job: the HQ aggregate-refresh cron. This article explains what that job does, exactly what it is and is not allowed to move between databases, and how to read the medians, percentiles, and sample counts it produces. If you manage stage-time standards day to day, read Process Standards first; this article is the "how the numbers get made" companion to it.

The privacy boundary, in one sentence

Franchisees own their operational data. HQ never sees a single franchisee's job list, timelines, or case-level records. What HQ sees is nightly, per-office, per-stage medians, quartiles, and sample counts, and nothing else crosses from the franchisee database into the network database. That boundary is enforced in code, not just policy: it is the reason HQ can run a network-wide standards program without becoming a surveillance tool.

The nightly rollup, plainly

Once a day, a scheduled job (the "hq-aggregate-refresh cron") wakes up and, for every active network on the platform:

1. Reads each member franchisee's lifecycle dates for the last 365 days: when a job was assigned, started, completed, billed, paid, and so on. This read happens inside the job itself, with elevated access that only this one job holds. Nothing you see on any HQ screen reads franchisee data directly.
2. Groups those dates into ordered stages by process (see the list below) and measures how many days elapse between each consecutive pair of stages, per franchisee.
3. Computes, for every stage transition, per office: the median (the middle value, the day count where half of that office's cases were faster and half were slower), the p25 and p75 (the 25th and 75th percentile day counts, the fast quarter and slow quarter of that office's own cases), and n (how many in-order cases fed the calculation).
4. Pools every office's raw cases together and repeats the same math to produce one network-level row per transition, the network's own median/p25/p75/n across all offices combined.
5. Writes only those numbers, medians, quartiles, counts, tagged by office and by transition, into the network database. No job ID, no customer name, no date, no address, no timeline ever leaves the franchisee database. A single case can never be reconstructed from what lands on the HQ side.
6. Snapshots one more figure onto each network-level row where it exists: the anonymous industry median for that same transition, drawn from the cross-network peer benchmark. This is the "your network vs industry" comparison you see on Network Flow tiles. It is a single published number from an anonymous, already-aggregated cohort; it carries no operator identities in either direction.

The job runs once nightly in a scheduled early-morning window (mid-morning UTC), after the operator-facing scoring pipeline has already run for the day. Large platforms with many networks are handled with a checkpoint: if the job runs out of time before finishing every network in one pass, it resumes exactly where it left off on the next scheduled tick rather than skipping networks or restarting from zero. Every day's rollup keeps its own dated row set, so the history itself becomes the basis for trend detection (see "What the rollup feeds," below) without ever needing to re-read franchisee data to look backward.

The processes it mines

The rollup doesn't only track jobs. It mines every process registered on the platform that has enough real, dated lifecycle data to support a meaningful median, currently seven:

| Process | What it measures | Example transition | |---|---|---| | Job lifecycle | Assigned → Started → Completed → Billed → Paid (plus optional Estimate submitted / Carrier approved stages where the network captures them) | Billed → Paid | | Supplement turnaround | Submitted → Responded | Submitted → Responded | | Recruiting pipeline | Received → Interviewed → Hired | Received → Interviewed | | Incident follow-through | Occurred → Action Closed | Occurred → Action Closed | | Purchasing cycle | Ordered → Received → Invoiced → Paid | Ordered → Invoiced | | Lead response | Received → First response → Converted | Received → First response | | Review response | Posted → Responded | Posted → Responded |

Each is a real, ordered sequence of dates a franchisee's own tools already capture; the rollup does not invent process stages that aren't backed by real dated columns. A process only gets registered here once real, filled-in dates exist across enough of the network to make its medians honest rather than hollow.

The five-case floor: why some cells read "Warming Up"

A median built from one or two cases is not a median, it is a coincidence wearing a number's clothes. So every office-level cell (one office, one stage transition) needs at least five in-order cases before the rollup will publish a median, p25, or p75 for it. Below that floor, the cell writes as an honest null rather than a number, and every surface that reads it (Network Flow, Process Standards, Conformance) renders that cell as Warming Up instead of guessing.

This is the same floor whether you're looking at:

• A Network Flow tile's per-office breakdown, where an office under the floor is simply left out of the office list until it clears five cases, with a note that the comparison "appears once an office clears five in-order [cases] on this stage."
• A Conformance row, where an office under the floor shows Warming Up · N of 5 next to its name instead of a Met/Near/Missed grade.

The network-level row (all offices pooled) has to clear the same five-case floor too, just against the pooled total rather than any one office's volume, so a brand-new or very small network can see network medians arrive before any single office's own count catches up.

Reading the network-level number correctly

The network-level median is a pooled median: every office's raw cases are combined into one pile and the median is taken across that whole pile. That means a high-volume office naturally pulls the network median toward its own pace more than a low-volume office does; it is not an average of each office's own median, and not every office is weighted equally. Read the network number as "how the network's total case load actually moved," and read the per-office breakdown underneath it as how any one location compares. When Network Flow shows the network number sitting close to (or far from) the anonymous industry median, that comparison is directional, useful for spotting a network-wide gap, but it is not a perfectly like-for-like statistical match, since the industry figure is a plain median over its own (external) cohort while the network figure is case-count-weighted over yours.

Where the output shows up

The rollup itself has no page of its own. It feeds three places in the product, all reading the same nightly snapshot from the network database, never from franchisee data directly:

Network Flow (Network Health, /network)

Open Network from the sidebar (Network band). The Network Flow row shows one tile per stage transition with a live network median: the process it belongs to, the transition (e.g. "Billed → Paid"), the network's median day count and case count, and, where the anonymous peer cohort publishes one, a small marker showing the industry median on the same scale, toned faster-than-industry or slower-than-industry. Tapping a tile opens the Network Flow tab in the Network Health detail view, where each transition expands into the network median, the industry median line ("Industry median X.Xd across the anonymous peer cohort") when one exists, and a per-office list ordered fastest to slowest, each office's own median, and its case count. Until offices have reported enough lifecycle dates, this row reads: "Network stage medians appear as offices report lifecycle dates. Job, supplement, recruiting, and safety flows map here automatically."

The row also carries a Standards Conformance tile once at least one stage-time standard exists (see below), showing the network's overall conformance percentage and a shortcut into the Conformance tab.

Process Standards (/standards/process, reached via Compliance)

From the sidebar, open Compliance (Compliance band), then the Process Standards tile inside the Standards & Audits row. This is where HQ sets a target number of days per stage transition, the network's committed pace, and where every office gets graded against that same bar. Each row shows the transition name, the current Network Median with how many offices are reporting it (or "No Network Median Yet" if the pooled floor hasn't cleared), and, once a standard exists, the Met/Near/Missed breakdown across offices. Admins can type a target directly, or click Use median to pre-fill the field with the network's own current median for that transition, then Save. A Clear link removes a standard. Non-admins see the same rows read-only, with "Standard X.Xd" or "No Standard" in place of the input controls.

When at least one transition has a live network median and no standard set yet, an Adopt network medians button appears at the top of the page for admins: one click sets every un-set transition's standard to the network's current median, the fastest way to start a standards program from where the network already runs today rather than a number pulled from nowhere.

The page header shows a live conformance share (for example, a percentage headline with a pill reading On Pace, Watch, or Action Needed depending on how the network is scoring), plus Standards Set (of how many total transitions), Checks Met, and Missed counts. Before any standard exists, the header instead reads: "Target days per stage, committed to by the network. Set a standard per transition (or adopt the network's own medians) and every office is measured against the same bar."

Conformance grading

Once at least one standard is set, every office's stage median for that transition is graded nightly:

• Met: the office's median is at or under the target.
• Near: the office's median is over the target but within a reasonable tolerance band above it.
• Missed: the office's median is meaningfully over the target.
• Warming Up: the office hasn't cleared the five-case floor yet on that transition, so there is no verdict, not a hidden bad one.

You can see this grading two ways: the compact Standards Conformance tile on Network Flow, or the full Conformance tab inside the Network Health detail view, which lists every standardized transition with its target, the network's own median and verdict, a Met/Near/Missed tally, and a per-office list (color-coded dot, office name, verdict, median, case count) ordered so the slowest, most attention-worthy offices sit at the top and warming-up offices sit last. If no standards exist yet, this tab reads: "No stage-time standards set yet. Define target days per stage under Standards → Process Standards; every office is then measured against the same bar, and the grades land here." If standards exist but the first nightly rollup hasn't landed yet, it reads: "Standards are set. Office grades appear after the next nightly rollup of stage medians."

Office names throughout all three surfaces pass through the same network-wide display-name handling every other HQ view uses (so a network that has chosen to anonymize its office names sees the same anonymized labels here as everywhere else, consistently).

What the rollup feeds beyond the screens above

Because each night's rollup keeps its own dated snapshot, the history it builds up powers two things you'll see arrive as signals rather than as this rollup's own UI:

• Stage-duration drift: a leading-indicator trend detector compares recent nightly snapshots against older ones (network-wide and per office) and flags a meaningful slowdown before it becomes a standards miss.
• Repeated conformance misses: an office that grades Missed against a standard on two consecutive nightly snapshots (not one bad night) generates a signal and a draft intervention plan, so a single noisy day never triggers an alert but a real, sustained pattern does.
• Billed → Paid carrier attribution: the same job-lifecycle dates that feed Billed → Paid medians also let HQ separate "this carrier pays every office slowly" (a carrier-side pattern worth escalating once, network-wide) from "this office collects slower than peers on the same carrier mix" (an office-side pattern worth a local conversation). Both read only the aggregated medians this rollup produces, never a franchisee's individual invoices.

These show up as signals and playbooks elsewhere in the product; this article only covers where their underlying numbers come from.

Known limits, honestly

• The network-level median is pooled, not office-averaged. See "Reading the network-level number correctly" above; a high-volume office has more influence on the network figure than a low-volume one.
• The five-case floor applies per office, per transition. A brand-new office, or an established office with genuinely rare volume on one particular stage (say, a recruiting pipeline transition it rarely runs), will show Warming Up on that specific cell even while its other cells are fully scored.
• The industry comparison is a snapshot, not a live feed. It's captured once, nightly, at the same time as the network-level row, from the anonymous cross-network peer cohort. It only appears where that broader cohort publishes a figure for the exact same transition and time window; not every transition has one.
• Nightly, not real-time. A franchisee's activity today appears in the rollup tomorrow morning. There is no "refresh now" button, by design, since the boundary crossing happens once, on a schedule, through one audited code path rather than on demand.

Related articles

• Process Standards
• Network Health
• HQ Benchmarks
• HQ overview
• Compliance