How to send bulk offer letters

Steps

1. 1

   Export approved offers

   Export approved offers only after compensation, start date, work location, reporting line, and employment type are signed off by the right HR, finance, and legal reviewers. Treat the CSV as the source for draft assembly, not as a place to resolve open offer terms. Use one row per candidate with stable headers such as `candidate_name`, `role_title`, `annual_salary`, `start_date`, `work_location`, `reporting_manager`, and `response_deadline`. Remove interview notes, compensation rationale, recruiter comments, and anything the candidate should not see. A common failure is exporting `start_date` as `06/15/2026` from a spreadsheet while the template expects `2026-06-15`; the rendered letter can produce a blank or inconsistent date. Fix the CSV before upload, not inside the template. Include decimal salaries like `155000.00` rather than mixed text such as `$155k`, because reviewers need a predictable field to compare against the approved offer record.

2. 2

   Prepare the letter template

   Open the reviewed offer letter wording and separate fixed language from candidate-specific data. Keep legal clauses, benefits language, contingencies, and at-will or probation wording under HR/legal control; replace only approved variable fields with Liquid, such as `{{ row.candidate_name }}`, `{{ row.role_title }}`, and `{{ row.start_date | date: '%B %-d, %Y' }}`. If a clause depends on employment type, use a reviewed conditional instead of editing rows by hand, for example `{% if row.signing_bonus != blank %}A signing bonus of {{ row.signing_bonus }} will be paid subject to the terms above.{% endif %}`. Do not use preview-only formatting filters for salary or dates; keep to stock Liquid and pre-clean the CSV values. If remote employees, contractors, and international hires require materially different language, create separate templates rather than hiding legal complexity inside one large conditional block.

3. 3

   Preview sensitive rows

   Preview the rows most likely to break the letter before generating the batch. Include a long candidate name like `Alexandra Montgomery-Santos`, a high salary such as `275000.00`, a remote work location, an unusual start date like `2026-12-28`, and any row with bonus, relocation, or visa language. Check that `{{ row.annual_salary }}` appears exactly where the approved compensation should appear and that dates, response deadlines, signer names, and line wrapping remain readable. Long names often push signature blocks or compensation tables onto a new page; fix the template spacing before the batch is routed. If a candidate has no signing bonus, confirm the conditional text disappears cleanly and does not leave a blank paragraph. Compare each preview PDF back to the recruiting tracker, not just the CSV, so the reviewer can confirm the draft reflects the approved offer terms before candidate-facing workflow begins.

4. 4

   Generate and route for approval

   Generate the draft offer PDFs only after the preview examples match the approved offer data and the wording has cleared the required HR/legal path. Download the batch and reconcile filenames against the source rows using a field like `offer_reference` or `candidate_email`; do not rely on candidate name alone, because duplicate names and preferred names create avoidable routing errors. Preserve the source CSV with the generated PDFs so the team can answer later questions about which value produced `{{ row.response_deadline }}` or a specific salary line. Route the documents through the normal approval or e-signature process before sending anything to candidates. If your workflow sends files to another system by webhook, include only approved draft outputs and verify that each downstream record receives the right candidate file. The generated PDF is an assembled draft; the decision to issue it remains with HR, legal, and the authorized signer.