Stage dwell times
Precise time-in-stage per candidate derived from the event stream, not from a manually updated status.
Where candidates move, and where they stall.
A recruitment analytics platform that turns an applicant tracking system's raw event log into a picture of where a hiring funnel actually leaks, with the bottleneck named rather than left to be inferred.
01 — The problem
The talent team ran a competent ATS and still could not answer basic questions. Time-to-hire was reported as a single company-wide average that hid a three-week gap between engineering and commercial roles.
Worse, nobody could see stalls while they were happening. A candidate sitting untouched for eleven days between a technical screen and an onsite only became visible when they withdrew.
02 — What we did
We rebuilt the funnel as a state machine over the ATS event stream, so every candidate has a precise dwell time in every stage rather than a status field that was last updated whenever someone remembered.
Then we made the product argue. Instead of rendering a chart and leaving interpretation to the reader, The Walt names the stage costing the most days, quantifies it against the team's own baseline, and links to the specific candidates sitting in it right now.
A dashboard that does not name the bottleneck is just a prettier spreadsheet.
Two of the screens that carry the most weight in daily use, rebuilt here from the production design system.
The product names the bottleneckRather than rendering a chart and leaving interpretation to the reader, the stage costing the most days is stated in words.
Ordered by riskThe daily view lists exactly which candidates need action today, ranked by how close they are to withdrawing.
Grouped by the job each set of capabilities exists to do, rather than by which team built it.
Precise time-in-stage per candidate derived from the event stream, not from a manually updated status.
Pass-through rates per stage, per role and per source, with confidence bands so small samples are not over-read.
This quarter against last, and this role family against the company baseline.
Which channels produce candidates who actually convert, rather than which produce the most applications.
The stage costing the most days is stated in words, with the size of the cost and the candidates affected.
Candidates exceeding the dwell threshold for their stage are surfaced while it is still recoverable.
Scheduling delay traced to specific panel availability instead of blamed on the process in general.
Withdrawals correlated with the stage and dwell time that preceded them.
A per-recruiter view of exactly which candidates need action today, ordered by risk.
A weekly email that states what moved, what stalled and what needs a decision.
Structured evaluation captured against consistent criteria so comparisons are meaningful.
Actions taken in The Walt sync back so the ATS stays the system of record.
Layer by layer, with the reason each one exists — because the reason is usually the interesting part.
Connectors poll ATS webhooks and history endpoints, reconstructing a complete event stream including backfilled history.
A state machine that replays events into per-candidate stage transitions, producing dwell times that survive out-of-order delivery.
Pre-aggregated rollups per role, stage and cohort, refreshed incrementally so dashboards stay fast as history grows.
Rule-based detection of stalls and bottlenecks, scored against each team's own historical baseline rather than an industry average.
React dashboard with server-driven charts and a digest mailer.
Technology
Measured against how the operation ran before, not against a benchmark chosen after the fact.
Time-to-hire fell from 34 days to 21. Most of the gain came from one scheduling stall the team had never been able to see.
Averages stopped hiding role differences. Each role family is measured against its own baseline.
Stalls became recoverable. Alerts fire while a candidate is still engaged rather than after they withdraw.
The ATS stayed the system of record. Write-back means the team did not end up maintaining two truths.
How it ran
Assessed ATS event completeness and found the history gaps that had to be backfilled.
State machine, event replay and dwell-time computation validated against manual reconstruction.
Rollups, baselines and the bottleneck detection rules.
Recruiter dashboard, digest mailer, scorecards and ATS write-back.
Phased by department with baselines established before any target was set.
One connected system for a warehouse that ran on paper.
A mobile-first ERP for warehouse and e-waste operations that replaced a decade of spreadsheets, paper travellers and radio calls with a single connected system that works on the floor..
Market data, sentiment and research in one investment workspace.
An AI investment-intelligence platform that pulls market data, news sentiment and analyst research into a single workspace, so an investment team can go from a question to a defensible answer without leaving the screen..
Clinical translation where a wrong word has consequences.
A translation platform built specifically for clinical settings, where general-purpose translation is not safe enough and a verified medical dictionary sits between the model and the patient..
Tell us what you run. We will reply within two business days with what we would build for your situation — and, just as usefully, what we would leave out.