How to Pilot Offboarding Automation: A Step-by-Step Blueprint to De-Risk Your HR Strategy

A successful offboarding automation pilot runs eight to twelve weeks, covers voluntary resignations in a single department, and tracks four KPIs from day one. Build and test in Make.com, set a clear expansion trigger before launch, and align HR, IT, Finance, and Legal on scope before you configure a single workflow.

Full-scale offboarding automation deployment without a prior pilot is one of the most reliably expensive mistakes HR and IT teams make. Integration failures, missed compliance triggers, and stakeholder resistance that could have been isolated in a controlled test instead surface across the entire workforce on day one of go-live. The antidote is a structured pilot: narrow scope, pre-set KPIs, and a defined expansion trigger. This post walks through exactly how to build and execute one.

For the strategic case for why offboarding automation should be your first HR project — not your third or fourth — see Why Offboarding Automation Must Be Your First HR Project. This satellite is the operational complement to that argument: the step-by-step execution plan once leadership is aligned.

Before You Start: Prerequisites, Tools, and Risks

Before configuring a single workflow in Make.com, confirm these prerequisites are in place. Missing any one of them is the most common reason pilots stall before generating usable data.

• HRIS access with termination event triggers: Make.com must receive a real-time signal — not a nightly batch — when a termination record is created. Confirm this with your HRIS administrator before scoping begins. Most modern HRIS platforms expose a webhook or API endpoint; if yours requires a polling workaround, document that gap now.
• IT system inventory: You need a current map of every application, directory, and physical access point the average employee in your pilot cohort holds. Without it, your access revocation workflow is incomplete by definition. This is where running an OpsMap™ discovery session pays for itself before a single scenario is built.
• Stakeholder alignment document: HR, IT, Finance, and Legal must agree on pilot scope, success threshold, and expansion trigger before launch. A one-page document signed by each team lead prevents post-pilot scope debates.
• Baseline metrics: Measure your current manual offboarding performance — time-to-access-revocation, task completion rate, HR hours per exit, asset recovery rate — before the pilot runs a single event. Without a pre-pilot baseline, you cannot prove ROI.
• Time budget: Allocate eight to twelve weeks for the pilot window and run a minimum of fifteen to twenty offboarding events before treating the data as reliable.
• Risk awareness: The two highest risks during a pilot are (1) an integration failure that leaves access unrevoked on a live exit, and (2) a workflow misconfiguration that fires payroll actions out of sequence. Both must be caught in a Make.com test scenario before any live employee runs through the system.

If you are inheriting a broken HR operation and are not sure where the biggest gaps are, the 11 Warning Signs Your Inherited HR Operation Is Bleeding Money is a useful pre-read before you define pilot scope.

Step 1 — Define Scope: Choose One Departure Type and One Business Unit

The pilot scope decision is the single most consequential choice you will make. Get it wrong and every metric that follows is noise.

Select voluntary resignations within one department or location as your pilot cohort. Voluntary exits follow a predictable, documented sequence: resignation acceptance → two-week notice period → last day → post-departure steps. That predictability is what makes them the right pilot vehicle. Involuntary terminations, contract expirations, and retirements each introduce variables — legal review timelines, severance sequencing, benefit continuation rules — that contaminate your baseline data when mixed into the same cohort.

One department gives you a single manager population to train, a manageable IT asset set to map, and a contained set of HRIS records to test against. When the inevitable integration edge case appears — and it will — you want to isolate it in a ten-person cohort, not discover it affects your entire company.

Disqualifying a department from the pilot: If a department has fewer than eight voluntary exits per year, it will not generate enough events to produce reliable data in your pilot window. Pick a higher-volume team.

Step 2 — Map the Workflow Before You Build It

Document every step in your current manual offboarding process before you open Make.com. Every handoff, every system, every person who touches a departure event — write it down. This is the foundation of the OpsMap™ approach: you map before you build. Automating a broken process produces broken automation faster.

Your map should answer these questions for each step:

• Who is responsible for this action?
• What system or tool does this action touch?
• What is the trigger — what causes this step to start?
• What is the deadline — is there a regulatory or policy clock running?
• What happens when this step fails or is skipped?

The 7 Questions to Ask Before You Automate Anything covers this diagnostic in detail. Run through it for every step on your map before scoping your Make.com scenario.

Once mapped, mark each step as: automate (no judgment required, same action every time), assist (automation handles the task, human confirms), or manual (regulatory, legal, or interpersonal — keep a human in the loop). Your pilot scenario handles only the “automate” and “assist” steps. The manual steps stay manual.

Step 3 — Build the Core Make.com Scenario

Your pilot Make.com scenario handles exactly three things: trigger detection, task generation, and access revocation initiation. Do not attempt to automate payroll, severance, or benefits in the pilot. Those carry the highest financial and compliance risk and belong in Phase 2 once the core is proven.

The trigger: Connect your HRIS to Make.com via webhook or API watch module. The scenario fires the moment a termination record is created with a future last-day date. Use a filter to limit to your pilot department.

Task generation: For each termination event, the scenario creates a task checklist in your project management system — one task per offboarding action, assigned to the responsible person, with a due date calculated from the last day. Every task gets a direct link back to the Make.com execution log so your team can trace any issue.

Access revocation initiation: The scenario sends an automated provisioning ticket to IT with the departing employee’s name, employee ID, last day, and the full list of systems from your IT inventory that require deprovisioning. This is a trigger, not a completion — IT still closes the ticket, but the delay between last day and ticket creation drops to zero.

Each module in your Make.com scenario needs a clear name, not the default “HTTP” or “Module 4.” Name every step what it does. Every external API call gets an error handler with three retry attempts at sixty-second intervals. Every outbound notification module includes the Make.com execution URL in the footer so your team can trace any issue back to its source run. These are non-negotiable defaults on every scenario, not just this one.

For a walkthrough of how non-technical HR teams approach building these scenarios from scratch, see How a Non-Technical HR Team Started Building Their Own Automations With Make + AI.

Step 4 — Set KPIs Before the First Live Event

Your four pilot KPIs — set in writing before the pilot runs — are:

1. Time-to-access-revocation ticket: Time from termination record creation in HRIS to IT receiving the provisioning ticket. Target: under five minutes. Your pre-pilot baseline is probably measured in hours or days.
2. Task completion rate: Percentage of auto-generated offboarding tasks marked complete within the required window. Target: match or beat your manual baseline in week one, improve by week eight.
3. HR hours per offboarding event: Time HR staff spends on administrative coordination per departure. This is the ROI number your CFO will want. Measure it manually for the three months before the pilot, then compare.
4. Escalation rate: Percentage of pilot events that require a human to intervene in a step the scenario was supposed to handle automatically. This is your integration quality score. Target: under ten percent by end of pilot.

Publish these KPIs in your stakeholder alignment document before launch. Do not add KPIs mid-pilot — that is how scope creep starts.

Step 5 — Run the Pilot and Manage Exceptions

For the first five pilot events, have your Make.com scenario fire but require a manual confirmation before any external system receives a message. Watch every execution log. Verify that the task list generated matches what your process map said it should generate. Verify that the IT ticket content is accurate and complete.

After the first five events without error, remove the manual confirmation gates and let the scenario run automatically. Continue reviewing execution logs daily for the first thirty days, then weekly for the remainder of the pilot.

Every exception — every escalation, every failed module, every ticket that had to be corrected — gets logged with three data points: what happened, which step failed, and what the root cause was. At the end of the pilot, this exception log is more valuable than your KPI dashboard. It tells you exactly what to fix before Phase 2 expansion.

The most common failure modes in offboarding automation pilots:

• HRIS webhook fires for the wrong employee types (contractors, temps) because the filter logic was not specific enough
• IT system inventory was incomplete — the scenario generates a ticket that omits two systems because they were not on the original map
• Task due dates calculate incorrectly for employees whose last day falls on a holiday or weekend
• Manager notifications route to the wrong person when a manager has been recently changed in the HRIS and the record has not been updated

None of these are catastrophic. All of them are fixable. All of them are far cheaper to find in a fifteen-person pilot than in a company-wide rollout.

Step 6 — Define the Expansion Trigger Before the Pilot Ends

Before your pilot runs its first live event, your stakeholder alignment document must answer one question: what does success look like, and what happens when we hit it?

A concrete expansion trigger looks like this: “If time-to-access-revocation averages under ten minutes, task completion rate exceeds 85%, and escalation rate falls below 15% across at least fifteen events by week twelve, we expand the Make.com scenario to all voluntary departures company-wide in Q3.”

Without a pre-set trigger, every stakeholder will have a different standard for “ready.” The pilot will drift. Legal will want one more review cycle. IT will want three more test events. Finance will ask for a cost projection that wasn’t scoped. Your pre-set trigger eliminates all of that.

If the pilot does not hit the trigger, it has still succeeded — it found the gaps before they became company-wide problems. Document what failed, fix the root causes in the Make.com scenario, and run a second pilot cohort with the corrected build.

What to Automate in Phase 2

Once the core scenario has passed the expansion trigger, Phase 2 adds three additional workflow layers:

• Asset recovery: Automated equipment return shipping label generation and IT asset tracking update on confirmed return
• Benefits termination notification: Scheduled COBRA and benefits carrier notification triggered automatically from the last-day date, with a human-in-the-loop confirmation step before the carrier message sends
• Exit survey delivery: Automated survey link delivered to the departing employee’s personal email on their last day, with manager notification if the survey is not completed within five business days

Payroll sequencing and severance calculations do not belong in Make.com automation until your legal and finance teams have reviewed and signed off on the logic. The cost of an error in those workflows is not recoverable in the same way a missed task reminder is.

For the Make.com infrastructure changes that unlock this level of HR automation, 6 Ways the Make MCP Changes Automation Work for HR Teams covers the shift in build speed and complexity that comes with AI-assisted scenario construction.

The Pilot Readiness Checklist

Before your pilot launches, confirm every item on this list is in writing and signed off:

• Pilot cohort defined: one departure type, one department or location
• HRIS webhook or API trigger tested and confirmed in a non-production environment
• IT system inventory complete and reviewed by IT lead
• Make.com scenario built, named, error-handled, and tested against synthetic data
• Four KPIs documented with pre-pilot baseline numbers
• Expansion trigger written and signed by HR, IT, Finance, and Legal leads
• Exception logging process defined — who owns it, where it lives, how often it is reviewed
• Rollback plan documented — if the scenario produces an error on a live exit, who kills it and how fast

If any item on this list is missing, the pilot is not ready to launch. A delayed start costs days. A premature launch with a gap in this checklist costs weeks of cleanup and resets stakeholder confidence.

Next Steps for HR Teams Ready to Move

If your HR team is evaluating where offboarding automation fits inside a larger operations cleanup, the OpsMesh™ framework structures that decision. The OpsMesh overview explains how discovery, build, and ongoing care work together as a system rather than a one-time project.

For teams starting from scratch on HR operations triage, Drowning in Admin: How Solo and Small HR Teams Can Fix Broken HR Operations Without Burning Out covers the prioritization framework before any automation work begins.

Offboarding automation is not a large project. A well-scoped Make.com pilot built by an experienced team runs in weeks, not quarters. The structure above is what separates pilots that generate reliable data from pilots that generate stakeholder doubt. Run it right the first time.