Answer
How do you use AI with your CRM data?
Reading and summarising, yes. Writing back only through defined fields, because a record other people rely on is not a draft.
Use it to read: summarise a customer's history, extract fields from correspondence, find records matching a description. Restrict writing to named fields with validation, because a record other people act on is not a place for a plausible guess.
The reading uses are immediate and low-risk. Summarising everything that has happened with a customer before a call, which otherwise means reading twelve emails. Pulling structured details out of correspondence so they land in fields rather than staying in notes. Finding the records that match a description you can express in words but not in the search box. Each of these saves real time and none of them changes anything, so an error costs a moment rather than a record.
The writing case is different in kind. A CRM record is a shared assertion that other people act on, often months later and without the context that produced it. A wrong stage, a wrong owner, a wrong next action or an invented detail propagates into decisions nobody connects back to its source. So writing should be restricted to specific fields, with validation on each, rather than granted as general update access.
Extraction into fields is the highest-value writing case and it is defensible because it is checkable. The extracted value sits next to the text it came from, so a person can see both. Where the field is constrained — a category, a date, a value from a list — the validation is straightforward, and where extraction fails the correct behaviour is to leave the field empty rather than to guess, since an empty field is visible and a wrong one is not.
Two practical constraints are worth stating. A CRM connector typically grants access to all records rather than to the relevant ones, so the scope decision is made at authorisation and should be narrowed there if the tool allows. And customer records frequently contain material that should not leave the business, which makes the reading decision and the disclosure decision the same one.
The pattern-finding uses are attractive and need more care than the others. Which customers look likely to leave, which enquiries resemble ones that converted, which accounts are underserved: these are inferences about named parties from limited data, and they are wrong often enough to matter while being expressed with complete confidence. Treat them as a list to look at rather than as a conclusion to act on, and never let one write a judgement into a record the customer's next contact will read.
A CRM record is read by people who were not there, which is why a confident wrong entry outlives every conversation about it.
Siddharth Sharma, Context Theory
Related questions
Can AI clean up a messy CRM?
It can identify duplicates, standardise formats and flag inconsistencies well, and the work should land as a proposed change set rather than as direct edits. Deduplication in particular is a judgement about identity — two records may be one customer or two people at one company — and the cost of merging wrongly is much higher than the cost of reviewing a list.
Should AI write call notes into the record?
A summary attributed as a summary, yes, and it is one of the more useful applications. What matters is that it is marked as generated and that the source remains available, because a later reader treating a summarised paraphrase as a verbatim record of what was agreed is the failure this creates.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Close rate — response under 5 minutes vs over 24 hours | 32% vs 12% | Category-wide |
| Odds of qualifying a lead — replying within the first hour vs after it | 7× | Category-wide |
Optifai speed-to-lead benchmark · n=939 companies · Q2 2025–Q1 2026 · verified
Oldroyd, McElheran & Elkington, "The Short Life of Online Sales Leads", Harvard Business Review (March 2011) · 1.25M inbound leads across 2,241 US firms · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Software | A customer record is acted on later by people without the context that produced it, so a wrong stage, owner, next action or invented detail propagates into decisions that are never traced back to their origin. | Tracing a decision made from a record back to who entered the field it relied on and when. |
| Workflow | Extraction into constrained fields is defensible because the extracted value sits beside its source text and the field's permitted values make validation straightforward, with an empty field on failure being visible where a guessed one is not. | Checking whether the workflow leaves a field empty or populates it when extraction is uncertain. |
| Constraint | Customer record connectors typically grant access at the level of all records rather than the relevant subset, so the reading decision and the disclosure decision about what leaves the business are made together at authorisation. | The permission scopes offered when authorising a customer-record integration. |
| Buying behaviour | Predictions about named customers from limited record data are expressed with full confidence and are wrong often enough to matter, so they belong as a list to review rather than as a judgement written into a record the customer's next contact will read. | Checking a set of past churn or intent predictions against what actually happened. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one