Shared SOPs: the network's process library

What Shared SOPs is

Standard operating procedures are the single biggest source of quality variance across a restoration network. One office runs a tight 12-step water-loss checklist; another improvises. Shared SOPs is where Verinode HQ makes the network's best documented processes visible to leadership, without ever exposing a member's private operating detail beyond what that member chose to publish.

A shared SOP is not something HQ writes or assigns. It is a process a member operator chose to publish from their own Verinode IQ account, run through an anonymization pass that strips the operator's identifying detail, and place into the network library for every other member of the group to see and, if useful, adopt into their own process documentation. Shared SOPs is the read side of that exchange: a row on the HQ Operations page that shows every SOP the network has published, who published it, how many peers have adopted it, and how many times it has been viewed.

This is knowledge-sharing infrastructure, not compliance enforcement. Nothing here tells a member what to do. It surfaces what other members are already doing well and makes it one click away to copy.

Where to find it

Open Operations from the HQ sidebar, under the Operations group, at hq.verinode.ai/operations. The Operations home is a stack of five rows, each a horizontal scroll of tiles:

1. A hero panel at the top showing the network's cycle-time median against the industry, alongside Process Maturity %, Capacity Utilization %, and Fleet Items.
2. Capacity Pressure: members running hot on utilization.
3. Process Maturity: every member's SOP-coverage standing.
4. Shared SOPs: the network process library. This is the row this article covers.
5. Bulk Buy: fleet/equipment categories where several members rent the same class.

Shared SOPs sits third from the top, between Process Maturity and Bulk Buy. Each tile in the row is one shared SOP.

What each tile shows

Every tile in the Shared SOPs row carries:

• Label, always Shared SOP (a fixed tag identifying the row's content type, not a per-item status).
• Headline, the SOP's title as the source member wrote it (for example, "Water Loss First Response: 60min on-site checklist").
• Subtitle, the service line the SOP is tagged to, followed by the publishing member's name (for example, "Water · by Heartland Disaster Group"). If the SOP has no service-line tag, the subtitle drops straight to "By [member name]" with no leading category.
• Meta line, the two numbers this article is about: "[N] adopted · [N] views", adoption count first, then view count, in that order (for example, "228 adopted · 9 views").

Click a tile and it opens the SOP's detail card, which repeats the same header information (title, source member, service line) inside the drill-in view.

Reading the two numbers

Adopted is a hard count: every time a member operator clicks Import on this SOP from their own Verinode IQ Processes view, this number increments by one. Importing copies the SOP's anonymized body into that operator's own SOP library as a new draft they own outright. It does not link back to the original or auto-sync future edits. A high adopted count means the network is actually using this process, not just admiring it.

Views is the softer signal: how many times members have opened this SOP in the network library. A SOP with many views but few adoptions is one members are checking out and deciding not to run as-is, worth a second look at whether it fits your network's conditions. A SOP with adoption tracking views closely is one that reads as immediately useful the moment someone opens it.

Neither number is a ranking mechanism, and neither is gated by cohort-size thresholds the way peer benchmark percentiles are. A shared SOP's adoption and view counts are visible at whatever count they currently sit at, because they describe voluntary network behavior, not a statistical comparison across anonymized peers.

How a SOP gets published: the operator-side path

Shared SOPs is populated entirely by members choosing to publish, from their own Verinode IQ account. There is no HQ-side authoring tool and no way for HQ to add, edit, or remove a shared SOP directly from this page. HQ is a reader here, not a publisher.

1. 1A member operator documents a process as an SOP inside their own Processes view (iq.verinode.ai/processes, All Processes tab, SOP kind).
2. 2From that SOP, the operator chooses to share it with their network.
3. 3Verinode runs the SOP body through an anonymization pass before anything leaves the operator's account. Company name, location, owner and employee names, customer names, addresses, phone numbers, emails, vehicle identifiers, and operator-specific dollar figures tied to the operator's own contracts are stripped. Procedure logic, safety steps, materials specs, time estimates, decision points, and industry-standard reference codes (IICRC numbers, OSHA citations) are kept intact.
4. 4The anonymized SOP is written into the network's shared library, tagged with the operator's display name (typically their company name) and their SOP's service line, and becomes visible as a tile in this row for every member of the same HQ group.
5. 5The operator's original SOP is untouched in their own account. HQ never sees the un-anonymized version, and no version of it flows through core.* or any HQ-visible table.

The privacy boundary this preserves

Every number on this page respects the same rule that governs everything on HQ Operations: franchisees own their data; HQ sees aggregates and what members explicitly publish, never the underlying private business record.

• A shared SOP's body is the anonymized version, generated before the operator's identifying detail ever leaves their account. HQ reads the anonymized copy from the network's shared table; the original SOP in the operator's own process library, with any operator-specific detail left in place, is never queried by HQ.
• Publishing a SOP is opt-in, one document at a time, initiated by the operator. A member who never shares anything shows up nowhere in this row.
• Adoption and view counts describe network behavior (how many peers chose to act on a published process), not a member's private operating metrics. They carry no dollar figures, no customer information, and no per-job detail.

At-rest encryption

The SOP body behind each Shared SOPs tile is stored encrypted at rest. Verinode encrypts the shared SOP text under the HQ group's own data-encryption key, sealed with AES-256-GCM, before it is ever written to disk. The encryption key itself is wrapped so that Verinode's infrastructure can unwrap it server-side to serve the Operations page (this is what lets the anonymized SOP body render for every group member without an admin needing to be logged in at read time). It is not a key only an individual admin's session can unlock. That distinction matters for Shared SOPs specifically: the SOP-sharing action runs from the operator's session, not an HQ admin's, so the shared library needs a key any authorized server-side process can reach, rather than one bound to a single logged-in admin.

In practice this means: if Verinode's database were ever exposed directly, the SOP text sitting behind these tiles is ciphertext, not plaintext, and unreadable without the wrapped key. It also means the anonymized SOP body is the only thing encrypted here. The already-stripped, industry-generic procedure text is what's protected. This protects the network roll-up of anonymized process knowledge from casual database exposure: layered defense on top of the anonymization pass itself, not a second identity-protection step.

Empty state

If no member has published a SOP to the network yet, the Shared SOPs row shows this text instead of tiles:

"Network SOP library is empty. When a franchisee earns network adoption, share their SOP from the operator-side processes view (anonymized before write)."

This is not an error. It means every member's SOPs are still private to their own account, which is the default and always-safe state. The library populates the first time any member chooses to publish, and HQ has no way to prompt or require that from this page.

Reading the row as HQ leadership

The Shared SOPs row is not a compliance checklist and should not be read as one. Use it to spot which processes the network has organically converged on as worth documenting and sharing, and to gauge how actively members are learning from each other:

• A row with several high-adoption SOPs across different service lines (water, fire, mold, storm) suggests the network's knowledge-sharing culture is healthy and multi-disciplinary.
• A row where every shared SOP comes from one or two members suggests those offices are your strongest documented operators, worth a closer look through the Process Maturity row and the franchisee-level SOP coverage picture, and potentially worth spotlighting in a broadcast or a Discovery Day session.
• Low view counts network-wide, even where SOPs exist, is a discoverability problem worth raising directly with members. The library only works if operators know to check it before writing their own process from scratch.

Related reading

• Operations overview: how Operations fits alongside the rest of the HQ shell.
• Network health: the franchisee-level view Process Maturity and Shared SOPs both feed into.
• Standards & compliance: the framework-level (IICRC, OSHA, EPA, state) reference library shared SOPs sit alongside on the operator side.
• Broadcasting to your network: how to spotlight a high-adoption SOP or its publishing member to the rest of the network.
• Discovery Day: the in-person venue where high-adoption SOPs often get walked through live.