Chat into a CRM: what belongs in a record and what should stay out

Connecting a messaging channel to a CRM is usually described as a plumbing exercise: conversation happens, record appears, sales team rejoices. The plumbing is the easy half. The half that determines whether anybody trusts the result is deciding what a record should contain, when one should exist at all, and how you know two records are the same person.

There is also a consequence nobody mentions in the integration guide. Every conversation you push into a CRM creates a second copy of personal data, in a system with different access, different retention and different export behaviour from the one it came from. That is a decision worth making deliberately rather than as a side effect of switching something on.

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

The commonest failure of these integrations is creating a record for every inbound message. Within a month the CRM contains wrong numbers, people asking for directions, somebody's cousin, two hundred entries with nothing in them, and the sales team has stopped opening it.

So define the threshold before connecting anything. A record should be created when something is actually known: what they want, where they are, some way to identify them. Below that, the conversation can sit in the messaging system where it belongs.

Three states worth separating.

A conversation, which is everything inbound and lives in the messaging channel.

An enquiry, which has enough substance to be worth somebody's attention.

A customer, 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

Structured facts, captured deliberately.

Identity, as far as you have it, and the number.

What they want, in categories your business actually uses.

Where, since it 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.

That last point matters more than it sounds. A link keeps one source of truth, avoids duplicating everything twice, and means a correction in one place is not contradicted by a stale copy in the other.

What should stay out

The part nobody specifies, and where these 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 does not need any of it.

Anything sensitive. Health, religion, sexuality, anything about children. It arrives uninvited and it should not be propagated further.

Media, by default. Photographs sent in a conversation 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, they are visible in a subject access request, and a record you would be embarrassed to show the customer is a record you should not keep.

Idle chat. The weather, the football, the apology for the slow reply. It adds nothing and makes the useful content harder to find.

A good 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

It is the obvious key and it fails in several routine ways.

Formatting. The same number with a country code, without one, with spaces, 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 completely different person.

Shared handsets. Households and small businesses.

Several numbers per person. Personal and work, old and new.

Somebody messaging for somebody else, where the number belongs to a relative or an agent.

Practical handling: normalise before matching, never merge records automatically on a number alone where anything consequential is attached, and give people a way to tell you a record is wrong. Where a match is uncertain, a duplicate is usually safer than a wrong merge, because merging is far harder to undo.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. 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.
3. Authorize the connections to your CRM and your WhatsApp Business Platform account.
4. Describe the exceptions: an existing customer, an uncertain match, an opt-out, anything sensitive, a conversation that should not become a record at all.
5. Run it for a fortnight and read the records it created, because that is the only way to find out 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; details are on the pricing page.

The consent trail

If the point of this integration is to contact people later, the consent position has to travel with the record and be more than a flag.

What they agreed to, specifically. Reminders about work in progress and marketing about other services are different things.

When, and how. The wording they saw and the mechanism, not just a date.

Which channel, since agreeing to be messaged is not agreeing to be called.

Withdrawal, recorded the moment it happens and applied everywhere.

Remember the PECR distinction here, because a CRM full of sole traders is a CRM full of individual subscribers: limited companies and LLPs are corporate subscribers for electronic marketing, while individuals, sole traders and ordinary partnerships need consent or the soft opt-in (ICO).

A record with a contactable number and no consent trail is a record you cannot safely use for the thing you built the integration for.

The second copy you just created

Worth stating plainly, because integration guides never do.

Your CRM now holds personal data that arrived through a messaging channel. It has its own access list, which is usually wider. Its own retention, which is usually longer or absent. Its own export and reporting, which means copies land in spreadsheets. And its own backups.

Four things follow. The CRM has to be in your data map. Its retention has to be set rather than defaulted to forever. Deletion has to reach it, so an erasure request handled only in the messaging system is not handled. And a subject access request has to be 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 and sorting it out later.

Who owns the conversation afterwards

An operational question that causes real confusion once records exist in two places.

If a salesperson replies from the CRM and a colleague replies in the messaging app, the customer gets two answers. 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.

Decide the 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.

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, since a renamed field fails silently.

Watch the duplicate rate.

Ask the people using it whether the records help, which is a faster diagnostic than any report.

Making it survive

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

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 means two retention answers, and forgetting the second is the common failure.

Automation cannot judge whether a lead is worth having, only what was said.

What to build first

The threshold. Decide what a conversation has to contain before it becomes a record, and write it down. Everything else here is easier to change later; 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 copy you forget 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 is actually known. Creating a record for every inbound message fills the CRM with wrong numbers and empty entries until nobody opens it.

What should the record contain?

Identity as far as you have it, what they want in your own categories, where, when they need it, the source, the consent position, and a link back to the conversation.

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 summary of what they want does not need any of it.

What about photographs?

Leave them out by default. Images carry far more than the subject, and copying them into a second system doubles the exposure for no benefit.

Why is matching by phone number unreliable?

Formatting differences, recycled numbers, shared handsets, multiple numbers per person, and people messaging on somebody else's behalf. Normalise first, and prefer a duplicate to a wrong merge.

What should the consent trail record?

What they agreed to specifically, when and how including the wording they saw, which channel, and any withdrawal applied everywhere. A flag is not a trail.

Does the marketing distinction matter here?

Yes. Limited companies and LLPs are corporate subscribers, while individuals, sole traders and ordinary partnerships are individual subscribers needing consent or the soft opt-in. Most trade CRMs are full of the latter.

What does integrating create that I need to manage?

A second copy of personal data with wider access, its own retention, its own exports and its own backups. It has to be in your data map, your deletion process and your access searches.

Who answers the customer once records exist in two places?

Decide and enforce it: the conversation happens in the messaging channel, the record lives in the CRM, and a person taking over suppresses the automation until they release it.

How do I keep the integration healthy?

Review what is being created monthly at first, delete junk rather than filtering around it, check fields are still populated after renames, watch the duplicate rate, and ask the people using it whether it helps.

Related reading

• Data protection for a messaging bot
• What a bot should remember
• Multi-stage flows and keeping state