Operations: your network's process health at a glance

What the Operations section shows

Operations is where HQ reads how the network actually runs, cycle time, process discipline, capacity headroom, and equipment, as a set of network aggregates and per-member rollups. It answers questions like: is the network turning jobs faster or slower than the rest of the industry, which members are running so much active work that quality is at risk, how many members have their processes actually documented as SOPs versus running on tribal knowledge, and where does the network have enough shared equipment demand to negotiate as a group.

Every number on this page is either a network-wide aggregate or a rollup attributed to one of your own network's members. Operations never reads a franchisee's private job-level records, adjuster correspondence, payroll, or line-item costs. It reads what your network's own nightly aggregation cron has already rolled up into your group's numbers, the same boundary that governs every HQ surface. See What HQ sees: the network privacy boundary for the full technical explanation of how that boundary is enforced.

Verinode HQ is the network intelligence layer sitting on top of every member's own IQ account. Operations is not a job-management or scheduling tool, it does not assign work, log hours, or track a specific job through its lifecycle. It surfaces the patterns and reports the numbers; your network's leadership decides what to do with them.

Where to find it

Open Operations from the HQ sidebar at hq.verinode.ai/operations. In the sidebar this item sits under the Operations group, the run-and-spend side of the network (its counterpart on the content side is Margin & Cash). The page has one home view built from five rows, plus a Download board slide button in the top-right corner that exports the section as a PDF for a board or leadership deck.

Row 1: the hero, cycle time and three secondary numbers

The top of the page is a single dominant number: Cycle Time, Group median (days), your network's median days from job start to close, rounded to the nearest whole day.

Beside the headline, a pill shows one of two things:

• A percentile, formatted like "P34 (lower is better)". This is where your network's median cycle time lands against the eligible cohort of operators outside your network, on the same day, week, and cost-structure metrics used across HQ's benchmarks. A low percentile number is the good direction here: it means most of that outside cohort is running slower than your network. A high number means more of the outside cohort is turning jobs faster than you are.
• A sample-size readout, formatted like "n=8/142", shown instead of a percentile when the comparison isn't ready to publish yet. The first number is how many of your own members have contributed cycle-time data; the second is the size of the eligible outside cohort at that point in time.

Underneath the headline, a line of text reads, for example, "Industry median 9d · 62% Process Maturity · 71% Capacity." That's the outside-network reference median for the same metric, followed by the same two percentages that anchor the secondary tiles beside it. Until your network has at least one member reporting cycle time, this line instead reads: "Cycle time appears as members share job data."

Three secondary tiles sit to the right of the headline:

• Process maturity, the percentage of your network's members whose SOP coverage clears the maturity bar (see Row 3 below), labeled "Above SOP coverage threshold." It highlights in green once it clears 70%, otherwise it renders in a neutral tone.
• Capacity utilization, the percentage of the network's active job load against its total capacity, labeled "Network active jobs vs cap." It flags in yellow once it passes 80%, the same threshold that drives the Capacity Pressure row below.
• Fleet items, a plain count of equipment registered across the network, labeled "Equipment registered." This tile has no good/bad tone, it's a footprint number.

All four hero numbers are read from the latest snapshot in your group's aggregation history, the same nightly rollup that powers the rest of HQ, not a live counter that updates as jobs close in real time.

Row 2: Capacity Pressure

This row surfaces members whose active job load is running hot enough that it's worth a look, sorted from most stretched to least.

A member appears here only once their capacity utilization passes 80%. Below that line, the row is empty and reads: "All members operating with healthy capacity headroom."

Each tile that does appear shows:

• A label, "Stretched" for members between 80% and 95% utilization, or "Maxed Out" above 95%, with the tile's accent color shifting from Hard Hat Yellow to Ember Red at that same line.
• The member's name as the headline.
• "{X}% Capacity" underneath.
• "{X}d Cycle Time" as the trailing meta line, when that member has a cycle-time figure on file. A ring gauge behind the tile visualizes the same utilization percentage.

Clicking a tile opens that member's page under Franchisees. The row shows up to six members at a time; open the Capacity tab in the card slider to see the full list.

Row 3: Process Maturity

This row is the per-member view behind the "Process maturity" hero tile: every member in your network, one tile each, with the fraction of their process work that's actually documented as an SOP.

If your network has no members yet, the row reads: "Process maturity will appear as members are added."

Each tile shows:

• A label describing the member's SOP coverage band: Mature (80% and above), Partial (40% to 79%), Low (below 40%), or Pending when no coverage figure has come through yet.
• The member's name as the headline.
• "{X}% SOP coverage" underneath, or "Awaiting data" for members still Pending.
• "{X}d cycle", the same cycle-time figure shown in the Capacity row, as trailing meta when available.
• A gauge visualization tuned to the same 40/80 thresholds, colored green for Mature, yellow for Partial, red for Low.

Clicking any tile opens that member's page under Franchisees. The row shows up to twelve members; the Process Maturity tab in the card slider lists every member in the network regardless of how many that is.

Row 4: Shared SOPs

This is your network's shared process library, the SOPs a member has actively published so other members can adopt them. It's a different kind of sharing than the aggregates elsewhere on this page: a member has to choose to publish an SOP to the network, and once they do, it's attributed to them by name, that's the whole point of sharing it, since adoption is how a member earns recognition across the network for a process that works.

If nothing has been shared yet, the row reads: "Network SOP library is empty. When a franchisee earns network adoption, share their SOP from the operator-side processes view (anonymized before write)." The "anonymized before write" note refers to how the SOP's content itself is stripped of any client, address, or job-specific detail before it's written to the network library, the process is shared, not the job it came from.

Each shared SOP tile shows:

• "Shared SOP" as the label.
• The SOP's title as the headline.
• The service line and source member, formatted as "{Service Line} · by {Member Name}" when a service line is tagged, or just "By {Member Name}" when it isn't.
• "{X} adopted · {X} views" as trailing meta, the number of members who have pulled this SOP into their own process library and the number who have viewed it.

Clicking a tile opens the Shared SOPs tab in the card slider, focused on that entry, with the SOP's body text alongside the same metadata. The home row shows up to eight SOPs, newest first; the slider tab lists all of them.

Row 5: Fleet, bulk-buy candidates

The last row is a network-wide equipment census by class, air movers, dehumidifiers, ozone generators, and the rest, surfaced so leadership can spot where the network has enough shared demand for a class of equipment to negotiate as a group instead of every member buying or renting on their own.

If no members have logged equipment yet, the row reads: "Fleet inventory will appear as members add equipment."

Each tile shows:

• A label, "Bulk-buy" when this equipment class has cleared the network's collective-demand bar, or plain "Class" otherwise. Bulk-buy candidates sort to the front of the row.
• The equipment class name as the headline, humanized from the underlying category (for example, a "cube_van" record displays as "Cube Van").
• "{X} units across network" underneath, the total unit count across every member.
• "{X} operators" as trailing meta, how many distinct members currently report equipment in that class.

A class earns the "Bulk-buy" label once enough members across the network are independently carrying equipment in that class that a group purchase or a group rental agreement becomes worth pursuing. Verinode doesn't publish the exact number of members it takes to cross that line, the same qualitative posture as every peer-count gate on the platform, because publishing the mechanics invites someone to game it. What you get instead is the label itself: once a class flips to "Bulk-buy," it's real, and worth a conversation with your equipment vendors.

Clicking a tile opens the Fleet tab in the card slider, focused on that class, alongside every other class in the network. The home row shows up to twelve classes; the slider tab lists all of them, bulk-buy candidates first.

How to use it

1. 1Start at the hero. If cycle time shows a percentile, note whether it's trending toward or away from the "lower is better" direction; if it shows an "n=" readout instead, the outside-industry comparison isn't ready yet and you're looking at your own network's raw contribution count.
2. 2Scan Capacity Pressure first. A member in "Maxed Out" territory is the most time-sensitive read on the page, sustained overcapacity is where service quality and crew burnout both start to slip.
3. 3Cross-reference against Process Maturity. A member who's both Stretched and Low on SOP coverage is running hot without the documented process to fall back on when things go wrong, that combination is worth a direct conversation, not just a dashboard glance.
4. 4Check Shared SOPs for anything worth pushing network-wide. A high adoption count on a shared SOP is a signal that the process behind it works broadly, not just for the member who wrote it.
5. 5Scan Fleet for any class flagged "Bulk-buy." That's the trigger to open (or reopen) a group-purchasing conversation with your equipment vendors.
6. 6Use Download board slide in the top-right corner to export the page as a PDF when you need to bring these numbers into a board or ownership meeting.

The privacy boundary on this page

Operations follows the same boundary as every other HQ surface: HQ reads your group's own per-member rollups, computed by a nightly aggregation cron that has access to run against member accounts specifically to build those rollups, and the anonymized cross-network industry reference. It has no path to query a member's raw job-level data directly, that database connection is refused at the schema level regardless of what HQ's application code asks for.

Two different things on this page look similar but aren't:

• Your own network's per-member rollups (Capacity Pressure, Process Maturity, the per-member fleet counts folded into the network total) are your own members looking at their own network. If your network's entity model anonymizes member identity, names appear as stable labels instead of business names; if it doesn't, real names show. Either way, this is your own network, not a privacy-boundary comparison.
• The industry percentile on the cycle-time hero is built from operators entirely outside your network, and it publishes as a single median with no names, and only once enough independent operators outside your network have contributed. Below that bar, you see the sample-size readout instead of a percentile, never a number built from too thin a cohort.

Shared SOPs work differently again: sharing is an opt-in act by the member, and the point of sharing is credit, so the source member's name is attached on purpose. That's not a privacy-boundary exception, it's a separate, voluntary mechanism sitting on top of the same boundary.

For the full explanation of how this boundary is enforced end to end, read What HQ sees: the network privacy boundary. For how the cross-network industry side of any HQ metric gets built and gated, read Benchmarks. For the roster and per-member view Operations tiles link out to, read Network Health.

Data sources