Automating the follow-up, safely

Follow-up decisions depend entirely on state: submitted, acknowledged, in process, interviewed, rejected, offered, gone quiet. Without explicit states the agent is guessing, and a guess here produces a message that contradicts something the candidate already knows.

Define the states and the legal transitions between them, and require every automated action to be a function of the current state. That is what makes the behaviour predictable enough to trust.

Closed must be terminal and enforced, not merely conventional. The single worst output of a follow-up system is a cheerful enquiry sent to an employer who rejected the candidate a week ago, and a state machine that cannot leave the closed state makes that failure structurally impossible rather than unlikely.

• Submitted — awaiting any acknowledgement
• Acknowledged with a timeline — waiting, no action until it passes
• In process — follow up only around stated milestones
• Interviewed — a prompt note is appropriate
• Closed — no further action, permanently

Outbound is trivial; inbound is where the work is. Responses arrive as automated acknowledgements, real replies, rejections phrased kindly enough to be ambiguous, and interview invitations buried in scheduling links.

Classify them and update state accordingly, but treat classification as fallible. A misread rejection leads directly to the worst possible follow-up, so route anything uncertain to the candidate rather than acting on a low-confidence label.

Asymmetric thresholds are the right design here. Mistaking a rejection for silence is expensive and mistaking silence for a rejection merely means one message goes unsent, so the confidence required to keep an application open should be higher than the confidence required to close it.

Replies rarely quote a reference number. They come from an address you have not seen, mention a role title shared by three applications, or come from a recruiter at an agency representing a client.

Use every available signal — sender domain, thread references, role title, timing — and accept ambiguity when it exists. Attaching a reply to the wrong application corrupts the state of two records at once, which is worse than leaving one unmatched.

A plus-addressed or otherwise unique reply-to address per application removes most of this problem at source, where the portal allows one. It is a small piece of setup that converts a fuzzy matching problem into a lookup.

A follow-up that lands at two in the morning local time, or on a public holiday, signals automation immediately. Schedule for working hours in the recipient’s timezone and skip weekends and holidays.

Small jitter helps too. Messages arriving at exactly nine o’clock every time are a pattern, and the pattern is the thing that makes an otherwise reasonable message read as machine-generated.

The intervals matter as much as the times. Two weeks before the first enquiry, one further note after another two, and then stop is a schedule nobody objects to; three messages in ten days is a schedule that gets the candidate remembered for the wrong reason.

Short, specific and low-demand. The role, the date applied, one sentence of continued interest, and an easy exit for the recipient. Anything longer invites the reader to skim it and reply later, which means never.

Never re-argue the case. A follow-up that restates why the candidate is a good fit reads as pressure and adds nothing the original application did not already contain; the purpose is to surface an application that fell through a gap, not to advocate again.

If the message would be embarrassing to read aloud to the recipient, it should not be sent. That test catches almost everything a template gets wrong, and it is cheaper than any amount of tuning.

• Name the role and when you applied — they are tracking many
• One sentence, not a second cover letter
• Give them an easy way to say the role is filled
• No more than two follow-ups, ever

Once a human replies with anything substantive — a question, an interview offer, a request for availability — automation should stop and the candidate should take over. An agent negotiating interview times or answering questions about someone’s experience is well past useful.

The clean boundary is: automation handles the silence, the person handles the conversation. That is both the safest design and the one candidates actually want.

The handover should carry context rather than just an alert. Showing the candidate the original application, what was sent and when, and the full thread means they can reply in two minutes instead of reconstructing six weeks of history first.