Verinode
Open Verinode

Reading Adoption Metrics: Rates, Median Days, and the Nightly Cron

The Playbook Scoreboard and the plan detail view both surface a handful of numbers that describe how your network is responding to a decision plan: an adoption completion rate, an affected-of-total…

12 min read·Updated July 14, 2026
On this page

What this article covers

The Playbook Scoreboard and the plan detail view both surface a handful of numbers that describe how your network is responding to a decision plan: an adoption completion rate, an affected-of-total franchisee count, a signal severity, and two median-day figures. None of these are typed in by anyone at HQ. They are all written by a single nightly cron job that reads the state of your network and decorates each plan with the current picture.

This article is the glossary. It defines each field precisely, explains where the number comes from, and explains why a brand-new plan reads "Awaiting cron" instead of a number until that job has run. For the page these fields live on, see /help/hq-playbook-scoreboard. For the queue where you push plans and read the same fields per membership, see /help/hq-playbook-scoreboard-vs-decisions-inbox.

Where these fields appear

You will see the same set of cron-written fields in two places:

  • The Playbook Scoreboard, at hq.verinode.ai/playbooks. Each tile in the Top Performers, Need Diagnosis, and All Active Playbooks rows shows a compressed version of these fields: the adoption percentage as the tile label, the affected-of-total count in the sub-line, and a median-days figure in the meta line.
  • The plan detail view, opened by clicking any tile on the Scoreboard (which routes to /franchise/decisions?plan=<id>) or by opening a plan directly from the Decisions inbox. Here the fields render in full under a Live decoration heading, with the exact refresh date beside it.

Both surfaces read the same underlying columns on the plan record. The Scoreboard is the compressed, ranked view; the detail view is the full readout.

The nightly cron: what it is and how it works

The job is called hq-aggregate-refresh. It is the single bridge that reads your operators' underlying data and writes pre-aggregated, network-level rows into the tables HQ pages read from. Decision-plan decoration is one small piece of a much larger sweep that also refreshes network health, benchmarks, compliance, and every other aggregate view across HQ.

The sweep runs once per day, in an early-morning UTC window, and is checkpointed: for networks with many memberships, one pass through every group can take more than a single run, so the job resumes from where it left off on each subsequent tick until the full sweep completes. This is why the Scoreboard's own empty-state and callout copy calls it a "nightly cron" rather than promising an exact time of day: it is a daily batch process, not a live, on-demand calculation.

For each decision plan in your group (every plan except archived ones), the cron writes:

  • current_affected_count and current_total_count, plus current_signal_severity, sourced from the underlying network signal the plan targets, if it was authored against one.
  • median_days_to_acknowledge and median_days_to_in_progress, calculated from every membership's per-plan adoption timestamps.
  • adoption_completion_rate_pct, the share of pushed memberships that reached "completed."
  • decoration_refreshed_at, the timestamp of that write, which is what the "refreshed [date]" note beside Live decoration in the plan detail view is reading.

Note

"Nightly cron" and "decoration" both refer to the same thing: a background job, not something you trigger by clicking. You never run this yourself. It simply runs once a day and updates every plan in the network in place.

Why a new plan reads "Awaiting cron"

The moment you activate a plan and push it to franchisees, none of these fields have a value yet, because the cron has not had a chance to look at it. On the Scoreboard, the tile label reads Awaiting cron in place of a percentage. In the meta line, a freshly-pushed plan on the Need Diagnosis row reads Awaiting acknowledgment instead of a median-days figure. A plan in Top Performers with no data yet does not appear in that row at all, since there is nothing to rank it on.

This resolves automatically the first time hq-aggregate-refresh sweeps your group after the plan was created or pushed. You do not need to do anything to make it happen, and there is no manual "refresh now" action. Once the first sweep completes, the plan carries real numbers from then on, and those numbers keep updating on every subsequent nightly run for as long as the plan stays active (or until it is archived).

Tip

If a plan has been live for more than a day and still reads "Awaiting cron," check whether it was created very late in the sweep window, or whether your network is large enough that the checkpointed sweep is still working through earlier groups. It will resolve on the next tick. It is not a sign that anything is broken with the plan itself.

One field is a partial exception: current_affected_count, current_total_count, and current_signal_severity only ever populate for plans that were authored against a specific target signal. A plan you authored without binding it to a network signal, a general initiative or standalone directive, will carry a permanent null for those three fields no matter how many nightly sweeps run. That is expected, not a stuck state: there is no signal for the cron to read a current count from. The adoption-pace fields (median days, completion rate) still populate normally for those plans, since they come from franchisee adoption timestamps, not from a signal.

The glossary

Adoption completion rate (adoption_completion_rate_pct)

What it is. The percentage of memberships the plan was pushed to that have reached status = completed on their individual adoption record.

How it is calculated. The cron counts every adoption row for the plan (every membership it was pushed to, regardless of where they currently stand), counts how many of those rows carry completed status, divides the second by the first, and rounds to a whole percentage. A plan pushed to memberships where none have finished the work reads 0%. A plan where every membership has finished reads 100%.

Where you see it. As the tile label on the Scoreboard, formatted "N% adopted." In the plan detail view, as Completion rate: N% under Live decoration.

How to read it. This is a completion measure, not an engagement measure. A membership that acknowledged the plan and is actively working through it still counts as 0 toward this percentage until their adoption record moves to completed. A low completion rate on a plan that has been live only a few days is expected; the same rate on a plan live for months is the signal that something about the rollout, not the plan's substance, needs attention.

Affected-of-total franchisee count (current_affected_count / current_total_count)

What it is. A live read of how many memberships the plan's underlying network signal currently affects, out of how many are eligible. This is not a count of how many memberships have adopted the plan; it is a count of how many are still exhibiting the pattern that made HQ author the plan in the first place.

How it is calculated. Every plan can optionally be authored against a specific network signal (target_signal_id). The cron looks up that signal's type, finds the most recently detected signal row of that type for your group, and copies its affected count, total count, and severity onto the plan. This means the count updates independently of adoption: if the plan targets "franchisees running outdated estimating software" and the signal is still detecting the same pattern six months later, the plan will still read something like "8 of 12 franchisees," even though the plan has been live all that time. A plan with high adoption but an affected count that hasn't moved is worth a second look. It says memberships marked their task complete, but the signal that triggered the plan is still firing.

Where you see it. In the tile sub-line, formatted "[kind] · N of M franchisees" (Top Performers, Need Diagnosis) or "N/M" (All Active Playbooks). In the plan detail view, as "Currently affects N of M franchisees."

How to read it. Treat this as the problem-side reading and the completion rate as the response-side reading. The two together tell you whether the plan is working: falling affected count alongside rising completion is the plan doing its job; flat affected count despite high completion is worth a follow-up conversation, not just a checked box.

Signal severity (current_signal_severity)

What it is. The severity tier of the same underlying signal the affected count is read from: info, warning, or critical. It travels with the affected count, so it updates on the same schedule and is subject to the same rule: a plan without a bound target signal never carries a severity value.

Where you see it. Only in the plan detail view, appended after the affected-of-total line as "signal severity: [value]." A critical severity renders in the Analyse signal color (Ember Red) to draw the eye; info and warning render in the default text color. It does not appear on the Scoreboard tiles themselves.

How to read it. This tells you how urgent the underlying network condition is judged to be, independent of how the plan pushed to address it is landing. A plan targeting a critical signal with a stalled completion rate is a different priority than a low-completion plan targeting an info-level signal.

Median days to acknowledge (median_days_to_acknowledge)

What it is. The median number of days between when a plan was pushed to a membership and when that membership acknowledged it, calculated across every membership that has acknowledged so far.

How it is calculated. For each adoption row that carries an acknowledged_at timestamp, the cron computes the whole-day gap from pushed_at, then takes the median across all of those gaps and rounds to a whole number. Memberships that have not yet acknowledged are not part of the calculation; they neither pull the median up nor down.

Where you see it. On the Scoreboard, in the tile meta line. On Top Performers it reads "median Nd to acknowledge" (falling back to "live since [date]" if no membership has acknowledged yet). On Need Diagnosis it reads "Nd median ack, review friction" (falling back to "Awaiting acknowledgment"). In the plan detail view, as "Median time to acknowledgment: N days."

How to read it. This is your read on how quickly the network notices and opens a plan you push, independent of whether they act on it. A long median-to-acknowledge on an otherwise well-completed plan usually points at a distribution or visibility problem (memberships aren't seeing the push promptly), while a short acknowledge time paired with a low completion rate points at a substance or difficulty problem instead.

Median days to start (median_days_to_in_progress)

What it is. The median number of days between when a plan was pushed and when a membership's status moved to in_progress, calculated the same way as the acknowledge figure, across whichever memberships have started so far.

Where you see it. Only in the plan detail view, as "Median time to start: N days." It is not shown on the Scoreboard tiles.

How to read it. Read it beside the acknowledge figure. A short gap between acknowledge and start means memberships open the plan and get moving right away; a wide gap between the two suggests the plan is being seen and set aside, worth a nudge before it stalls out entirely.

The three signal-tone colors on the Scoreboard

The Scoreboard tiles use tone as a fast visual read of adoption performance, separate from and simpler than the raw severity field above. On the All Active Playbooks row, tile color is set per plan by its completion rate: 75% or higher renders in the Expand signal green, 40% up to 75% renders in the Maintain signal yellow, under 40% renders in the Analyse signal red, and a plan still reading "Awaiting cron" renders in the neutral copper tone. On Top Performers, every tile renders in Expand green regardless of its exact number, since qualifying for that row already means it is among your strongest completion rates. On Need Diagnosis, every tile renders in Analyse red at a heightened visual intensity, since membership in that row already means completion is under 40% on a plan old enough to judge fairly.

What "franchisee" and "membership" mean in these counts

Every count on this page, whether it is the affected-of-total reading or the pushed/acknowledged/completed rollup in the plan detail view, is a count of memberships in your network, never a named individual reading unless your network's entity model has been set to same-entity ownership. In the default posture, per-membership names shown alongside adoption status are anonymized labels, not raw location names. HQ sees how many memberships are where in a plan's lifecycle; HQ does not see the underlying business data, jobs, financials, or client records, that led any single membership to acknowledge slowly, decline, or complete quickly. The nightly cron aggregates across the network; it never surfaces one membership's private operating detail as the reason behind its number.

Heads up

Do not read a single membership's slow acknowledgment or low completion as a performance verdict on its own. These fields are network health signals for you as the plan's author, not a report card meant to be quoted back to any one membership without the fuller context you'd get from a direct conversation.

Quick reference table

| Field | Populated from | Requires a target signal? | Shown on Scoreboard | Shown in plan detail | |---|---|---|---|---| | Adoption completion rate | Adoption rows, status = completed share | No | Yes (tile label) | Yes | | Affected of total franchisees | Latest matching the network rollup row | Yes | Yes (tile sub-line) | Yes | | Signal severity | Latest matching the network rollup row | Yes | No | Yes | | Median days to acknowledge | Adoption rows, pushed_at → acknowledged_at | No | Yes (tile meta line) | Yes | | Median days to start | Adoption rows, pushed_at → started_at | No | No | Yes | | Decoration refreshed at | Cron write timestamp | No | No | Yes ("refreshed [date]") |

  1. 1Open a plan whose tile still reads "Awaiting cron" and confirm whether it has a target signal bound to it (visible in how the plan was authored). If it does not, the affected-count and severity fields will always stay empty; only the adoption-pace fields will populate.
  2. 2Give the nightly sweep at least one full cycle before treating a missing number as a problem. Large networks can take more than one 10-minute tick to fully sweep.
  3. 3Once numbers appear, read completion rate and affected-of-total together, not separately, to judge whether the plan is actually resolving the condition it targeted.
  4. 4Use median-to-acknowledge and median-to-start together to tell a distribution problem (slow to notice the push) apart from a substance problem (notices quickly, doesn't act).

Related reading

Data sources

  1. 1.`hq-aggregate-refresh` cron job (decision-plan decoration routine). Your network.
  2. 2.Your decision plans and their per-membership adoption records. Your network.
Was this helpful?