Chatbot and CRM: What to Write to the Record
If nothing remains after a conversation, you have automated the exchange and thrown away the only durable thing it produced. But the opposite extreme costs just as much: forty fields, none of them filled, or filled and never acted on. This article separates what a conversation should write to the CRM from the fields that merely occupy space. It covers the seven fields worth writing, the ones that only look useful, how duplicates have to be matched and linked, how to verify that what was written is true, and the four figures worth measuring.
A conversation with no record is a lost asset
The most undervalued output of a chatbot project is not the conversation. It is the record left behind. The conversation ends, the customer leaves, and six weeks later the company has forgotten what it learned — while in those six weeks that person either bought from a competitor or is still deciding.
The opposite extreme is a genuine problem too. Teams create twenty fields, fill them with AI, and make no decision on the basis of any of them. A field that is populated but unused is not free: it pollutes reporting, produces contradictory data, and eventually causes someone to make a wrong call on the strength of it.
The practical rule is this: a field should exist only if someone behaves differently because of it — sorts, filters, routes, or uses it on a call. If that question has no answer, the field should not be created.
The seven fields worth writing
- Source and channelWhich channel and which page the conversation came from. This is the only reliable attribution point marketing gets, and it cannot be reconstructed later — if it is not written at the time, it is gone.
- IntentSales, support, information, unrelated, complaint. Five values is enough. A thirty-intent taxonomy is a field nobody can filter on.
- Product or service of interestSpecific, not free text. The product or category named in the conversation. This is the field that most changes how the follow-up call opens.
- TimeframeAs a normalised value: this month, this quarter, distant, unknown. 'In three months' and 'next quarter' must land in the same bucket, or the queue cannot be sorted on it.
- Contact details and permissionA number or email, plus the context in which it was given. Knowing the customer is expecting a callback changes how the call should open.
- A one-sentence summaryWhat the conversation was about, in human language. This is the field a salesperson uses to get oriented without opening the transcript, and in practice it is the most-read field on the record.
- A link to the transcriptLinked, not embedded. The full text should not fill the record's main view, but it must be one click away.
What not to write
- A budget the AI inferred. If it was not stated explicitly, the field is fiction and it will be wrong on the first call.
- Whether the person is a decision maker, unless they said so. It is among the most commonly mis-extracted fields.
- A sentiment score, if you do nothing with it. The number looks interesting and changes no decision.
- The full conversation text in a primary field. It makes the record unreadable and ruins search.
- Company names extracted but unverified. A wrong company name makes the right one harder to find.
- The bot's own confidence score. Useful for debugging the model, not for sales, and it has no place on the record.
Duplicates and matching
This section looks technical and it is what actually decides whether the CRM is believed. If the same person returns three times across two channels and produces three records, your 'new leads' figure is inflated threefold and somebody will call them three times.
- Choose a stable key: phone number is the most reliable in most markets, email second.
- Recognise the number in the formats customers actually write — with and without country code, with spaces, with brackets.
- Link duplicates rather than deleting them. Deleting loses history; linking keeps both conversations under one person.
- Exclude the company's own numbers, or internal tests become leads and corrupt the reporting.
- Decide what happens when an existing customer writes from a new number — the most common matching gap there is.
Quality: is what was written true?
An automatically extracted field is always somewhat wrong, and that is acceptable — provided the direction of the error is known. Two rules govern this.
First: when uncertain, leave it empty. An empty field tells a salesperson nothing; a wrongly filled one sends them in the wrong direction. Measure the empty rate — it is the most honest indicator of the model's own confidence that you have.
Second: a buyer-intent filter has to run before a lead is created. A phone number appearing in a conversation does not make it a lead — the person could be a job applicant, a student, or someone quoting their own number for comparison. Without that filter, the CRM quickly becomes a list nobody trusts.
What to measure
- Field fill rateWhat share of records have each field populated. A low figure means either that the field cannot be extracted or that it was never needed.
- Field accuracy, by sampleCheck fifty records against their transcripts each month. It is manual and it is the only real verification available.
- Duplicate rateLinked duplicates as a share of all records. A rising figure means matching has broken.
- Field usageWhich fields are genuinely used in filters, reports and sorting. A field nobody has used in six months should be deleted.
What Vexvon writes from a conversation
In Vexvon extraction runs on the conversation. Phone numbers are detected through a five-stage process, free-form fields are extracted alongside them, and a one-sentence summary of the conversation is written — three of the seven fields above exist in the system already.
A buyer-intent filter runs before a lead is created and removes false leads; the company's own numbers are excluded. Duplicates are detected and linked rather than deleted. The lead record carries status, stage, category, a priority marker, a close reason and a contact-attempt count.
On the customer side, the built-in CRM ships with a nine-stage pipeline by default — New Lead, Waiting, Needs Follow-up, Needs a Call, Interested, In Discussion, Won, Lost, Blocked — with coloured tags and JSON custom fields. A 'left a number' tag is applied automatically. CSV import accepts name, phone and email with duplicate checking.
A unified timeline assembles a chronological feed from ten sources, so someone who wrote on Instagram, messaged on WhatsApp and then called is one record rather than three. Every action is written to an activity log covering ten types, and a trigger delivers the lead onward to a Telegram notification, Bitrix24 or the built-in CRM.
Frequently asked questions
- What is chatbot CRM integration?It is the writing of what a conversation produced into the customer record the sales team already works in — extracted fields, a summary, a link to the transcript and the lead itself. Data that stays in a chat log does not count as integration.
- Which fields should be written?Source and channel, intent, product of interest, a normalised timeframe, contact details and permission, a one-sentence summary, and a link to the transcript. Seven fields is enough for most teams.
- Should budget be recorded?Only if the customer stated it. An inferred budget is wrong on the first call and costs the salesperson's trust in the record permanently.
- How should duplicates be handled?Match on phone or email, link rather than delete, and exclude the company's own numbers. Without matching, the 'new leads' figure inflates.
- How do you verify what was written?Check fifty records against their transcripts by hand each month. There is no other reliable method, and it takes about an hour.
- When should an operator edit the record?Whenever they hold information the conversation did not contain, and the moment they see an extracted field is wrong — the correction belongs on the record, with a trace in the log.
Start by reading fifty records
Before redesigning the CRM schema, open fifty lead records from last month and ask one question of each: could a salesperson walk into a call ready, from this record alone? Where the answer is no, write down what was missing. That list is your real field requirement, and it is usually shorter than the schema you already have.