The problem
The client is a small web studio that runs websites for a handful of clients. Those clients don’t file tickets. They send WhatsApp messages or voice notes like “add a button between these two” or “move that up a little”.
An AI assistant already answered on WhatsApp, but it didn’t know who it was talking to. Someone still had to work out who sent each request, then find their account, their site and where that site is deployed.
Matching senders against a phone number on the CRM account didn’t work. WhatsApp often identifies senders with an internal ID instead of a phone number, and one client can have several people and several channels.
What we built
1. A contact-channel table in the CRM. Each way to reach a client (WhatsApp, SMS, phone, email, Telegram) is its own row, linked to the client’s account. A row holds the raw and normalized handle, optional platform user and chat IDs, and “primary”, “verified” and “last seen” fields. A uniqueness rule stops one handle from ever mapping to two accounts.
2. A resolver. Given a channel and whatever identifiers the platform provides, it looks up the account in a fixed order: normalized handle first, then platform user ID, then chat ID. Normalization is per channel:
- WhatsApp IDs are kept exactly as sent, only lowercased.
- Phone numbers are reduced to digits.
- Emails are lowercased.
A match returns the account, organisation, repository and site, and records a “last seen” time. No match returns “not resolved”. It never guesses.
3. A private API endpoint. The messaging gateway calls it for each inbound message. It requires a shared secret and validates its input. It fails closed: an unknown sender gets no client context at all.
How it works
When a mapped client writes, the gateway adds a labelled block of trusted context (account, organisation, repository, site) to the conversation. The assistant treats that block as scope, never as instructions, so a message can’t talk its way into another client’s account. Then it:
- turns plain language into a concrete edit (“a little higher” means a small nudge, not a redesign);
- edits only that client’s site;
- checks the live site over HTTPS;
- only then confirms to the client, briefly and without technical detail, on the same thread.
In one case, a client’s voice note asked for a new homepage button between two existing ones. The assistant added the button and its page, then checked that the live homepage showed the buttons in the right order and that the new page loaded, before replying.
What we learned
- A running gateway doesn’t mean WhatsApp can send. At one point the WhatsApp connection was logged out while everything else looked healthy. Now “the change is live” and “the client was told” are tracked as separate facts.
- Knowing who the client is doesn’t tell you where their site lives. Identity and deployment are kept as separate records.
- Exact work belongs in code. Matching, normalization and access control are done in tested code, not left to the AI’s judgement.
Result
- Every way a client reaches the studio maps to one account, and one handle can never point at two accounts.
- 13 automated tests cover normalization, lookup order, the no-match case, rejected authentication and input validation. All of them pass.
- In the pilot, mapped clients were recognised with the correct account and site.
- A website change went from a client’s voice note to a verified live change without anyone translating the request.
Could this work for you?
If your customers reach you on WhatsApp, SMS or email, and someone on your team spends time working out who they are and what they’re asking for, the same pattern fits: every message matched to the right customer record, routine requests handled or drafted for your approval, and nothing technical reaching the customer.
We build this as the WhatsApp / CRM Assistant: $3,500 fixed, 2–3 weeks, with an optional Care Plan from $400/month to keep channels connected and rules up to date.
Matching is done in tested code. The AI never guesses who you are.