Hires and retention checkpoints

What this tab is

A hire is only a good decision if the person is still doing the job months later. The Hires + Retention tab is where Verinode turns your hiring history into a set of retention rates, checkpoint by checkpoint, and compares the ones that matter most against your peer cohort. It also holds the one manual habit that makes the whole tab work: logging what actually happened to a hire at 30, 90, 180, and 365 days out.

Verinode does not decide whether a hire worked out. It reads what you log at each checkpoint, retrospectively scores the hiring decision through a specialist reviewer, and rolls the outcome into your own retention rates and, anonymized, into the peer benchmark. You make the call on each hire; Verinode keeps the record straight and shows you how it compares.

Where to find it

Open Recruiting from the sidebar (route /recruiting). Recruiting is a switchable section and a Premier feature; see Recruiting: overview and how the section works if you haven't turned it on yet or are seeing an upgrade prompt instead of live data.

From the Recruiting home view, either click the Retention 90d tile in the Explore row, or open the cards slider (click any tile) and select the Hires + Retention tab in the tab strip: Findings, Open Roles, Applicants, Pipeline, Talent Pool, Hires + Retention, Benchmarks.

The four checkpoint cards

At the top of the tab, four cards sit in a row: 30-Day, 90-Day, 180-Day, and 365-Day. Each one answers a single question: of the hires who reached this checkpoint, what percentage were still retained?

Each card shows:

• A percentage, rounded to the nearest whole point (for example, "86%"). This is your operator-level retention rate at that specific checkpoint, not an overall average across all checkpoints.
• A dash when you don't have any checkpoint observations at that mark yet. No hire has to reach every checkpoint before the tab shows anything, each card computes independently from whichever checkpoints you've actually logged.

The 90-Day and 365-Day cards carry one more line: a peer comparison. It reads as a signed delta against the peer median, for example "+4.2 vs peer (82%, n=14)": your rate, minus the peer median, with the peer median and the number of contributing operators in parentheses. A positive delta (in green) means you're retaining better than the peer median at that checkpoint; a negative delta (in red) means you're behind it. The 30-Day and 180-Day cards never show a peer line, they report your own rate only, retention benchmarking is scoped to the 90-day and 365-day marks because those two windows are the ones the peer cohort tracks consistently.

The peer figure itself only appears once enough operators in the cohort have contributed retention data. Below that point, the card simply omits the peer line and shows your own rate on its own, there's no partial or estimated peer number shown early. This is the same cohort-minimum principle used across every benchmark in Verinode: a comparison built from too few operators would be more noise than signal, so Verinode waits until it means something before showing it. See How benchmarks work for the general mechanics.

The departures banner

If you've had at least one hire log a Departed status within the past 90 days, a bordered banner appears below the checkpoint cards, in the Ember Red family. It states the count plainly: "1 departure in the past 90 days" or "3 departures in the past 90 days" (the wording pluralizes correctly). Underneath, it explains what happens next: each departure runs through the retention-reviewer retrospectively, and failed hires feed back into your hiring-profile benchmark.

In plain terms: a departure isn't just a data point, it's a prompt for Verinode to look back at what the hiring signals said about that candidate before you hired them (their score at hire, certifications, experience) against what actually happened, and use that to sharpen how future applicants against similar roles get scored. If you have no departures logged in the last 90 days, the banner doesn't appear at all.

Awaiting Checkpoint: the list that drives everything

Below the banner (when there's data to show), an Awaiting Checkpoint section lists every hire whose next scheduled check-in has come due, sorted so the soonest-due checkpoint sits at the top, up to 20 at a time.

Each row shows:

• The hire's name.
• Hired [date] · Next: N-day, the date they were hired and which checkpoint is next in the sequence (30, 90, 180, or 365 days after the hire date). Checkpoints run in that fixed order, once a hire clears 30-day, the 90-day mark becomes their next one, then 180, then 365. After 365-day is logged, a hire drops off this list entirely.
• A Capture button.

Capturing a checkpoint

Clicking Capture on a row expands an inline form in place, no separate page or modal:

1. Three status buttons: RETAINED, DEPARTED, and DEPARTING SOON (shown in uppercase with letter-spacing). Click one to select it; the selected option fills solid, the others stay outlined. Retained is the default selection when the form opens.
2. A Notes textarea, optional, placeholder text reads "Notes (optional), what you observed, what drove the status." Use it to record the actual reason, a wage gap you lost them to, a fit issue that surfaced late, or simply that they're thriving, so the retrospective has something concrete to work from.
3. A Team member id text field, required. This ties the checkpoint observation to the person's record on your team roster so retention data connects cleanly to their team-member profile elsewhere in Verinode.
4. Save and Cancel buttons. Save is disabled while a submission is in flight (it reads "Saving…"). Cancel collapses the form and clears the notes field without saving anything.

Save writes the checkpoint, hands it to the retention-reviewer specialist for a retrospective score, and triggers a cross-section signal: a departure emits a flight-risk-style signal to your Team section so the succession planner can react without waiting for its overnight run; a retained checkpoint at 90 days or beyond emits a bench-strengthened signal instead, reinforcing that the hire is holding. A confirmation line appears below the list once the save completes: "Saved. Retention-reviewer running…" If the save fails, whatever error came back from the server prints in its place instead, so you know exactly what didn't go through rather than a generic failure message.

Idempotent by design. If you capture a checkpoint for the same hire at the same checkpoint days twice, the second save overwrites the first rather than creating a duplicate row, so correcting a mistaken entry is safe, just capture it again with the right status.

How retention feeds benchmarks

Every checkpoint you log does three things:

1. Updates your own rate. The 30/90/180/365-day cards recompute from your full checkpoint history the next time the tab loads, no separate step required.
2. Runs a retrospective score. The retention-reviewer specialist looks at the hire's profile at the time you hired them (their applicant score, certifications, years of experience) against the checkpoint status and any notes you left, and produces a retrospective read on whether the hiring decision worked out. This consumes Intelligence Units, the same metering that applies to any other operator-initiated specialist consult in Verinode.
3. Contributes, anonymized, to the peer benchmark. Your outcome (never your name, never the applicant's) becomes one data point in the national retention benchmark that every operator's 90-Day and 365-Day cards compare against. Verinode never sells this data, or any operator data, to carriers: the value flows back to you and every contributing operator as a sharper comparison, not out to a third party. See How benchmarks work for the full mechanics of how contributions turn into a benchmark.

This is also why the tab's empty state exists the way it does: retention benchmarking depends entirely on operators actually capturing checkpoints. A hire sitting silently for a year with no checkpoint logged doesn't help your rate, doesn't get a retrospective score, and doesn't strengthen the peer benchmark for anyone.

Empty state

If you have no hires yet, or you have hires but haven't logged a single 30/90/180/365-day checkpoint, the whole tab shows one message in place of the cards and list:

"Retention retrospectives appear once you've hired and at least one 30/90/180/365-day checkpoint lands. Peer benchmarks unlock at cohort-min."

Nothing is broken, there's simply nothing to compute yet. The moment you log your first checkpoint on any hire, the relevant checkpoint card fills in.

Best-practice example

Say your 90-Day card reads 71% with a delta of "-9.3 vs peer (80%, n=18)", and the departures banner shows two departures in the past 90 days. Open the Awaiting Checkpoint list first: if several hires are overdue for their 30 or 90-day check-in, your true rate may be understated simply because good outcomes haven't been logged yet, capture those before drawing conclusions. Then look at the notes on the two departures you already logged, if both mention the same theme (say, a wage gap that surfaced after the offer), that's a signal to revisit your comp range on the requisition side, not just a retention problem in isolation. The retrospective score behind each departure, together with the applicant's original score at hire, is exactly the kind of feedback loop that should tighten how the next role in that family gets screened.

Related reading

• Recruiting: overview and how the section works
• How benchmarks work
• Reading a benchmark
• Benchmarks overview
• The decision workspace
• Understanding your margin