Verification SLIs That Stop Support Fires Before They Start

It is 9:12 AM. A candidate in a different timezone is 4 minutes into a "2 minute" verification, their interview is in 8 minutes, and they just opened their third chat ticket. The recruiter pings Support, the hiring manager asks for an exception, and someone suggests "just let them through and verify later." In that moment, you are balancing three failure modes: funnel leakage (candidate drop), false rejects (legit candidates blocked), and silent accepts (fraud passes because you weakened the gate). Without SLIs and SLOs, every one of those looks like a one-off fire instead of a predictable system behavior.

Start with two SLIs because they map directly to Support pain and business risk: verification latency and decision confidence. Verification latency SLI: time from "verification started" to "decision issued" for the full flow (document + face + voice if applicable). Measure p50, p95, and timeout rate. Segment it by device type, geography, and risk tier so you can see where candidates actually get stuck. Decision confidence SLI: a normalized score (or bands) that expresses how strongly the system believes the identity and liveness checks are valid given the available evidence. The key is to include an explicit "unknown" state for partial evidence or degraded signals. Unknown is not failure, but it must trigger a controlled fallback. Why this matters now: 31% of hiring managers report they have interviewed someone who later turned out to be using a false identity. Directionally, that implies identity risk is common enough to reach normal hiring workflows, not just edge cases. It does not prove your company has the same prevalence, and it is self-reported survey data, so treat it as a risk signal, not an incident rate.

Make ownership explicit or Support becomes the default owner of every ambiguous case. Owner model that holds up in escalations: Recruiting Ops owns the workflow design and SLOs, Security owns risk policy and audit requirements, Support owns incident response and candidate-facing escalations, and Hiring Managers are consumers of outcomes, not exception approvers. Automation vs manual: automation should handle the default path (pass, fail, unknown), and manual review should be reserved for unknown or contested cases under an SLA. Manual review is not a backdoor, it is a controlled step-up with evidence requirements. Sources of truth: the ATS is the canonical record of candidate stage and disposition, the verification system is the canonical record of identity state and evidence, and the interview platform is the canonical record of attendance and interview artifacts. If those disagree, you get duplicate tickets and un-defensible timelines.

Set SLOs by risk tier and funnel stage so you do not punish low-risk candidates or give attackers a predictable bypass. Risk-Tiered Verification: use passive signals first (device reputation, network anomalies, behavioral patterns) to assign a risk tier. Only then decide whether you need step-up checks like additional liveness prompts or secondary document capture. For Support, the key is predictability: high-risk tiers may tolerate slightly longer flows because they prevent expensive downstream cleanups, but the workflow must communicate expectations and have a fallback path. One real-world signal of scale: Pindrop reports 1 in 6 applicants to remote roles showed signs of fraud in one hiring pipeline. Directionally, that suggests remote workflows attract more adversarial behavior and deserve tighter monitoring. It does not mean 1 in 6 of your applicants are fraudulent, because pipelines, definitions, and roles vary.

This example shows how to encode SLIs, SLOs, and escalation routing by risk tier, including a manual review SLA and an explicit unknown bucket. Treat the numeric thresholds as illustrative until you baseline your own environment.

IntegrityLens AI is built for teams that need verification performance you can operate, not just a pass or fail result. It combines ATS workflow + identity verification + fraud detection + AI screening interviews + coding assessments into one defensible pipeline (Source candidates -> Verify identity -> Run interviews -> Assess -> Offer). TA leaders and recruiting ops teams use it to keep the funnel moving with Risk-Tiered Verification and clear fallbacks. CISOs use it to reduce identity and deepfake exposure with audit-ready Evidence Packs and SOC 2 Type II and ISO 27001-certified infrastructure controls. Support teams use it to cut ticket thrash by instrumenting latency, confidence bands, and SLA-bound manual review queues.

• Granting "one-time" bypass links when latency spikes (attackers trade them, Support becomes the distribution channel). - Collapsing unknown into pass to protect conversion (you remove the only state that can safely trigger a fallback). - Letting recruiters DM reviewers for exceptions (you create invisible decisions with no chain of custody).

Support needs a queueing model, not heroics. Route only edge cases to humans and enforce an SLA so escalations do not sprawl across teams. Use an SLA-bound manual review queue for unknown decisions, not for disagreements about hiring. Manual review should be limited to identity evidence quality (for example, glare on a document photo), not subjective judgment. Build an escalation ladder: L1 Support can see state, latency breakdown, and approved next step. L2 Trust and Safety reviewers can request a step-up check. Security is only paged on anomaly clusters (spike in unknown, spike in timeouts, repeated device fingerprints). Protect reviewer attention with idempotent workflows: every re-submission should replace the prior attempt cleanly (Idempotent Webhooks), and every attempt should be traceable without duplicates.

If you publish SLOs without answering these, you will create new escalations instead of reducing them.