WhatsApp Is Your Intake Layer, Not Your CRM
WhatsApp receives the lead; the CRM owns its state. The routing contract to write before you buy either tool, plus the two platform rules that break it.
WhatsApp is where your inbound arrives and where the conversation happens; the CRM is where the lead's state lives. Treat the channel as an intake layer wired into a system of record, and write the routing contract — field, whether it is required, what breaks when it is missing, who owns it — before you buy either tool. Teams that buy the CRM first rebuild the intake a second time, because they discover the contract while the data is already flowing.
The confusion, and what it costs
In Latin America WhatsApp is not "one more channel." It is the front door. Sales lives in it, customers expect an answer there, and for a lot of companies the app is the de facto pipeline. Then someone decides the business needs control, buys a CRM, and asks: import what, exactly?
What usually happens next is a split personality. WhatsApp keeps running the business, the CRM becomes a reporting layer fed by someone's memory, chat search turns into the database ("who wrote me in March?"), and a spreadsheet export starts circulating. Two systems holding half a lead each, and neither of them answerable when the owner asks what happened to a deal.
We implement this for a living, and the pattern is consistent enough to state as opinion: a CRM bought before the intake is defined does not create order, it creates double entry. The data-entry burden moves to whoever is least likely to complain about it, and six weeks later the team is back in WhatsApp because that is where the truth is.
There is a demand signal behind this. Our own Search Console data for the 28 days from September 20 to October 18, 2026 shows our WhatsApp + CRM comparison for the Latin American market pulling 853 impressions at position 6.0 and zero clicks. People are asking which tool is which, and the answer on the page — a platform comparison — is not the answer they need. They are asking a layer question: what is WhatsApp actually responsible for once a CRM exists?
Two layers, two jobs
The split is not philosophical; it decides what breaks at 2 a.m. on a Saturday.
| What the intake layer (WhatsApp) owns | What the system of record (CRM) owns |
|---|---|
| The conversation, in real time | The identity of the person, deduplicated |
| Opt-in status and its proof | Lead stage, owner, and next action |
| Template state, quality rating, window clock | Full history, across people and channels |
| The moment a human must take over | Reporting you can defend in a meeting |
Neither side can do the other's job. The CRM never chats — every hour you ask it to, you add latency a competitor will eat. And WhatsApp does not remember reliably: a phone number with no consent timestamp is not an auditable lead, and a chat thread is not a pipeline. Search inside an inbox is a retrieval trick, not a data model.
The routing contract
Before a single tool is selected, write the contract. It is a table, and it is the whole discipline:
| Field | Required | What breaks when it is missing | Who owns it |
|---|---|---|---|
| Contact identity (E.164 phone + name) | Yes | Duplicate records; the same person exists three times under three conversations | Intake automation |
| Opt-in proof (timestamp, source, wording) | Yes | You cannot defensibly message them once the window closes; opt-in is a platform requirement, not a courtesy | Marketing ops |
| Source / campaign | Yes | Channel contribution stays a matter of opinion; budget meetings go in circles | Intake automation |
| Requested service or intent | Yes | The lead lands in a generic queue and the first human reply asks something a bot could have answered | Automation |
| Qualification answers (budget band, timeline) | Per business | Sales asks again, and the second ask is where conversations cool off | Sales owner |
| Named owner | Yes | The lead sits in a shared inbox; "I thought you had it" is the entire failure mode | Sales manager |
| Window state (expires at, next action) | Yes | Follow-up is planned as a free-form message the platform will simply not deliver | Automation |
| Failure lane (validation fails → named human + queue) | Yes | The lead exists nowhere: not in the CRM, not in a report, not on anyone's list | Automation |
Every row we have watched go missing has produced the same outcome: silence, not an error. Automations do not raise their hand when a field fails; they drop the record and keep running. That is why the failure lane is a column in the contract and not an afterthought.
Constraint one: the 24-hour customer service window
Meta's documentation on service messages is blunt about the clock: when a WhatsApp user messages or calls you, a 24-hour timer starts, and it resets only if the user messages or calls again before it expires. While the window is open you can send free-form service messages with no pre-approval. When it closes, you can only send pre-approved template messages.
Two consequences fall straight out of that text. First, your own replies do not extend the window — only the customer's messages do. A team that answers diligently for 23 hours and then waits for business hours has quietly moved itself into template-only territory. Second, any step you plan for hour 25 must be a template, which means it must already exist, already be approved, and already be categorized correctly. Opt-in is also mandatory throughout: you can only message people who agreed to be messaged.
There is a smaller trap in the same page: delivery order across a sequence of messages is not guaranteed. Meta advises confirming a delivered status webhook before sending the next message. Multi-step confirmations built as a fire-and-forget burst sometimes arrive out of order, and a customer who receives "your request was received" after "your appointment is confirmed" reads that as chaos.
Constraint two: template categories decide price and survival
Template messages are the only way to reach someone outside the window, and per Meta's template fundamentals, every template must be categorized as authentication, marketing, or utility — and the category factors into pricing.
The categorization guide contains a change that most teams discover through an invoice rather than through documentation. Effective April 9, 2025, if you submit a template as UTILITY and WhatsApp determines it should be MARKETING, the template is approved as marketing — the category change is the default behavior now, not a rejection. You can request a review within 60 days. Two content patterns guarantee the reclassification: mixed content (an order update that also carries a promotion) and content too vague to classify.
Pricing is the visible half. The invisible half is availability: template quality rating is computed from seven days of user feedback — blocks, reports, mutes — and poor signals can pause a template, which means the automation that depends on it fails without ever throwing an error. Messaging limits apply to what you can send outside windows, and templates inactive for 12 months are archived automatically.
Put the two constraints together and the design rule appears: every step that depends on a template needs a fallback lane that does not. Not a retry loop. A named human, a visible queue, and a timestamp.
The order of work
- Write the contract. The table above, filled in for your business, agreed by sales and marketing before anything is connected.
- Define the smallest state model sales will actually update. Four or five stages, each with an owner and an exit condition. A twelve-stage pipeline nobody updates is worse than a spreadsheet.
- Wire the intake. Webhook → automation → CRM create-or-update, idempotent on phone number so a returning customer updates rather than duplicates. This is where the platform constraints live, and where workflow design decisions pay off.
- Approve templates before you need them. Every template your flow depends on, in every language you serve, tested for category and delivered end-to-end — not the afternoon a campaign launches.
- Build the exception lanes first. Field fails validation, template rejected or paused, window closed, no owner: each one lands in a named queue with a human. Failure handling is the product; the happy path is the demo.
- Monitor four numbers: share of leads missing a required field, time from message to human handoff, window-expiry rate before follow-up, and template reclassification or pause events.
If you want to see the handover half of this done in practice, we wrote up the bot-to-human handover on WhatsApp with the stack we use for it, and the six-layer chatbot architecture that decides what the bot is allowed to answer on its own.
What we measure, and what we do not claim
We measure operational numbers: handoff time, field completeness at creation, expiry-before-follow-up, template events. We do not claim conversion lift from this work on our own property, because our conversion events are not instrumented well enough to defend such a claim — saying "the routing contract raised conversions" would be a story, not a measurement. The operational numbers are the ones that tell you whether the intake is broken, and they are available within the first week.
If you would rather have the contract drawn and wired than read about it, that is the Automation & Chatbots engagement, and where a CRM rebuild is the real issue, CRM Implementation. Fastest path in is a call.
WhatsApp is excellent at receiving people and terrible at remembering them. The CRM is excellent at remembering and useless at replying. The contract between them is the part nobody builds first — and it is the only part that decides whether the second system you buy helps or doubles your workload.
Frequently Asked Questions
Why do WhatsApp templates get rejected or reclassified?
Templates are validated against category guidelines when they are created, and category decides pricing. Since April 9, 2025, if you declare a template as utility and WhatsApp judges it marketing, the template is approved as marketing rather than blocked — you can request a review within 60 days. Mixed content (an order update with a promo inside) and unclear content are both treated as marketing. Separate from categorization, a template can also be paused or downgraded by poor quality signals from the last seven days of user feedback.
What happens after the 24-hour customer service window closes?
Free-form replies stop working. Meta's documentation states that when the window closes you can only send pre-approved template messages, and the timer resets only when the customer messages or calls again — your own replies do not extend it. Anything you planned to send in free form at hour 25 has to be a template you already had approved, or a task for a human in the CRM.
Where should the human handoff live — WhatsApp or the CRM?
In the CRM, with the WhatsApp thread attached to it. WhatsApp holds the conversation and the window clock; the CRM holds ownership, stage, and next action. A handoff that only exists inside the chat app dies the moment the person holding the phone changes shift.
