Reply STOP: Opt-Out on WhatsApp Candidate Outreach

We shipped a WhatsApp template that said “Reply STOP to opt out” before we had built anything that would listen for the word STOP.

The templates went to Meta for approval with that line in them, because every guide on WhatsApp recruiting tells you to include it and because it is the right thing to put in a message. The channel went live. And then somebody asked the obvious question, which was what happens when a candidate actually does it, and the honest answer for about twenty four hours was: nothing. The message would have been read by a person who then continued receiving messages.

That gap closed the next day. This post is about what had to exist behind that one sentence, because “respect every opt-out” is advice that every compliance guide gives and none of them explain how to implement.

The promise is the easy part

Search for guidance on WhatsApp recruitment opt out and STOP compliance and you will find consistent, correct, entirely unactionable advice. Include a clear way to stop receiving messages. Honour every request. Remove the person from your list.

All true. None of it tells you where in your system the check goes, or what your code should do when it cannot answer the question.

The reason that matters is that an opt-out is not a preference stored on a profile somewhere. It is a promise that a specific future event will not happen, and promises about future events live or die on where you put the check. Put it in the wrong place and you have a database field that is accurate and a message that goes out anyway.

There are only two honest places for it, and one of them is wrong.

You can filter opted out numbers when you build a send list. This is how most bulk messaging works, it is easy, and it fails on exactly the case that matters. A candidate who replies STOP after a list is assembled but before the send fires is still on that list. In a screening pipeline where a reminder tick runs on a schedule, that window is real and it is the window a person is most likely to opt out in, because they just received a message.

Or you can put the check at the send itself. Every single send, immediately before the message leaves. That costs a lookup per message and it is the only version that is actually true.

We put it at the send. A suppressed number is skipped there, before anything reaches the provider, and the skip is stamped on that candidate’s row so it is visible later rather than being an absence in a log.

What counts as STOP

A candidate typing on a phone will not send you a clean control word. They send “stop”, “STOP pls”, “unsubscribe”, “opt out”, “optout”, and a dozen shapes in between.

Our inbound webhook classifies the message body rather than matching a single exact string. The stop family covers stop, unsubscribe, opt out and optout, at the start of the message, case insensitive. The start family covers start, unstop, resume and subscribe. Anything else is ignored, which is the correct behaviour for a candidate who replies “thanks” or asks a question.

The START side is not decoration. Opt-outs in hiring are frequently situational: a candidate is mid exams, or has accepted something else, or was pinged for a role they did not want. Two months later they apply for a different role at the same company. Without a resubscribe path, that person is permanently unreachable on the channel and nobody knows why, and unpicking it means a recruiter filing a request to an engineer.

Record what arrived, not just that something did

A suppression that stores only a flag is thin evidence six months later.

Ours writes three things when a candidate opts out: the number in a canonical form, a timestamp, and a truncated copy of the message they actually sent. That last field is the one people leave out, and it is the one that answers the only question anyone asks afterwards, which is whether the person really did ask you to stop or whether a classifier over-read an ordinary reply.

It also gives you a way to audit the classifier itself. Pull the stored texts periodically and read them. If bodies like “stop sending at night” or “stop, I already joined somewhere” are turning up, your candidates are trying to say something more specific than the two states the channel offers, and a blunt permanent suppression is the wrong response to half of them.

The part I would argue about: failing closed

Here is the design decision in this feature that took the longest to settle.

The suppression check reads from a store. Stores can be unreadable. So what should happen when the system tries to check whether a number opted out and genuinely cannot tell?

The comfortable answer is to send. Notifications are usually built to fail soft, the whole WhatsApp path in our system is fail soft by contract precisely so that a messaging problem cannot break a booking, and continuing on error is the consistent behaviour everywhere else in that code.

We do the opposite here. If the opt-out store cannot be read, the message is not sent. Cannot verify consent means do not send.

The reason this is defensible rather than merely cautious is the mirror channel design described in how the WhatsApp invites and reminders work. WhatsApp never carries anything alone. Email is the primary channel and is never made conditional on it. So the worst case of failing closed is that a candidate receives their invite by email and not also by WhatsApp. The worst case of failing open is that a person who explicitly asked you to stop gets another message from you.

Those two costs are not comparable, and the asymmetry only exists because the channel is a mirror. If WhatsApp were the only path, failing closed would mean silently dropping candidates out of a hiring process, and the right answer would flip. The lesson generalises: whether you fail open or closed is not a matter of principle, it depends on what else is carrying the load.

Utility templates, marketing templates, and a rule that recently changed

A detail worth knowing before you write your own templates, because it has moved recently.

WhatsApp distinguishes utility messages from marketing ones. An interview invite, a reminder about an unbooked slot, and a booking confirmation are utility: they relate to a transaction the person is already part of. A message telling a candidate about roles they never applied for is marketing.

That distinction has teeth. Meta now requires marketing templates to carry an actual opt-out button rather than a “reply STOP” line in the body text, a change that several messaging providers have documented as a mandatory marketing opt-out button. Utility templates continue to carry the instruction as text.

The practical guidance is to keep your screening templates strictly transactional. The moment an invite template starts advertising other openings it becomes a marketing message, it needs different handling, and it stops being something a candidate reasonably expected. That is also the point at which recruitment messaging starts feeling like spam to the person receiving it, which is a worse outcome than any compliance finding.

The India layer

Consent for candidate communication in India now sits under the Digital Personal Data Protection Act, which frames processing around notice and consent that a person can withdraw. Guidance on WhatsApp Business and DPDPA obligations treats the withdrawal path as a requirement rather than a courtesy, and withdrawal that takes effect eventually is not really withdrawal.

I am not going to write the legal analysis here. We have a separate DPDP checklist for AI voice screening for that, and your counsel will have a view. The engineering point is narrower and it is the one under your control: an opt-out that is honoured at the next send is a different product from one honoured at the next campaign, and only the first of those matches what the candidate believed when they typed the word.

What this looks like in the review queue

The observable outcome of all of this is small and specific. A candidate who opted out shows a suppressed state on their row for that message kind, alongside the sent and failed states, in the same review queue where the rest of the screen’s output lives.

That visibility is the point. Three candidates who never booked a slot can look identical in a campaign total while being three completely different situations: one was messaged and ignored it, one had a malformed phone number and was never reachable, one asked you to stop. The first is a follow up. The second is a data fix. The third is a person whose decision you should respect and not work around by finding another number for them.

A suppression that is invisible produces exactly that last behaviour, which is why the skip is stamped rather than silent.

The policy your recruiters need, in one line

The engineering side of this is settled once the check is in the right place. The human side is not, and it is where I have seen the most damage done.

A recruiter looks at the review queue, sees a strong candidate with a suppressed WhatsApp state, and wants to reach them. The resume has a second number on it. Or the placement cell has one. Or the candidate’s college email is right there. Every one of those is a way to route around a decision the person made deliberately, and every one of them will feel to the recruiter like initiative rather than a violation.

So the policy has to be explicit, because the default behaviour of a good recruiter is to try harder: an opt-out is on the person, not on the number. Do not find another way to reach them on that channel.

Two clarifications that make the line workable rather than absolute.

The candidate has declined a delivery channel, not the process. They still receive their invite, their booking confirmation and their result by email, because email is primary and is never conditioned on the messaging layer. Nobody drops out of a hiring pipeline by replying STOP, and recruiters need to hear that plainly or they will treat every suppression as an emergency.

And if a candidate later contacts you and asks to be messaged again, they can restore it themselves by replying START. That is better than a recruiter clearing it on their behalf, because the record then shows the candidate’s own action rather than a staff member’s, which is exactly the distinction that matters if anyone ever reviews how consent was handled.

Write both of those into your recruiter onboarding rather than assuming they are obvious. In a season where a team is behind on numbers, “just try their other number” is the most natural instruction in the world for a manager to give.

Three questions for any vendor sending on your behalf

If someone else’s system is messaging your candidates under your company’s name, the liability is yours. Three questions worth asking, in this order.

Where does the opt-out check run, at list build or at send? Anything other than “at send” has a window.

What happens if the check itself fails? Should the message go out regardless, understand that their fail soft behaviour has just become your compliance exposure.

Is there a resubscribe path a candidate can use without contacting a human? If not, every opt-out is permanent, including the accidental ones.

The take

We put a promise in a template before we built the thing behind it. That was the wrong order, it was caught quickly, and the fix is a lookup on every send plus a decision to stay silent when we cannot be sure.

Every recruiting tool in this market prints “Reply STOP to opt out.” Ask where the check runs, the same way you would ask an interviewer a question it did not expect. The sentence costs nothing to add and it is the implementation underneath that decides whether it means anything.