Chat into a CRM: what belongs in a record and what should stay out
A conversation is not a lead. Matching by phone number, the consent trail, and the copy of personal data you have just created somewhere else.
Rebecca PearsonUpdated 11 min read
On this page
- Key takeaways
- What we'll cover
- A conversation is not a lead
- What belongs in the record
- What should stay out
- Matching by phone number is unreliable
- Building it with CodeWords
- The consent trail
- The second copy you just created
- Who owns the conversation afterwards
- Keeping the CRM worth reading
- Making it survive
- Limits worth knowing about
- What to build first
- Frequently asked questions
- Related reading
To connect WhatsApp to your customer relationship management (CRM) system, create a record only when a conversation holds something useful, store structured facts plus a link to the conversation, and carry the consent trail with the record. A conversation is not a lead. The hard part is deciding what a record contains, when one should exist, and how to tell that two records are the same person.
Key takeaways
- Define a threshold before connecting anything: a record should exist only when you know what the person wants and have some way to identify them.
- Store structured facts and a link to the conversation, and leave out the transcript, sensitive details and media by default.
- Phone numbers identify accounts, not people, so normalise them before matching and prefer a duplicate to a wrong merge.
- The consent trail must record what the person agreed to, when, how, on which channel, and any withdrawal.
- The CRM is a second copy of personal data, so it needs its own retention, deletion and access processes from day one.
What we'll cover
- A conversation is not a lead
- What belongs in the record
- What should stay out
- Matching by phone number is unreliable
- Building it with CodeWords
- The consent trail
- The second copy you just created
- Who owns the conversation afterwards
- Keeping the CRM worth reading
- Making it survive
- Limits worth knowing about
- What to build first
- Frequently asked questions
A conversation is not a lead
Do not create a CRM record for every inbound message. Within a month, the CRM fills with wrong numbers, people asking for directions, and two hundred entries with nothing in them, and the sales team stops opening it.
Define the threshold before connecting anything. A record should exist when something is actually known: what the person wants, where they are, and some way to identify them. Below that, the conversation can stay in the messaging system.
Separate three states:
A conversation: everything inbound, which lives in the messaging channel.
An enquiry: a conversation with enough substance to deserve somebody's attention.
A customer: a person who has bought something and needs a durable record.
Most integrations collapse all three into one object, and the result is a CRM nobody believes.
What belongs in the record
The record should hold structured facts, captured deliberately:
Identity, as far as you have it, and the phone number.
What they want, in categories your business actually uses.
Where, since location decides whether you can serve them.
When they need it.
Source, so you can tell which channels produce work worth having.
Consent position and what it covers.
A link back to the conversation, rather than a copy of it.
The link matters most. It keeps one source of truth, avoids duplicating everything, and means a correction in one place is not contradicted by a stale copy in the other.
What should stay out
Five kinds of content should stay out of the CRM, and this is where integrations quietly cause harm.
The whole transcript. People volunteer things they did not intend for a permanent business record: a bereavement, a divorce, a health problem, financial trouble. A summary of what they want needs none of it.
Anything sensitive. Health, religion, sexuality and anything about children arrive uninvited and should not be propagated further.
Media, by default. Photographs include far more than the thing being photographed, and copying them into a second system doubles the exposure.
Inferred judgements about people. Scores and labels are personal data and appear in a subject access request. If you would be embarrassed to show the customer the record, do not keep it.
Idle chat. The weather, the football and the apology for the slow reply add nothing and bury the useful content.
Apply one test: would you be comfortable if this person read their CRM record aloud? If not, something in it should not be there.
Matching by phone number is unreliable
A phone number is the obvious matching key, and it fails in five routine ways.
Formatting. The same number appears with a country code, without one, with spaces, or with a leading zero. Store one canonical form and match on it.
Recycling. Disconnected numbers are reissued, so an old record can attach to a different person.
Shared handsets. Households and small businesses share phones.
Several numbers per person. People have personal and work numbers, old and new.
Messaging for somebody else. The number may belong to a relative or an agent.
Normalise numbers before matching, and never merge records automatically on a number alone when anything consequential is attached. Give people a way to tell you a record is wrong. Where a match is uncertain, a duplicate is safer than a wrong merge, because merging is far harder to undo.
Building it with CodeWords
CodeWords connects to 3,000+ integrations (CodeWords pricing page, 2026), and each connection is made once and reused.
- Open CodeWords and start a new automation.
- Describe what should happen in plain language to Cody, the automation builder: what makes a conversation into a record, which fields are written, what is deliberately left out, and how matching works.
- Authorize the connections to your CRM and your WhatsApp Business Platform account.
- Describe the exceptions: an existing customer, an uncertain match, an opt-out, anything sensitive, and a conversation that should not become a record at all.
- Run it for a fortnight and read the records it created. Reading them is the only way to see what your threshold is actually doing.
You describe the outcome; Cody builds it, connects it and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows (CodeWords pricing page, 2026). Details are on the pricing page.
The consent trail
If the integration exists so you can contact people later, the consent position must travel with the record, and it must be more than a flag. Record four things:
What they agreed to, specifically. Reminders about work in progress and marketing about other services are different things.
When, and how. Keep the wording they saw and the mechanism, not just a date.
Which channel. Agreeing to be messaged is not agreeing to be called.
Withdrawal, recorded the moment it happens and applied everywhere.
Remember the PECR (UK Privacy and Electronic Communications Regulations) distinction, because a CRM full of sole traders is a CRM full of individual subscribers. Limited companies and limited liability partnerships are corporate subscribers for electronic marketing. Individuals, sole traders and ordinary partnerships need consent or the soft opt-in (ICO).
A record with a contactable number and no consent trail cannot safely be used for the purpose you built the integration for.
The second copy you just created
Integrating creates a second copy of personal data in a system with different access, retention and export behaviour. The CRM has its own access list, which is usually wider. It has its own retention, which is usually longer or absent. Its exports and reports put copies into spreadsheets, and it has its own backups.
Four actions follow:
- Put the CRM in your data map.
- Set its retention rather than leaving it at forever.
- Make deletion reach it, because an erasure request handled only in the messaging system is not handled.
- Make subject access requests searchable there, by number, including the notes field where people type things.
None of this is a reason not to integrate. It is a reason to decide what crosses the boundary rather than pushing everything across and sorting it out later.
Who owns the conversation afterwards
Decide who owns the conversation once records exist in two places, or the customer gets two answers. If a salesperson replies from the CRM and a colleague replies in the messaging app, the customer receives conflicting replies. If the CRM shows a stale summary while the live conversation has moved on, somebody acts on old information. If an automation continues while a person is typing, the business looks disorganised.
Set one rule: the messaging channel is where the conversation happens, the CRM is where the record lives, and a person taking over suppresses the automation until they release it. Then make the CRM show clearly that a conversation is live and who has it.
Keeping the CRM worth reading
Integrations degrade quietly, and the symptom is that people stop trusting the data. Five checks help:
Review what is being created monthly for the first few months.
Delete the junk records rather than filtering around them.
Check the fields are still being populated. A renamed field fails silently.
Watch the duplicate rate.
Ask the people using the CRM whether the records help. This is a faster diagnostic than any report.
Making it survive
Five practices keep the integration trustworthy.
Set the threshold for what becomes a record, and revisit it.
Link to conversations rather than copying them.
Normalise numbers before matching, and never auto-merge on a number alone.
Carry the consent trail, including withdrawal.
Include the CRM in retention, deletion and access processes.
Limits worth knowing about
Five limits apply to any WhatsApp-to-CRM integration.
A CRM full of unqualified records is worse than no CRM, because people stop opening it.
Phone numbers identify accounts, not people.
Integration does not create demand. It organises what arrives.
Two systems mean two retention answers, and forgetting the second is the common failure.
Automation cannot judge whether a lead is worth having. It can only record what was said.
What to build first
Build the threshold first. Decide what a conversation must contain before it becomes a record, and write it down. Everything else is easier to change later, while a CRM already full of empty records is a cleanup job and a credibility problem.
Two habits make the difference. Link to the conversation rather than copying the transcript, because transcripts carry things people never meant to put in a permanent business record. And put the CRM into your retention and deletion processes on day one, since the forgotten copy is the one that turns up in a request you cannot answer.
Frequently asked questions
Should every conversation create a CRM record?
No. Set a threshold based on what you actually know about the person. A record for every inbound message fills the CRM with wrong numbers and empty entries until nobody opens it, and the sales team stops trusting the data.
What should the record contain?
The record should contain identity as far as you have it, what the person wants in your own categories, where they are, when they need it, the source, the consent position, and a link back to the conversation instead of a copy of it.
Should the transcript be copied in?
No. People volunteer bereavements, health problems and financial trouble that do not belong in a permanent business record. A short summary of what the person wants needs none of that, and the link to the conversation keeps the original available.
What about photographs?
Leave photographs out by default. Images carry far more than the subject, and copying them into a second system doubles the exposure for no benefit. Keep them in the messaging system and link to the conversation if someone needs to see one.
Why is matching by phone number unreliable?
Numbers appear in different formats, get recycled to new people, are shared on handsets, and belong to people who have several. Some people also message for someone else. Normalise numbers first, and prefer a duplicate to a wrong merge.
What should the consent trail record?
It should record what the person agreed to specifically, when and how (including the wording they saw), which channel it covers, and any withdrawal, applied everywhere. A single yes-or-no flag is not a trail, because it cannot show what was agreed.
Does the marketing distinction matter here?
Yes. Limited companies and limited liability partnerships are corporate subscribers. Individuals, sole traders and ordinary partnerships are individual subscribers who need consent or the soft opt-in. Many trade CRMs hold mostly the second group, so check each contact's type.
What does integrating create that I need to manage?
Integration creates a second copy of personal data, with wider access, its own retention, its own exports and its own backups. Add the CRM to your data map, your deletion process and your access-request searches before you switch the integration on.
Who answers the customer once records exist in two places?
Decide the rule and enforce it: the conversation happens in the messaging channel, the record lives in the CRM, and a person who takes over suppresses the automation until they release it. The CRM should show who has the conversation.
How do I keep the integration healthy?
Review what is being created each month at first, delete junk records rather than filtering around them, check that fields are still populated after renames, and watch the duplicate rate. Also ask the people using the CRM whether the records help.