What a WhatsApp CRM actually needs to do, not just show
A shared inbox is not a CRM. The mechanical checklist that separates a WhatsApp CRM that works from one that just looks like it does, in screenshots.
· 4 min read
A shared inbox is the easy 20 percent
Several people replying from one WhatsApp number without stepping on each other is genuinely useful, and it is also the easiest part of this category to build and the easiest to demo well. A screenshot of a clean inbox with assignment and internal notes looks finished. Whether the product underneath it actually understands WhatsApp's own rules — the 24-hour window, opt-in categories, template restrictions, per-number quality — is invisible in that screenshot and is where most of the real engineering effort in this category actually has to go.
The rest of this article is the checklist for that invisible part: the mechanics a tool has to get right before 'WhatsApp CRM' means something more than 'chat viewer with an assignment button.'
It has to know the window is closed before it lies about sending
As our guide to the 24-hour customer service window explains, WhatsApp accepts a free-form message sent outside that window at the API level and then silently drops it — the sender gets no error, and a naive integration records the message as sent because that is what the API response said. A tool that does not check the window before attempting the send will show an agent a clean 'delivered' status for a message the customer never received, and nobody finds out until the customer says they never heard back.
The only real fix is checking the window before the send is attempted, not after, and refusing the send with a clear reason — 'this contact's window is closed, send a template instead' — rather than letting it through and hoping. That is a specific, checkable behaviour to ask about, not a vague claim about being 'compliant.'
It has to enforce opt-in by category, not just record that consent exists somewhere
Our guide to WhatsApp opt-in covers why consent is category-specific — agreeing to order updates is not agreeing to marketing — and why the burden of proving it now sits with the business. A CRM that stores a single yes/no consent flag per contact cannot answer the question WhatsApp will actually ask if a complaint is investigated: consent for what, captured how, and when.
The real requirement is that a campaign launch checks live, per-recipient, per-category consent before it sends, and refuses or strips out anyone who does not have it — rather than trusting that consent was checked once, at some earlier point, by someone, and is still valid now.
It has to treat template category as a gate, not a suggestion
Our guide to template approval and rejection covers why a miscategorised template is expensive: it can cost the account a week or more of utility restriction that cannot be appealed quickly, precisely because a mismatch between what a template says and the category it claims gets caught by Meta's own review and enforcement, not by the tool that submitted it.
A CRM worth the name validates a template against category rules — the formatting restrictions, the content patterns that read as marketing versus transactional — before submission, not after a rejection or, worse, after an approval that later gets revoked for quality reasons. Catching this before Meta does is the difference between a five-minute fix and a week of restricted sending.
It has to make bulk sending slow when the rail demands it, not fast by default
Our guide to bulk sending and number restriction covers why a QR-paired channel needs to be deliberately throttled — paced sends, a daily cap, and an explicit risk acknowledgement before a broadcast on that rail can even start. A tool that treats every connected number the same way, sending as fast as the API allows regardless of which rail it is actually on, is optimising for a demo that looks fast rather than for the number staying usable next month.
Ask specifically: does the tool send differently depending on whether the number is on the official Business Platform or a paired phone? If the answer is no, it does not understand the risk it is putting the business's number in.
The checklist, plainly, and why it is the actual product
Window-awareness enforced at send time, not just reported after the fact. Opt-in checked live, per contact, per message category, at the moment a campaign launches. Template category validated against content before submission, and treated as a real gate rather than a formality. Sending paced and capped according to which channel a message actually travels on, with the riskier channel visibly and deliberately slower. A shared inbox, multi-agent access, and a clean interface are worth having, but they sit on top of this list — they are not a substitute for it.
None of these four are visible from a features page written in adjectives — 'compliant', 'safe', 'reliable' — because those words describe an intention, not a mechanism. The useful version of this checklist is a set of questions with checkable answers: does a send get refused, or just logged as risky after the fact? Is a category checked per message, or once per contact? Is a template's content actually validated, or only its variable count? Does a broadcast slow down on a risky rail, or does every number get treated the same? A vendor who can answer all four specifically has probably built the thing; a vendor who answers all four with the same reassuring paragraph probably hasn't.
It is easy to treat these four mechanics as a defensive layer bolted onto the real product — the inbox, the campaigns, the automation builder — rather than as the thing that makes the rest of the product safe to use at all. A campaign feature that can send to anyone regardless of consent is not a more complete campaign feature; it is a campaign feature with a hazard left in it. A missing mechanic here means a real number, belonging to a real business, at real risk — which is the reason this checklist is worth asking about before signing up, not discovering after the first restricted send.
Common questions
Isn't a shared inbox with assignment and notes basically what a WhatsApp CRM is?
That is the visible, table-stakes part of it, and it is genuinely useful, but it is not the hard or distinguishing part. The mechanics that actually protect a business — window-awareness at send time, live category-specific opt-in checks, template category validation, and rail-aware sending pace — are invisible in an inbox screenshot and are where a tool's real engineering effort has to go.
How can I tell if a tool actually checks the 24-hour window before sending, rather than just reporting on it afterward?
Ask directly, and ask for the specific behaviour: does an attempted free-form send to a contact whose window has closed get refused with a clear reason, or does it appear to send successfully? A tool that can only tell you after the fact that a window was closed is reporting, not preventing — and reporting after the customer never received the message is too late.
Why does template category matter this much to a CRM's design?
Because Meta's own review checks a template's actual content against the category it was submitted under, not just the label chosen. A mismatch — a discount slipped into a message submitted as a transactional utility template, for example — risks a restriction on the whole account's utility-sending ability that is not something an owner can appeal quickly. A CRM that validates this before submission catches it in minutes instead of a week later.
Does a WhatsApp CRM need to treat every connected number the same way when sending in bulk?
No, and treating them the same is itself a risk. A number connected through the official Business Platform is on a metered, sanctioned channel built for volume. A number reached through a QR-paired phone is not, and sending at the same speed and volume on that rail is one of the fastest ways to get the number restricted. A CRM that sends identically on both is optimising for speed over the customer's own number staying usable.