Modelling candidate follow-up before ATS automation

The problem

Assume the agency receives 80 applications a month and measures a 3–5 minute handling time for each acknowledgement or outcome update. That creates a 4–7 hour monthly range to investigate before allowing for exceptions.

The team should also record its actual on-time follow-up baseline. This scenario does not assume a 60% starting point or a perfect automated completion rate.

What the Blueprint found

An agency like this uses Bullhorn as its ATS. A workflow session often surfaces that Bullhorn's webhook system, which fires an event every time a candidate's status changes, is configured but not connected to anything, typically set up by a previous IT contact and never used.

If those webhooks are available, the Blueprint would test their connection to an email sequence as a high-priority option. Tooling, exceptions and review requirements must be confirmed in the actual agency.

What gets built

Two automated email sequences, triggered by Bullhorn status changes. The first fires when a candidate's application status moves to "received": a personalised acknowledgement with a timeline. The second fires when a status moves to "interview complete": an outcome email with next steps.

Both sequences use the candidate's name and role title pulled from Bullhorn, so they read as personal emails, not automated ones. You review and approve the templates before go-live.

What changes

The implementation hypothesis is that ATS triggers reduce drafting time and improve on-time follow-up. Exceptions, invalid addresses and human review mean 100% should never be promised.

Measure handling time, successful delivery, on-time follow-up and candidate response for four weeks before and after launch. Any response uplift is an observed result only after that comparison.