Following up without becoming a nuisance

Not every application deserves one. An automated acknowledgement with a stated timeline means the timeline is the answer. An explicit rejection means the conversation is over. A posting that said no follow-ups meant it.

The agent’s first job is to decide whether to act, and that decision needs the application’s actual state — which means the tracking has to be right before the messaging is built.

Treat an unknown state as a reason not to act. An application the system cannot confidently place should produce a question for the candidate rather than a message to an employer, because the cost of asking is a few seconds and the cost of guessing lands in someone else’s inbox.

• Applied with no response and past the stated timeline — follow up
• Interviewed with no response — follow up, sooner
• Explicitly rejected — never
• Told a decision date that has not arrived — wait
• State uncertain — ask the candidate, do not send

Too early reads as impatient and arrives while the process is still running. Too late and the role is filled. The right moment is after any stated timeline has passed, or after a reasonable interval when none was given.

Post-interview is the exception worth treating differently: a prompt, brief note after a conversation is normal professional behaviour and is received well, where the same message three weeks later is not.

Send within working hours in the recipient’s timezone, with a little jitter. A message arriving at 02:00 or at exactly nine every time announces that it was automated, which is the one thing a follow-up should not do.

A second follow-up rarely produces a response that the first did not. A third is noticed, and remembered, in a way the candidate would not choose.

Cap it at one in code. An agent optimising for responses will always find a reason to send another, and the constraint has to sit outside its reasoning.

Make stopping an explicit terminal state rather than an absence of scheduling. An application marked as having exhausted its follow-ups cannot be picked up again by a later scheduling pass, which is how the second message usually escapes in practice.

A message whose entire content is "following up on my application" gives the recipient nothing to respond to and adds no information. It is a request for attention with no offer attached.

A good follow-up adds something small and real: a relevant thing shipped since applying, a brief answer to a question that came up, a specific point of continued interest. Then the recipient has a reason to reply rather than a reason to feel guilty.

Keep it shorter than the original application and make declining easy. A sentence acknowledging that the role may already be filled gives the recipient a low-cost reply, and a low-cost reply is far likelier than a considered one.

Never re-argue the case. A follow-up restating why the candidate is suitable reads as pressure and adds nothing the application did not already contain; the purpose is to surface something that fell through a gap.

The agent must never follow up on an application that was rejected, already answered, or already followed up. Each of those makes the candidate look inattentive to the person deciding about them.

That means reconciling state from replies, not just from what the agent sent. An unread rejection sitting in an inbox is exactly the situation that produces the worst-timed follow-up possible, and only inbound processing prevents it.

Check the state again immediately before sending rather than only when scheduling. A rejection that arrived between the two is the common case, and a queued message that does not re-verify is the mechanism by which it goes out anyway.