How a Recruiting Firm Built a Daily Pipeline View

Why the desk view kept breaking

The operating record comes from a UK tech recruiting firm, 7 recruiters. Candidate and job data lived in the ATS, while interview dates, client replies, follow-up knowledge, and exceptions also lived in recruiter inboxes, memory, and shadow trackers.

A flat candidate card was not enough. The same person could be active against several roles and clients, and each submission needed its own stage, owner, interview history, and latest movement.

Modeling submissions instead of flattening candidates

The workspace used the submission as the operating unit. Candidate search could isolate every active process for one person, while role and client labels plus a multi-role indicator kept those opportunities distinct.

The delivered views covered candidate submissions, live roles, tasks, going-cold reminders, interviews, guarded inbox updates, and agency analytics. These capabilities document the system's origin, but they do not all ship inside the standard $4,500 package.

What recruiters asked for after daily use

Recruiters asked for interview groupings that matched desk decisions: today, upcoming, recently completed, and unscheduled. A third-interview stage was added between second and final, and completed dates remained visible so a past interview did not appear to be waiting for a date.

Daily use also sharpened cross-role search and card context. Operators could see each role and client process without guessing which opportunity a stage referred to.

Guarding inbox-driven stage changes

Client email could propose stage movement, but updates had to verify candidate, company, and active role context first. One unambiguous match could proceed; multiple matches, wrong-role context, or low confidence failed closed for manual review.

The workflow did not auto-place candidates. Its boundary was a guarded record update with an audit trail.

Completeness, recovery, and freshness

After the tracker crossed more than 1,000 submissions, explicit pagination fixed a silent omission caused by a record ceiling. The official PostgreSQL documentation notes that LIMIT/OFFSET pagination needs an ORDER BY that constrains rows into a unique, predictable order. Source-freshness visibility then made the last successful sync part of the operating view rather than an invisible backend detail.

One documented catch-up processed 73 submissions, 30 candidates, 48 jobs, and 35 clients with 0 errors. A separate-host freshness watchdog runs every 15 minutes and was proven through an alert and recovery transition.

The exact connector login trigger remained unconfirmed. A dedicated automation credential issue also remains unresolved, so the record does not claim a vendor login change, a permanent credential fix, or permanent uptime.

What was verified

During the verified production bridge, 824 ATS submissions were backfilled with 0 write errors. In a bounded attribution repair, 746 fallback-owned records were reassigned, leaving 0 unassigned in that repair.

The operating record contained 55 interviews in July 2026. From August 1 through August 9, 2026, it recorded 115 stage moves across 97 candidates and 17 interviews.

These numbers describe records observed and processing verified during dated periods. They do not establish value created by the system.

What was not measured

This record did not measure revenue, financial return, placement or fill-rate improvement, labor reduction, rescued outcomes, or placement causation. It also does not claim perfect accuracy, perfect completeness, or uninterrupted operation.

Those outcomes would require a separate measurement design. The evidence here is limited to delivered workflow behavior, observed records, bounded repairs, and dated processing checks.

Who this pattern fits

This pattern fits recruiting and staffing agencies where candidate submissions, interviews, client feedback, and follow-up ownership do not resolve into one dependable daily view. It is especially relevant when one candidate can hold several live role and client processes.

See the current Recruiting OS package for the fixed base scope. Connector development, write-back, historical backfill, and custom mapping remain separately scoped.

What I would revisit

I would replace session-bound authentication with supported client-owned automation credentials where the source system permits it. That work remains unresolved and should be confirmed during connector discovery rather than assumed inside the five-day install.

To discuss workflow fit and supported access, book a Recruiting OS fit call.