Maciej Nuzia · CRM
Email threads and notes often contain information missing from CRM fields. A model can prepare a contact summary, suggest a value for a missing field or flag possible duplicates. Whether it only suggests a change or can write it to the CRM depends on the permissions and process used by the company.
The model gets access to the fields you point at, and to no others.
The database
A salesperson walks out of a meeting with three things to remember and straight into the next one. What reaches the record afterwards is the name, the amount and the stage, because the form insists on those. Everything that was agreed stays in the email thread and the calendar, outside the fields the report is built from. Six months later somebody else opens that record and tries to work out where things stood.
Who it's for
A sale closed in a single phone call leaves nothing on the record but the amount. When an account runs for months and several people from both sides sit in the thread, the contact history gets thick, and that is the raw material here. So I ask whether correspondence with customers reaches the CRM at all, because the model reads only what is inside it.
On the record
Somebody leaves the company, or an account changes hands. The model puts a few paragraphs together out of the whole contact history: what was agreed, what the customer turned down, who decides on their side. Every sentence keeps a link to the message it came from.
The same customer entered three times, each time a little differently. The model points at the pairs that look like duplicates and shows what sits on one record and is missing from the other. Merging I leave to a person, because there is no undoing it.
Industry, company size, who makes the decision on the other side. The model gives a value together with the sentence from the correspondence it rests on. Where the history holds no such sentence, the field stays empty.
A deal marked as negotiation, the last message in the thread six weeks old. The model puts the two side by side and sets deals like that aside for review before the forecast.
A new name appears in copy on the thread, and somebody who used to reply goes quiet. The model adds changes like that to the contact list on the record, so the list keeps up with who is actually writing.
"Which customers asked about warehouse integration this year?" The model goes through the contact history and returns the records together with the sentence that put each one on the list. On policies and contracts that same job belongs to RAG for business.
When a CRM entry is only one stop on a longer route between systems, the page you want is AI process automation. Tickets arriving from customers stand in a queue of their own, which is where AI customer support automation picks up.
From reading to writing
People write to those records, and they remember what they put there themselves. A change nobody asked for stands out faster than any report.
01
I ask about the pipeline: what each stage means, who moves a deal along and which fields end up in the report. That turns into a list, and the fields nobody in the company can define drop off it. A field with no agreed meaning is one the model fills in its own way, consistently, across the whole database at once.
02
The model reads the contact history and writes out what it would add to the records. None of it reaches the database. We go through that list with the sales team, because they can tell from a single sentence that a thread was read the wrong way.
03
The first writes arrive on the record as proposals. The owner takes them or turns them down, and whatever is taken stays marked in the history and can be undone.
04
I switch writing on for the field that drew the least argument on that list, and for one team. Then I look at the rejections: how many there are and which fields they gather around. The rejections are the list of fixes, and they also show when another field can be added.
Technologies
The model does not live inside the CRM. It stands next to it and talks to it through the API, like every other tool you have plugged in. ChatGPT reaches it through the OpenAI API, by the same entrance an Anthropic model uses when that suits the reading better. Contact history can be long and APIs have their request limits, so I spread the first pass over the database across stages.
After the write
A salesperson opens their record and finds a sentence they never wrote. When there is no telling where it came from, they go back to their own notebook. So every entry from the model is marked and carries its source, and taking it back goes as far as your CRM allows.
A record filled in to the last field looks like one somebody checked. The fewer questions it raises, the longer an error lives in it. So a value from the model stays recognisable on the record until somebody confirms it. Where that mark can sit depends on what your system lets anything write.
The contact history holds sentences written for a colleague: about health, about family, about who on the other side is easy to deal with. Nobody who wrote them expected a machine to read them. So notes are treated differently from fields, and the model reaches into them only where the task cannot be done without them.
FAQ
What counts is what your system exposes and what it lets anything write back. HubSpot, Pipedrive and Salesforce document both, so reading the history and writing to a record travel the same road. With a CRM built inside the company I ask about those two separately, because writing is often closed off even where reading is wide open. It also happens that a model is allowed to add a note while a field somebody once added by hand stays out of its reach.
Anyone who opens the record. An entry from the model arrives with a link to the message it was built on, so its origin can be checked without asking anybody. At the start each one waits for the record owner, who takes or turns down the proposals one by one. Before the model proposes anything, every record needs a person for that proposal to go to.
The model works on one record at a time and sees as much of it as the task calls for: a thread, a note, a handful of fields. Whole categories of records can stay out of its reach, and phone numbers and addresses can be hidden before anything goes out. Where the model itself stands is something we settle separately: some providers undertake not to train on anything you send them, and where the database has to stay in the company, the model moves closer to it. The list of fields and records kept out of reading is yours to hand me.
I do not have a number for that, before looking at the database or after. What can be filled in is whatever somebody once wrote a sentence about: if company size appears in no thread at all, the model will not invent the value, and it should not. When a record is a company name and a phone number, and the selling happens out loud, the contact history holds no sentences to read. What I suggest then is tidying the database itself, with no model over it.
A first email
Write down what you keep customers in and who makes sure the records stay current. Two sentences like that show whether the contact history holds anything worth reading, and who the proposed entries would go to. You will get an answer just as short: what can be pulled out of a database like that, and which field I would start writing to.