The highest-response channel has the lowest accountability
Ask an Indian business where its customers actually reach it and the answer is WhatsApp. Ask who owns that channel and the answer is a phone in somebody's pocket.
This is not a small operational gap. It is the channel with the best response rate and the highest intent, run with none of the controls applied to a fraction of the email volume. Enquiries arrive and are answered inconsistently, or twice, or not at all. Nothing is recorded against a customer. When the person holding the phone is on leave, the channel is on leave. When they resign, the conversation history resigns with them.
Every company I have worked with in Vadodara, Ahmedabad and further afield has some version of this, and almost none had it on a list of things to fix.
The Cloud API, and why the unofficial route is not a shortcut
There is a persistent market in unofficial WhatsApp automation: tools that drive WhatsApp Web, or unofficial libraries that emulate the mobile client. They are cheaper, they set up in an afternoon, and they get numbers banned.
That is not a hypothetical risk, it is the enforcement mechanism working as designed. And the number that gets banned is the one printed on your invoices and saved in every customer's phone. The official WhatsApp Business Cloud API costs more and takes longer to provision, and it is the only version of this worth building on.
The provisioning itself is the unglamorous part: a Meta Business account, business verification, a number that is not already registered to a personal WhatsApp account, and a display name that survives review. Budget days rather than hours, and do it before anything depends on the date.
What a router actually needs to do
Once messages arrive over a webhook rather than on a handset, the design questions become ordinary integration questions. I have built and run this shape: a central router handling inbound webhooks across multiple business numbers, splitting traffic by route and logging every conversation against the right record.
- Accept and verify webhooks for several business numbers, with per-route handling rather than one endpoint guessing
- Separate marketing from support traffic, because they have different response expectations, different owners and different compliance rules
- Identify the sender against existing CRM records before deciding where the message goes
- Route to the right team, with a defined fallback when nobody claims a conversation
- Log everything against the customer record: inbound, outbound, delivery status and failures
- Fail loudly. A webhook silently rejecting messages for a week is worse than no automation at all
The 24-hour window shapes everything
The single design constraint that surprises teams: outside a 24-hour window after the customer's last message, you cannot send free-form text. You can only send pre-approved template messages.
This is not an obstacle to work around, it is the grain of the platform, and systems that fight it become expensive and fragile. It means your follow-up templates have to be written and approved before you need them, not when a lead goes quiet. It means the value of replying quickly is structural rather than just good manners. And it means "we will just message them next week" is a different, template-shaped, chargeable action rather than a free one.
Templates, and the cost model
Template messages go through review, so the useful discipline is writing the eight or ten you will genuinely reuse rather than one per situation. Approval is not instant and rejections are common for anything that reads as unsolicited promotion.
Pricing is conversation-based rather than per-message, and the categories (marketing, utility, authentication, service) are priced differently, with marketing the most expensive. That has a direct architectural consequence: a system that classifies conversations correctly costs materially less to run than one that routes everything through the marketing category because it was simpler to build.
What good looks like afterwards
The test is not whether messages are automated. It is whether the channel survives a person being unavailable.
Every conversation attached to a customer record, visible to whoever picks it up next. Marketing and support separated, with different owners and different response expectations. Templates approved in advance for the follow-ups that actually recur. Failures that alert someone. And a number that belongs to the business rather than to whoever set it up.
None of this is technically difficult. It is deferred because the current arrangement works well enough on most days, and its failures are invisible: a lead nobody answered generates no complaint and no record. That is precisely what makes it expensive.
Frequently asked
What is the difference between WhatsApp Business app and the Cloud API?
The Business app is a phone app for one person managing one number. The Cloud API is infrastructure: multiple agents, routing, CRM integration, automation and audit. If more than one person needs to handle the same number reliably, the app has already been outgrown.
Can we automate WhatsApp without the official API?
Technically yes, and it is a well-populated market. It also risks the number being banned, and the number at risk is the one on your invoices and in every customer's phone. For anything the business depends on, the unofficial route is not a cheaper version of the same thing.
How long does WhatsApp Business API approval take in India?
Days rather than hours, assuming business verification is clean and the number is not already registered to a personal WhatsApp account. The common delays are verification documents and a display name that fails review, both of which are worth resolving before anything depends on the launch date.
Can WhatsApp conversations be logged in our CRM?
Yes, and this is usually the point of the whole exercise. Every inbound and outbound message, plus delivery status, attached to the customer record, so the conversation belongs to the business rather than to whichever phone it happened on.
What does WhatsApp Business API cost to run?
It is priced per conversation rather than per message, with marketing conversations costing more than utility or service ones. The practical consequence is architectural: correctly classifying conversations, rather than defaulting everything to marketing, is a meaningful ongoing cost difference.