11 New-Hire Docs in 4m08s for 31¢ — n8n + Claude

By Lazar Milicevic · Published September 15, 2026 · 7 min read

Every HR automation tutorial covers sourcing, screening, scheduling — the stuff before the yes. Nobody automates the paperwork swamp after the yes. Here's the exact n8n + Claude workflow that generates the full onboarding packet in 4 minutes 8 seconds for 31 cents in tokens.

The problem nobody's building for

A twelve-person agency hires roughly one person a month. Every hire, the ops lead burns half a day generating eleven documents:

• Offer letter
• NDA
• Contractor or W-2 form
• Equipment request
• IT access checklist
• Benefits summary
• Direct deposit form
• Emergency contact form
• Employee handbook acknowledgment
• Day-one agenda
• Manager intro doc

Every doc lives as a Google Docs template. Every one needs the same six fields swapped in: name, start date, manager, salary, equipment tier, office or remote. Then each gets exported to PDF, dropped in a Drive folder named after the hire, and three of the eleven (offer letter, NDA, direct deposit) go into DocuSign.

Four hours of copy-paste. Every hire. Multiply that by twelve hires a year at a $40/hr fully-loaded ops rate and you're spending $1,920/year to Ctrl-C-Ctrl-V documents.

The big HR platforms don't fix this. They sell the sourcing/screening/scheduling triangle because that's where enterprise budget sits. Under fifty employees, you don't need help screening 500 resumes — you need help with the paperwork bloat between accepted offer and day one. And no HRIS I've tested will let you keep your own Google Docs templates without shoving you into their template editor, their signature product, their onboarding wizard. You pay platform tax for a workflow you can wire yourself in an afternoon.

The trigger: one row of structured data

The workflow starts with a Google Sheet as the source of truth. One row per candidate, one status column. When the ops lead flips a row to Offer Accepted, an n8n webhook fires.

You can swap Google Sheets for a Notion database or Airtable base — whatever your team already lives in. The trigger just needs to hand off one row of structured data. Here's the payload shape I use:

{
  "candidate_name": "Jordan Reyes",
  "start_date": "November 12",
  "manager": "Priya Shah",
  "salary": "$92,000",
  "equipment_tier": "Tier 2 (MacBook Pro 14, 32GB)",
  "location": "Remote — Austin, TX",
  "employment_type": "W-2",
  "candidate_email": "jordan@example.com"
}

That's it. No cleaning, no normalization. The ops lead types it however they type it and moves on.

What each field feeds

• candidate_name → folder name, all eleven docs, DocuSign signer
• start_date → offer letter, day-one agenda, IT access ticket
• manager → manager intro doc, IT access approver
• salary → offer letter, direct deposit form
• equipment_tier → equipment request, IT checklist
• location → handbook acknowledgment (state law varies), benefits summary

The merge-field extractor: Claude, not regex

The webhook payload lands in a Claude node with a small prompt: read this row, return a JSON object with these six keys, normalize the dates to ISO format.

I use Claude here instead of raw JavaScript because half the time the ops lead types the start date as November 12 and half the time as 11/12/2026, and I don't want to babysit regex. Claude normalizes it every time.

You are a data normalizer. Read the input row and return a JSON
object with EXACTLY these keys:

  name          — full name, title case
  start_date    — ISO 8601 (YYYY-MM-DD)
  manager       — full name, title case
  salary        — string, format "$XX,XXX"
  equipment_tier — one of: "Tier 1", "Tier 2", "Tier 3"
  location      — string, "Remote — City, State" or "Office — City"

Return ONLY the JSON object. No prose.
Input row: {{ $json }}

Token cost on this call: ~800 in, ~200 out. Under a cent per hire.

The reason this beats a JavaScript node isn't just date parsing. It's that six months from now, when someone adds a new equipment tier or the salary field starts showing 92k instead of $92,000, the prompt still works. Regex breaks silently. LLM extraction fails loudly enough that you notice.

The template loop: batchUpdate is the whole engine

In Drive I keep a folder called new-hire-templates with eleven Google Docs. Every doc has merge fields written as double curly braces: {{name}}, {{start_date}}, {{manager}}, {{salary}}, {{equipment_tier}}, {{location}}.

The n8n loop does three things per template:

1. Copy the template file into a new folder named Onboarding — {{name}} — {{start_date}}
2. BatchUpdate the copy, replacing every merge field with the values Claude extracted
3. Export the populated doc to PDF via the Drive export endpoint

The Google Docs batchUpdate call is the actual engine. Here's the request body for one document:

{
  "requests": [
    { "replaceAllText": {
        "containsText": { "text": "{{name}}", "matchCase": true },
        "replaceText": "Jordan Reyes"
    }},
    { "replaceAllText": {
        "containsText": { "text": "{{start_date}}", "matchCase": true },
        "replaceText": "2026-11-12"
    }},
    { "replaceAllText": {
        "containsText": { "text": "{{manager}}", "matchCase": true },
        "replaceText": "Priya Shah"
    }}
  ]
}

Six replacements, one API call per document, roughly 400ms each. Eleven documents finish in under five seconds of real API time. The rest of the runtime is Drive giving you file IDs back.

Why keep the editable Google Doc, not just the PDF

• Managers occasionally want to tweak the day-one agenda after seeing it
• Legal sometimes wants a redline on the NDA before it goes to signature
• If a merge field looks wrong, you fix the doc directly instead of rerunning the workflow

The editable version and the PDF both land in the candidate's folder. Two artifacts per doc, twenty-two files total, zero manual work.

The signature push and the notification

Three of the eleven docs need signatures: offer letter, NDA, direct deposit form. Those get pushed to DocuSign through the Envelopes API with the candidate's email as the signer.

{
  "emailSubject": "Welcome to Acme — please sign",
  "documents": [
    { "documentId": "1", "name": "Offer Letter.pdf", "fileExtension": "pdf",
      "documentBase64": "{{ $binary.offer_letter_pdf }}" }
  ],
  "recipients": {
    "signers": [{
      "email": "jordan@example.com",
      "name": "Jordan Reyes",
      "recipientId": "1",
      "tabs": {
        "signHereTabs": [{ "anchorString": "/sig1/", "anchorUnits": "pixels" }]
      }
    }]
  },
  "status": "sent"
}

I use anchor strings (/sig1/, /sig2/, /date1/) in the template so DocuSign auto-places the signature and date fields wherever the anchor appears. No manual tab-placement per envelope.

The other eight docs are informational and just sit in the Drive folder for the candidate to read on day one.

Last step: n8n posts to the ops lead's Slack (or Telegram — the same node with a different credential). Message includes the folder link, the three DocuSign envelope IDs, and the total runtime.

Real numbers, no estimates

Here's the actual cost breakdown from my last production run:

Runtime from status flip to Slack notification: 4 minutes 8 seconds.

Compare that to four hours of a $40/hr ops person: $160 of labor replaced by 31 cents of infrastructure. At twelve hires a year that's $1,920 of ops time recovered for $3.72 in token and DocuSign spend. Payback on the afternoon it takes to build is one hire.

DocuSign is the only real variable. If you're under 100 envelopes a year, their pay-as-you-go pricing is fine. If you're doing volume, swap in an eSignature provider with better per-envelope economics or handle signatures through your existing HR platform if you already pay for one.

The reuse insight worth more than the workflow

Here's the part that matters if you already run any doc automation. This is the same template-merge engine that runs behind invoice generation for a small billing business: read a row, extract fields, populate a template, export a PDF, notify.

The only things that change between use cases:

• The template folder (invoices → new-hire packet → sales quotes → renewal notices)
• The merge field names (customer name → candidate name; line items → equipment tier)
• The notification destination (accounting Slack → ops Slack)
• Whether the output goes to eSignature or not

Twenty minutes of config to retarget the whole thing. If you already have a doc-gen pipeline running for invoices, contracts, or quotes, you can point it at HR onboarding by the end of today. If you don't, build it once for the use case that hurts most and you get the others nearly free.

That's the actual leverage. Not that new-hire packets got faster. That a small business can own one document automation primitive and apply it to every recurring paperwork bottleneck.

Where bizflowai.io fits in

At bizflowai.io I build this exact template-merge primitive for solopreneurs and small teams, then retarget it at whatever documents eat their week — invoices, onboarding packets, client reports, renewal notices, quotes. The workflow above is one of the standard patterns we ship, with the eleven templates and six merge fields swapped for whatever your team actually generates. If you want to skip the afternoon of wiring it yourself, that's what we do.

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.