17 Hires, 0 Pre-Start Ghosts, $1.62: The Post-Signature

By Lazar Milicevic · Published August 16, 2026 · 8 min read

Every ATS and monday.com recruiter agent stops the moment the offer is countersigned. That silence is where I was losing 23% of hires on the last cohort — counteroffers landed in the seven-day gap between signature and start date. Here's the agent I built to own that window, the exact architecture, and the token receipts.

The gap every recruiting stack ignores

The post-signature to day-one window is where hires quietly evaporate — 23% of my last cohort updated LinkedIn within 72 hours of signing and fielded a counteroffer before they ever received a laptop. Every tool in the recruiting stack optimizes the funnel up to signature. Sourced, screened, interviewed, offered, signed. Green dashboard. Then nothing. No equipment ticket, no Slack invite, no payroll form, no manager intro, no welcome doc.

The old employer, meanwhile, sees the LinkedIn update within a day and starts a counter. You're not competing with the market anymore — you're competing with a manager who has a week of unopposed access to someone you already spent about $4,000 closing (recruiter time, interview loops, offer negotiations). If one in four walks, your true cost-per-hire is 33% higher than your ATS reports.

The lesson from running this end-to-end: the bottleneck isn't screening 500 resumes. It's the 168 hours between signed and started. Nobody automates that window because it doesn't feel like a "recruiting" problem — it sits between HR, IT, finance, and the hiring manager, and everyone assumes someone else is running it.

Trigger and state: DocuSign → n8n → Supabase

The whole system runs off a single source of truth: one row in a Supabase table called onboarding_state, written the moment the offer is countersigned in DocuSign. Every subsequent agent run reads and writes to that row, which kills the two problems that break most multi-step agent workflows — lost context and duplicated messages.

DocuSign fires a Connect webhook on envelope completion. n8n receives it, extracts candidate fields, and inserts:

create table onboarding_state (
  id uuid primary key default gen_random_uuid(),
  candidate_name text not null,
  candidate_email text not null,
  start_date date not null,
  role text not null,
  location text not null,
  manager_email text not null,
  equipment_profile text,
  interview_notes text,
  day_count int default 0,
  status text default 'day_zero',
  sentiment_score jsonb,
  last_touchpoint_at timestamptz,
  created_at timestamptz default now()
);

The status field only ever has four values: day_zero, active, flagged, started. The day_count gets incremented by whichever cron ran last. sentiment_score stores the JSON from the day-three sensor. That's it — no separate tables for messages, no external state store. If an agent crashes mid-run, the next cron just reads the row again and picks up.

Why Supabase and not a Google Sheet? Two reasons. Row-level locking so two crons can't collide on the same candidate, and a real SQL layer so the day-N query is a one-liner instead of a full-sheet scan.

The six-day cron sequence

Six n8n cron triggers, one per day from day one through day six. Each cron runs at 9 a.m. local, queries Supabase for day_count = N AND status = 'active', and fires a Claude agent per matching row with a day-specific job. Splitting into six discrete crons instead of one long workflow means a failure on day three doesn't block day four for other candidates.

Here's what each day actually does:

Day one is where the operational commitments show up. The agent reads role and location, picks the laptop spec from a config file (a senior engineer in Austin gets a different SKU than a support rep in Denver), files the IT ticket with the shipping address, provisions the Google Workspace account, and drops the hire into the right Slack channels with a founder-signed intro. The candidate wakes up on day two knowing their laptop is on the way and sees a welcome from the CEO in #new-hires. That single sequence kills 60% of the counteroffer temptation on its own.

Day two is the boring but critical one — payroll forms specific to their state and employment type (W-2 vs. 1099 vs. international contractor), a pre-filled DocuSign envelope so they're not hunting for their SSN in three tabs, and finance CC'd so nothing falls through.

Day three: the sentiment sensor

Day three is the only touchpoint designed to generate a reply, and the reply is the sensor for the whole seven-day window. The agent writes a short, non-templated note from the hiring manager that references something specific from the interview notes and asks one open question. When the candidate replies, sentiment analysis fires and either lets the sequence continue or triggers a recruiter alert.

The generation prompt is boring on purpose:

You are drafting a short check-in email from {manager_name} to {candidate_name}
who signed 3 days ago and starts on {start_date}. 

Read these interview notes and reference ONE specific thing they said they were
excited about. Do not use the word "excited." Do not use "just checking in."

Ask exactly one open-ended question that invites a real reply, not a yes/no.

Notes: {interview_notes}

Keep it under 80 words. Sign as {manager_name}, no title, no signature block.

Reply comes back into a separate n8n webhook. That webhook runs a second Claude call with a structured output prompt:

Rate this candidate reply on three dimensions, 1-5:
- excitement (5 = clearly energized, 1 = flat/perfunctory)
- hesitation (5 = raising doubts/concerns, 1 = none detectable)
- specificity (5 = engaged with the specific question, 1 = generic response)

Return JSON only: {"excitement": N, "hesitation": N, "specificity": N, "signal": "..."}

Reply: {reply_body}

Rules are hardcoded in the next n8n node: if excitement < 3 OR hesitation > 3, flip status to flagged and fire a Telegram message to the recruiter with the candidate name, the reply, the JSON scores, and a one-paragraph rescue script generated on the fly from what the candidate actually said. The agent doesn't try to save the hire. It hands the recruiter a warm intervention with the exact language to use.

Day three is also the most expensive step by a mile — 91¢ of the total $1.62 cohort spend, because the sentiment call carries the full interview notes as context.

Escalation logic and the human handoff

Automation stops the moment there's a real signal. Two escalation triggers fire independently of the cron schedule: 48-hour silence on any touchpoint, or a sentiment score outside the safe band on day three. Both route to the recruiter's Telegram with everything they need to act in one message.

The silence detector is a separate n8n workflow that runs every 6 hours:

// n8n Function node
const now = new Date();
const stale = items.filter(row => {
  const last = new Date(row.json.last_touchpoint_at);
  const hours = (now - last) / 36e5;
  return hours > 48 && row.json.status === 'active';
});
return stale.map(r => ({ json: r.json }));

Each stale row triggers a Claude call that reads the last message sent, the candidate's role, and their interview notes, then drafts a suggested outreach in the recruiter's voice. Telegram message goes out with candidate name, days since last contact, the last message sent, and the suggested reply. The recruiter taps once, edits if needed, sends.

On the last cohort of 17 hires, four Telegram alerts fired. The recruiter intervened on three of them. All three signed on to day one. The fourth was a false positive — the candidate was on a pre-start vacation and replied warmly two days later. That's the ratio I want: the system errs slightly toward escalation, because a false positive costs 90 seconds of recruiter attention and a false negative costs $4,000.

What the numbers actually looked like

• 17 hires processed end-to-end
• 43 automated touchpoints delivered (some hires triggered fewer than 6 based on role/location)
• 0 pre-start ghosts (down from ~4 expected at the historical 23% rate)
• $1.62 total in Claude tokens across the whole cohort
• 91¢ on day-three sentiment runs, 48¢ on welcome doc generation, 23¢ on everything else
• Runs on a Raspberry Pi 4 next to the main server, ~$0 infra beyond electricity

At $1.62 in tokens versus 3 counteroffers saved at ~$4,000 sunk cost each, the ROI math is not close.

Why bizflowai.io helps with this

Post-signature onboarding is exactly the kind of cross-system workflow bizflowai.io already builds for SMB clients — the boring wiring between DocuSign, an ATS, IT ticketing, Google Workspace, Slack, and finance that nobody on a 10-person team has time to own. When we ship an onboarding agent, it looks like the architecture above: one state row per hire, discrete daily jobs, sentiment on the human touchpoints, and Telegram escalation to a real person when something goes off-script. No dashboards to check, no rules engine to maintain — just receipts in a Supabase table and alerts when the recruiter needs to step in.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.