A smaller desk keeps its WhatsApp provider and gains the workflow

A two or three person recruitment desk does not have someone who wants to read Meta's business platform documentation. What it wants is a number, an inbox, a template builder and a bill that arrives monthly. Providers aimed at small businesses solve exactly that, which is why so many small agencies are already sending through one before they ever evaluate a CRM.

The consequence is a specific migration problem. The desk has its number, its display name, a quality rating built up over a year of sending, and a set of approved templates in the languages it recruits in. All of that is real work, and none of it is portable in an afternoon.

So the question a small agency asks is not whether the CRM has WhatsApp. It is whether adopting the CRM means starting the WhatsApp setup again.

Today it does mean moving, and there is no way to describe that as anything else. To use WhatsApp inside Surhires you connect through the Meta Cloud API directly, through Twilio, or through DoubleTick. A Wati account cannot be pointed at the product.

For a desk starting fresh, going direct through Meta with your own WhatsApp Business Account is straightforward and removes a party from the chain. For a desk with an established Wati setup, moving means migrating the number to a new platform, re-submitting templates for approval, and accepting a period where the number's quality rating rebuilds.

That is a genuine cost. It should be weighed in an evaluation rather than glossed over, and it is the reason the roadmap item exists at all.

It would let a desk keep its number, its display name, its approved templates and its billing relationship while gaining the recruitment workflow above them: candidate records, requisitions, sequences, reply classification and the pipeline.

It would not change the platform rules. The 24-hour session window is Meta's. Template approval is Meta's, granted to your business account. Opt-in still has to be captured on the candidate record with its timestamp, channel and wording. STOP still suppresses across every desk in the tenant. No provider alters any of that and none is claimed to.

It also would not change what recruiters see. The composer, the session countdown, the template picker and the reply handler sit above the router, so the experience is the same on every route.

Even without the Wati route, the reason a small agency puts WhatsApp inside recruitment software rather than running it from a provider inbox is that a provider inbox has no idea what a requisition is. It cannot tell you which candidate was submitted to which client, which conversation belongs to a live search, or which of last month's chats went cold at the availability question.

Inside the product, a WhatsApp thread lives on the candidate record next to the submittals, the interview history and the disposition codes. A reply moves a stage or raises a task. A follow-up nudge cancels itself when the candidate answers. That is the part a messaging tool cannot do.

If Wati moves into build it will be described as in development with its scope named, in the future tense. When it ships it will carry an evidence line naming the routing function, exactly as the WhatsApp page does today.

There is no partnership with Wati, no certification, no reseller arrangement and no listing, and none is implied by this page existing. Writing about a roadmap item is not the same as claiming a connection, and the state badge at the top of this page is the thing to read.