4,000 applicants later: what actually broke in our recruitment funnel

The situation

The client recruits in cohorts. Applications open, a wave of people apply, and every applicant has to be screened, invited to an information session, interviewed, and given a decision. The information sessions run on Eventbrite. The CRM is HubSpot. The team is small.

Before we got involved, the process was held together by coordinators and memory. Someone read each application. Someone sent each session invite. Someone watched the Eventbrite registration list and copied names back into HubSpot. Someone noticed, or did not notice, when a registrant failed to show up. Someone sent the interview booking link. Someone updated the deal stage after each of these steps, by hand, if they remembered.

The constraint was plain: application volume was growing and headcount was not. The client did not want new software. They were already paying for HubSpot and Eventbrite, and the team knew both tools. Our job was to wire together what they already had. That is what most of our automation work looks like in practice: fewer new tools, more connections between the ones already paid for.

What we tried first

We built the obvious version. A HubSpot form created the contact and the deal. A Zap watched for new deals and sent the Eventbrite session invite. Registration moved the deal to Session booked. Attendance moved it to Attended. Attended triggered the interview scheduling link. A booked meeting moved the deal to Interview scheduled. Clean, linear, and it demoed well.

For the happy path, it stayed well. A first-time applicant who registered, showed up, and booked an interview never needed a human until the interview itself. The problem is that at volume, you stop getting only the happy path. Three edge cases did the damage.

Edge case one: people apply twice

Some people apply more than once. Months apart, or the same week, or with a different email address because the first one was a work account they no longer check. We had not planned for any of this.

There were two failure modes. With the same email, HubSpot deduplicated the contact correctly, but our new-application Zap fired anyway and created a second deal, because the deal creation step never checked for an existing open deal. One person, two deals, in two different stages of the same pipeline. With a different email, the person became a full duplicate contact, invisible to email-based matching, and went through the whole funnel a second time.

The version we had to apologize for: an applicant received a fresh information session invite while their other record sat at the interview stage. They asked, reasonably, whether anyone was reading their file. That question is what a duplicate record sounds like from the outside.

Edge case two: the no-shows

We had wired the forward trigger to Eventbrite registration. That was the mistake. Registration is a statement of intent. Attendance is behaviour. They are not the same thing, and at volume the gap between them is a crowd.

Deals moved forward when people registered, and nothing moved them back when they failed to check in. The pipeline said these people had momentum. They had none. The coordinators trusted the stages, so nobody chased the no-shows, because the board said they were progressing. No-shows raised no errors. They sat in a stage that overstated their progress.

The fix was behaviour-based routing. Eventbrite knows who checked in, not just who registered, and we had been ignoring that data. Deals now move forward only on things people did: checked in, booked, replied. Registration earns a reminder sequence. Nothing more.

Edge case three: the stage nobody owned

Between Attended and Interview scheduled sat a stage the team called Ready for interview. During the build workshop, someone said "we handle that step manually," so the automation skipped it. The recruitment coordinator believed the hiring manager sent the interview link from there. The hiring manager believed the coordinator did. Both were sometimes right, which is worse than both being wrong, because the gap was intermittent and nobody could see a pattern in it.

We found it by sorting the pipeline by time in stage instead of looking at stage totals. The totals looked healthy because the stage quietly absorbed people. The oldest deals in Ready for interview had sat long enough that reaching out felt embarrassing. These were applicants who had done everything asked of them: applied, registered, shown up. The system went silent on exactly the people who behaved best.

This is the single most common leak we find in client operations, and it is rarely in the tooling. We wrote up the general method for finding it in our operations leak audit.

The thing that mattered most

All three failures had the same root. A stage existed, and nothing was responsible for getting deals out of it. So here is the rule, and it is the only part of this article you need to remember: every stage needs an owner and an exit rule.

A pipeline stage is a queue. A queue needs two things to function: a worker and a timeout. If a stage has no worker, items wait forever. If it has no timeout, failures are silent. Our duplicate deals were items entering the queue twice. Our no-shows were items with no timeout. Ready for interview was a queue with no worker at all.

An owner is a named person or a named automation. "The team" is not an owner. "The coordinators" is nobody. An exit rule means every deal in the stage has a defined way out, and at least one of those ways is triggered by time rather than by someone remembering. Forward exits should fire on behaviour: a check-in, a booking, a reply. Timed exits should fire on silence: a reminder, then a reroute, then a clean close.

We now ask two questions of every stage in every pipeline we design. Who or what moves deals out of here? And what happens to a deal that has been here too long? If either answer is "someone will notice," the stage is a leak. This is pipeline design before it is automation, which is why we treat it as RevOps work first and wiring second.

Here is what the recruitment pipeline looked like once every stage could answer both questions:

Stage	Owner	Forward exit (behaviour)	Timed exit (silence)
New application	Automation	Passes screening, session invite goes out	Flagged as a task for human review if screening cannot decide
Invited to session	Automation	Registers on Eventbrite	Reminder sequence, then a close with a re-apply note
Session booked	Automation	Checks in at the session	No check-in routes the deal to the no-show lane
No-show	Automation	Books a later session	Re-invite sequence, then a courteous close
Attended	Coordinator	Books an interview from the scheduling link	Reminders, then a HubSpot task lands on the coordinator
Interview scheduled	Interviewer	Outcome recorded after the meeting	A cancellation moves the deal back automatically
Decision	Hiring lead	Offer sent or file closed	Overdue decisions escalate as a task to the lead

Notice what the table does not contain: a stage whose only exit is memory.

What shipped

The final system, in pieces:

• A dedupe step at the front door. Every new application is matched on email first, then on a normalized phone number. A returning applicant updates their existing open deal instead of creating a new one, and routes to a returning-applicant branch that a human reviews. The funnel never restarts on its own.
• Behaviour-based routing everywhere. Deals advance on Eventbrite check-ins, booked meetings, and replies. Registration alone earns reminders, not progress.
• A no-show lane with its own owner and exit. An automation re-invites, and if nothing comes back, closes the file with a polite note that invites re-application. No-shows stopped being invisible and became a lane with a process.
• Scheduling wired into stage updates. Entering Attended sends the booking link. The booked meeting advances the stage. A cancellation reverses it. Nobody types stage changes by hand, because the stage is now a fact derived from behaviour, not an opinion someone records.
• Time-in-stage alerts. When a deal sits past its stage limit, the stage owner gets a HubSpot task. The stage nobody owned cannot happen quietly anymore.

All the wiring is Zapier. It was the right choice here because the client's own team can read and edit the Zaps without us. If you are picking a tool for a similar build, we compared the trade-offs in Zapier vs Make vs n8n.

This system has now moved 4,000+ applicants and eliminated 85% of the manual recruitment work. We want to be precise about what that 85% was: copying names between tools, sending invites, chasing no-shows, updating stages, and noticing silence. The remaining work is the part that should stay human: reading applications that need judgement, running interviews, making decisions, and reviewing the edge cases the automation flags instead of guesses at.

What we would do differently

1. Map the exits before the entries. We drew the entry triggers happily and dealt with exits late. The exits are where pipelines fail. They are now the first question we ask about any stage, before anything gets built.
2. Wire on behaviour from day one. Registration is intent, check-in is behaviour, and the gap between them filled a stage with people who were not moving. We will not trigger forward motion on intent again.
3. Build the no-show path before launch, not after. At volume, no-shows are not an edge case. They are a standing population that needs its own lane, its own owner, and its own ending.
4. Put time-in-stage on a dashboard in week one. The stage nobody owned was visible in the data from the start. We were looking at stage totals, which the leak flattered. Sorting by age would have surfaced it months sooner than it did.
5. Say earlier when a client does not need the build. If your volume is low enough that one person can name every active applicant, you do not need this system. You need a spreadsheet, a weekly review, and the same two questions per stage. The owner-and-exit-rule discipline costs nothing and works on paper. Automate when the copying, not the deciding, is what consumes the hours.

If you want a second pair of eyes on a pipeline like this, our process is on how we work: scope quoted in writing before anything starts, $150/hr CAD, and hours that never expire.

FAQ

What is an exit rule in a pipeline stage?

A defined way out of the stage that does not depend on anyone remembering. Every stage should have a forward exit triggered by behaviour, such as a check-in, a booking, or a reply, and a timed exit triggered by silence, such as a reminder, a reroute, or a clean close. If the only way out of a stage is that someone notices, the stage will leak.

How do you stop duplicate applicants from creating duplicate deals in HubSpot?

HubSpot deduplicates contacts on email address, but that does not protect your deals, and it does nothing when someone applies again from a different email. Put a dedupe step at the front of the funnel: match on email first, then on a normalized phone number. On a match, update the existing open deal instead of creating a new one, and route the contact to a returning-applicant branch that a human reviews.

Why route on Eventbrite check-in instead of registration?

Registration is intent and check-in is behaviour. When we advanced deals on registration, no-shows kept moving forward and nobody chased them, because the pipeline claimed they were progressing. Advancing only on check-in keeps the pipeline honest, and it lets no-shows route to their own lane with re-invites and a defined close.

Do I need this kind of automation at low applicant volume?

Probably not. If one person can name every active applicant, a spreadsheet and a weekly review will beat a month of automation work. The part of this article worth stealing at any volume is free: give every stage a named owner and an exit rule. Automate once the copying between tools, not the deciding, is what consumes the team's hours.