Outreach that is not spam

Automated outreach to people who did not ask to hear from you is cold contact, and building it without acknowledging that leads to systems that harm the person sending as much as the person receiving.

It can still be legitimate. A candidate contacting a named recruiter about a role that recruiter is advertising is reasonable contact. The same system sending two hundred messages a day to anyone with "recruiter" in their title is not, and the line between them is a design decision you make explicitly or by accident.

It matters commercially as well as ethically, because both sides of the line are available in the same codebase. A product that drifts across it does not usually decide to; it raises a cap, adds a fallback, relaxes a gate, and arrives somewhere nobody chose.

Targeting quality determines everything downstream. A message to someone who does not hire for this area is noise however well written, and enough of it damages the sender’s reputation and the platform’s.

Require a real basis for contact: they posted this role, they lead this team, they wrote about this problem. If the agent cannot state why this specific person, it should not send.

Prefer the channel the posting offered before attempting discovery at all. An application form or a stated contact address is consented contact by definition and reaches someone whose job is to read it, where a private address found elsewhere arrives as an intrusion.

• A stated connection to the role or team
• A verified address, never a guessed one
• An honest declared identity — the candidate, not a fake persona
• An easy way to decline that is actually honoured

Bulk similar messages from one domain get filtered, and once a domain is classified as a source of unwanted mail, recovering is slow and painful. This affects every user of the platform, not just the one who over-sent.

Authenticate properly, keep volumes low, warm up gradually, and monitor bounce and complaint rates as a hard stop rather than a dashboard metric. A single aggressive user can damage delivery for everyone.

Keep cold outreach on a different sending domain from transactional mail. A bad week on the first should not start filtering password resets and application confirmations, and separating them is a configuration decision rather than an engineering project.

Sending from the candidate’s own address is usually better for everyone. It arrives as a person rather than a platform, replies reach them directly, and the reputation consequences land where the behaviour is.

A generated message that could have been sent to anyone will be treated as what it is. The gate is specificity: does it name this role, does it cite a concrete piece of the candidate’s experience, would it be wrong if sent to someone else.

If the answer to the last question is no, the message is a template and should not be sent. Applying that test rejects a lot of output, which is the point.

Implement the gate in code over the gathered facts rather than as a self-assessment. A model asked whether its own message is specific enough will say yes, which is the same reason every other guardrail sits outside the thing it constrains.

A prompt asking the agent to be considerate is not a limit. Caps on messages per day, per company and per recipient belong in the sending layer, along with a suppression list that survives everything.

Once someone declines, they are done — permanently, across the platform, regardless of which user’s agent contacts them. Honouring that is both a legal requirement in many jurisdictions and the single behaviour that separates outreach from spam.

Recognise the informal decline as well as the formal one. "Please stop", a complaint-marked bounce, and a reply asking where you got the address are all objections, and a system honouring only an unsubscribe link will keep contacting someone who has clearly asked it not to.

Check the suppression list before composing rather than before sending. Generating a message for a suppressed recipient costs tokens, produces something that must never go out, and only has to leak once through a bug to become a real violation.

Volume metrics reward exactly the behaviour that destroys the channel. A system optimising for messages sent will send more and worse ones, and the numbers will look excellent while the outcomes decay.

Track reply rate, positive reply rate and complaint rate. If reply rate falls as volume rises, the system is consuming a finite resource — the willingness of recruiters to read cold messages — and should slow down.

The number worth managing against is conversations started per week. Five good messages producing two conversations beat two hundred producing one, and only that metric makes the difference visible rather than flattering the wrong system.