Connecting WhatsApp to your CRM: what data to sync

The instinct when connecting WhatsApp to a customer record system is to log everything, on the reasoning that data not captured cannot be analysed later. This produces a system nobody uses.

The reason is that a complete message log is a transcript, and a transcript is not what anyone needs at the moment they open a customer record. Someone about to call a customer needs to know what happened, what was agreed, and whether anything is outstanding. Scrolling several hundred messages to reconstruct that is slower than asking a colleague, so people ask the colleague and the integration goes unused.

So the useful question is not what data is available but what question the record needs to answer. For most businesses there are three: who is this person and what have we agreed with them, are we permitted to message them and about what, and what is outstanding right now.

Everything worth syncing serves one of those. Everything else is storage cost, noise, and — for message content specifically — a data protection exposure that grows with volume. A deliberately smaller sync is more useful than a complete one, and that is the central design decision rather than a compromise forced by effort.

A practical schema starts with identity and consent, because those are what govern whether anything else can happen.

The contact needs a phone number in full international format, stored as the identifier that links the messaging channel to the customer record. Inconsistent number formatting is the most common cause of duplicate records and of a conversation failing to attach to the right customer, so normalising on entry matters more than it sounds.

Consent needs three fields, not one: the method by which it was captured, the date, and the message category it covers. A single consent flag cannot express that someone agreed to order updates but not promotions, which is exactly the distinction policy turns on. This is the highest-value part of the whole schema, because it is what makes a pre-send check possible.

Language preference, recorded from what the customer actually used rather than inferred from location, determines which template version to send.

Then the operational state: whether a customer service window is currently open, when the last inbound message arrived, and whether anything is awaiting a reply. That last group is what makes the record useful for the person about to act, and it is the part most often omitted in favour of message history.

Outbound template sends are worth recording individually, because each is a billable event and a compliance record. Useful fields are the template used, its category, the timestamp, the delivery status, and whether it was read or replied to. This gives a business the ability to answer what was sent to whom and when, which is the question that arises during a complaint or a policy query.

Inbound and free-form messages are the ones where full logging causes problems. The better approach is a summary plus a pointer: record that a conversation happened, when it started, roughly what it concerned, and how it ended, with the full thread remaining accessible in the messaging tool for the occasions it is actually needed.

The outcome field is the one that repays the most effort and is almost always missing. A conversation that ended in an order, a booking, a resolved complaint, a quote sent, or no result at all is a fact somebody can act on. Without it, a record shows that conversations occurred and nothing about whether they achieved anything.

Media deserves a deliberate decision. Syncing every image and document a customer sends consumes storage rapidly and often duplicates what is already elsewhere. Recording that media was exchanged, with a reference, is usually sufficient.

Some things are technically syncable and better excluded, and the reasoning is worth making explicit so exclusions are decisions rather than gaps.

Full message content for every conversation is the main one. It creates a large, growing store of customer communications, including whatever personal details customers volunteered, held in a system with different access controls from the messaging tool. The more places sensitive information is copied, the more places it must be protected and eventually deleted.

Read receipts on individual messages produce high volume and near-zero value. Aggregate read behaviour is useful; knowing that one message was read at a particular minute is not.

Typing indicators, presence and other real-time signals should not be persisted at all. They are momentary by nature and become noise immediately.

Inferred attributes deserve scepticism. A sentiment score or an interest guessed from message content becomes a fact in the record that no human verified, and it will be acted on as though somebody had. Recording what the customer said or did is safer than recording a system's interpretation of it.

And anything a customer would be uncomfortable to learn was stored is worth a second look, since that instinct usually tracks a genuine data protection question rather than mere squeamishness.

The single most valuable thing an integration can do is turn consent from documentation into a check that runs before a send.

A consent record that exists only as a stored field is a defence after a complaint. A consent record consulted automatically before every outbound message is a control that prevents the complaint. The difference is not the data but where in the process it is used.

That requires the consent fields to be structured rather than freeform. Method, date and category as separate values can be evaluated by a rule; a note reading "opted in at the shop, I think last year" cannot. This is the practical argument for the three-field approach over a single flag.

Opt-outs need to be honoured across the whole system rather than in the tool where they arrived. A stop request received in a conversation, recorded only in the messaging tool, leaves a customer record that still looks permitted — and the next campaign will message someone who asked not to be. This is one of the most common ways businesses generate blocks while believing they are compliant.

It is also worth recording the negative cases: who was excluded from a send and why. That is what lets a business answer why someone did or did not receive a message, which is otherwise unanswerable after the fact.

A few things reliably cause trouble and are cheap to avoid.

Normalise phone numbers on entry, in one format, everywhere. Numbers stored with country codes in some records and not others, with spaces or leading zeros, produce duplicate contacts and conversations that attach to the wrong customer. Retrofitting this is considerably harder than doing it at the start.

Decide how a conversation maps to a record before building. A customer with two numbers, a number shared by a household, or a business contact who also buys personally all need a rule, and discovering the ambiguity after thousands of records exist is expensive.

Decide retention deliberately. Messaging data accumulates quickly, and a system with no deletion policy holds customer communications indefinitely by default rather than by decision.

Expect the sync to fail sometimes and design for it. A message that arrives while the integration is down should not vanish silently, and a business should be able to tell whether the record is complete for a given period.

And start narrower than feels comfortable. Fields can be added when a real question needs them, whereas an over-broad schema built speculatively creates work maintaining data nobody consults — which is the usual reason these integrations are abandoned rather than any technical failure.