WhatsApp Interview Invites and Reminders, Per Role

A candidate applies on Tuesday, gets a screening invite by email on Tuesday evening, and reads it on Friday. By then the drive has moved on. This is not a hypothetical failure, it is the ordinary arithmetic of email in Indian entry level hiring, and it is the reason we spent August wiring WhatsApp into the invite path.

As of August 26 it is live on production. HireQwik can now send a screening invite, a reminder, and a booking confirmation over WhatsApp, switched on one job description at a time. This post is what it does, what it deliberately refuses to do, and the rollout order I would use if I were turning it on for a role of my own.

Three messages, not a messaging product

The scope here is narrow on purpose. There are exactly three message kinds.

The invite goes out when a candidate enters the pipeline and needs to pick a screening slot. It carries the booking link. The reminder fires when an invited candidate has not booked yet. The booking confirmation goes out once they have picked a time, carrying the joining detail.

That is the entire surface. There is no chat inbox for recruiters, no conversational bot, no broadcast campaign tool. Those are all real products and several vendors sell them well. What we built is a delivery channel for three transactional moments that were previously email only, because those three moments are where a screening funnel silently loses people.

We stayed narrow because a screening pipeline that grows into a messaging platform picks up a second surface that can break, and a first round only earns its place if it runs unattended.

Per role, not per account

The switch lives on the job description’s trigger configuration, not on your account. You turn WhatsApp on for one role and every other role in your organisation keeps sending email only.

This matters more than it sounds. The instinct with a new channel is to enable it everywhere and see what happens, which in high volume hiring means finding out about a formatting problem across 2,000 candidates instead of across 40. Per role means the blast radius of your first mistake is one requisition.

The rollout I would run, and the one we ran ourselves:

Pick your lowest volume open role. Not the campus drive. A lateral requisition with twenty or thirty candidates in the pipeline where you will actually read every delivery result. Turn it on. Watch what lands. Then widen to a second role, then to a drive.

Email stays primary, and that is a design decision

The most important property of this feature is a negative one: WhatsApp mirrors email, it does not replace it.

The email invite still sends. The email is never made conditional on WhatsApp succeeding. Underneath, the WhatsApp service is fail soft by contract, meaning a failure inside it cannot raise an error into the flow that called it. A messaging outage cannot block an email going out, cannot block a booking being made, and cannot stop a reminder tick from running.

That is a deliberate tradeoff and it costs us something. It means we cannot claim WhatsApp as the channel that guarantees delivery, because we always pay for two channels. It also means a candidate who is on WhatsApp gets pinged twice, which some of them will find mildly redundant.

We took that trade because the alternative is worse in a specific way. A single channel screening funnel has a single point of failure sitting between your requisition and every candidate in it, and messaging infrastructure is not something we control. The reasoning is the same one behind the rest of our notification design, and it is why the scheduling path has its own reliability mechanics rather than depending on any one message arriving.

If you are looking for the argument that reminder channel choice moves show up rates in Indian campus hiring at all, we made that case separately in why your campus hiring funnel breaks before the screen runs. This post assumes you accept it and covers what it took to actually ship.

The copy is fixed, and you should understand why

You cannot freely write the text of a WhatsApp interview invite. Not in our product and not in anyone’s.

Meta requires business initiated messages, meaning any message you send to someone who has not messaged you first, to use templates submitted and approved in advance. Providers of the WhatsApp Business API document this consistently: template approval is a prerequisite, not a formality, and utility templates covering things like appointment notifications are held to different standards than marketing ones.

Practically, this means the copy of your invite is decided at approval time and only four values change per send: the candidate’s name, the role, the company, and the link or slot. Four positional slots in a fixed sentence.

Two consequences worth planning around. First, you cannot A/B test invite wording the way you would an email subject line, because each variant is a separate template needing separate approval. Second, when you do want new copy, budget for the review cycle rather than assuming a same day change. Teams arriving from an email first workflow, where wording can be changed the morning of a send, are caught by this more often than by anything else here.

Since the copy is fixed anyway, use the space well. The invite is the natural place to tell a candidate that the first round is AI conducted, and that disclosure is worth more than it looks: In Greenhouse’s 2026 candidate study, 70% were never told upfront that AI would be evaluating them, and undisclosed AI ranks among the top reasons people abandon a process. A template you write once, that says plainly what is about to happen, fixes that for every candidate you will ever send it to.

The unglamorous part: phone numbers from a spreadsheet

Here is the problem nobody puts on a feature page, and the one that will actually break your first rollout.

Candidate phone numbers reach us through a connected Google Sheet, so they arrive in whatever shape a placement coordinator, a staffing partner, or the candidate themselves happened to type. In one real column you will find a bare ten digit number, the same number with spaces in it, a version with a leading zero, one with dashes, one with the country code and no plus sign, and one with a stray apostrophe that a spreadsheet added to stop it being read as a number.

Every one of those is the same human being. None of them is directly sendable.

So the service normalises before any send. Ten digits are assumed to be Indian and get +91. An eleven digit number starting with a zero drops the zero. Twelve digits starting with 91 gain a plus. A number already carrying some other country code is trusted as it stands. Anything shorter than ten digits is rejected outright rather than guessed at, because a guess here means messaging a stranger.

That last rule is the one I would defend hardest. The tempting behaviour is to pad or infer a short number and get delivery up. The correct behaviour is to drop it, because the cost of a wrong guess is a message about a job interview arriving at someone who never applied.

The practical implication for you is a five minute job before you enable the channel: sort the phone column in your sheet and look at the shortest values. Those are the rows that will silently not send. That is a data problem you can fix in the sheet, and it is much cheaper to fix on Tuesday than to discover on drive day.

When each of the three messages should fire

The mechanism is only half the decision. The other half is timing, and timing on WhatsApp behaves differently from timing on email in ways that catch teams out.

Email tolerates being early. A message sitting in an inbox at 6 AM costs nothing and gets read whenever the person opens their mail. WhatsApp does not work that way. It arrives with a notification, on a device in someone’s hand, and an invite that lands at 7 AM on a Sunday reads as intrusion rather than opportunity. The channel that gets read faster is also the channel that annoys faster, and those are the same property viewed from two sides.

The invite goes out with the pipeline event rather than being held back, because a candidate who has just applied is the most engaged they will ever be and delay works against you. That does mean the timing of your sheet drop becomes the timing of your messages. If a placement coordinator pastes a batch at 11 PM because that is when their day ended, that is when the invites go. Add the rows in the morning instead. It is a one line change to how your team works and it is the only lever here that is entirely in your hands.

For the reminder, the temptation is to send several. Resist it. One reminder to a candidate who has not booked is a service. Three is a nuisance and it converts a neutral candidate into someone who opts out, which costs you the channel for that person permanently on future roles as well. If a single reminder does not produce a booking, the problem is usually not awareness. It is that the candidate has decided, or that your slot window does not fit their week, which is a scheduling design question rather than a messaging one.

For the booking confirmation, immediacy is the whole value. It fires when the slot is picked, closing the loop while the candidate is still on the booking page. It also carries the joining detail, which makes it the message they will scroll back for on the day, and a strong argument for putting it where they can actually find it again.

How you check whether a candidate was actually pinged

Every attempt is stamped on the candidate’s own row, per message kind. Invite, reminder and confirmation each carry their own status.

This is the difference between “we sent 800 messages” and “was this specific person contacted.” When a hiring manager asks why a promising candidate never booked, the answer is on the row: sent, failed, or suppressed, with a timestamp. Campaign level counters cannot answer that question, and the question is always about one person.

You read those states in the review queue alongside everything else the screen produced, in the HR dashboard. A candidate showing an invite sent and no booking three days later is a follow up. A candidate showing a failed send is a data problem. They look identical in a total and need completely different responses.

One state you will see is a suppressed send, which means that number opted out. That mechanism has its own rules, its own failure behaviour, and its own post: what happens when a candidate replies STOP.

What we are not claiming

The channel went live five days ago. We do not have a response rate, a no show reduction, or a completion lift to show you from our own sends, and we are not going to borrow someone else’s numbers and imply they are ours. Several vendors in this space publish substantial claims about WhatsApp response rates against email; treat those as their data, not as an industry constant.

What we can say is what the mechanism does: three transactional messages on a channel Indian candidates read the same day, without removing the one they read eventually, a role at a time, with a per candidate record of what happened.

The take

Most WhatsApp recruiting features are sold as a response rate multiplier. That framing invites you to switch a channel on across everything at once, which is exactly the wrong order of operations for a system where the failure mode is a malformed phone number rather than a bad message.

Turn it on for one role. Read the phone column first. Keep email underneath it. Then widen.