Distinct Closure Status for Unreviewed Applications

Give the ATS a terminal status for an application closed without a human opening it, distinct from the one used for a reviewed decline, bind it into the notification template, and count it on the requisition.

Intervention I-010 Actor: ATS vendor Scope: ecosystem Cost: medium Evidence: supported

On the canonical path

Machine work stays mechanical — Automation deduplicates, extracts and orders. It does not decide. Where a rule does end an application, the rule is stated and it is one a person would defend out loud.

This entry is one of the things that holds that commitment up.

What it looks like when this intervention is in place

Composite excerpts, written to be typical rather than copied. No particular message, company or person is quoted here.

The status the batch writes, and where the count lands reconstruction

Title: Requisition #4471 — queue closure

config Terminal statuses: reviewed_advanced · reviewed_declined · closed_unreviewed · closed_with_requisition. A record does not leave the queue without one of them.
02:00 Scheduled job expire_stale_applications — 312 matched; human_open recorded on 0 → status closed_unreviewed
02:01 Notice sent, status bound into the template: "Your application was not reviewed before this search closed. No assessment of your profile was made."
requisition dashboard Requisition #4471 — received 640 · opened 219 · closed unreviewed 421

What to notice: The batch is the same batch. What changed is that the status it writes separates a record nobody opened from one that was declined, and the count of the first sits on the same dashboard as applications received.

What this targets

Expected effects

M-020 can no longer write the value used for a decision: the expiry job writes closed_unreviewed, and the notification template carries that status
The gap M-009 runs on becomes a figure on the requisition — applications closed unopened are counted where applications received already are
B-003 leaves a state that can be read from outside: not reached, reviewed and not advanced, or closed with the search

What to measure

unreviewed_at_close_rate
time_to_first_human_open_days
closure_status_coverage

From each side

The same entry from inside each position that meets it: what reaches them, what it means from there, and what happens next given what they control.

ATS vendor

What reaches them: A status vocabulary in which every way a record leaves the queue has its own terminal value, and the migration that splits the existing Rejected in two.
What it means from there: The split is a schema change and a template variable; what it exposes — how much of the queue was never opened — becomes a figure in every customer's dashboard.
What happens next: Ships the statuses and the counter, makes the terminal status a required variable in the notification template, and carries the customers whose reporting was built on a single Rejected value.

Recruiter

What reaches them: The requisition dashboard carrying received, opened and closed-unreviewed side by side, and the expiry batch landing in the third column.
What it means from there: How far the queue ran past the week is a published figure on the requisition rather than a condition of the job. Time-to-fill is still what the report is read for.
What happens next: Works the current inbound with the count standing next to it; where the count is argued about, it is argued about against the recruiting headcount that fixes review capacity.

Candidate

What reaches them: A notice naming the status the record ended in, and whether a person opened it.
What it means from there: A record nobody reached and a record that was assessed and declined no longer arrive in the same words; only one of the two says anything about the profile.
What happens next: Reads the message for the status rather than for an assessment it states is not there, and decides about reapplying on that.

Share card png This page as markdown json