A CRM (the system where you keep customers and sales opportunities) is often empty not because it lacks features, but because an entry gets written only when a salesperson finds time for it. Usually that is not straight after the call, and later they remember less. So before you buy a new “CRM with AI”, it is worth naming the problem precisely: it is a capture problem, not a software problem. A system with a language model (an AI program that reads and writes text) that never receives the content of calls and e-mails will be just as empty as the one you have.
The fix I describe in this article is simple to state: after every e-mail thread and every call, the system drafts a proposed entry, and the salesperson approves, edits or rejects it. On our page about AI in the sales team this is one item on a list; here we set that item out in full: where the content comes from, what a good entry looks like, which fields a model should not guess, how to measure the effect, and when the assistant already built into your CRM is enough.
CRM automation without AI: what a rule in the system already handles
“CRM automation” often means something that needs no language model at all. Moving the stage once a quote is sent, by a rule you set, a reminder about a deal that has gone quiet, assigning an enquiry to a salesperson by region, a task created when a deal is won — these are rules that popular CRM systems have built in, and they behave predictably because they do the same thing every time.
If your problem fits this list, start by setting up rules in your current system. A model becomes useful only where someone has to read free-form text written by people — an e-mail thread, a call note, the description in a form — and turn it into CRM fields. Text in a fixed format, such as a submission from a quote generator, can usually be split up by a rule. That is the part of CRM automation the rest of this article is about.
Where the content comes from: e-mail threads, call notes and forms
An entry has three sources, and they are worth taking separately because each has different limits.
- The e-mail thread with the customer. The best source, because what was agreed is written in the customer’s own words, with a date and a sender. The condition: the system needs access to customer correspondence — only to threads with people who are already contacts in the CRM, or to a copy of the correspondence stored in the CRM, not to the salesperson’s whole mailbox. Private mail and mail unrelated to sales should never reach the model at all.
- The note after a call. A few sentences typed or dictated by the salesperson straight after a phone call or meeting. This source needs no recording, and the model turns it into a structured entry in place of the salesperson.
- The form on your website. An enquiry from a new customer: the contact details are in separate fields, and the description of the need is free text the model can break down into fields.
A transcript of a recorded call (its written record) is a variant of the second source, not a separate category — and it inherits every obligation that comes with recording. We do not repeat the legal basis here; we set it out on our voicebot page, in the section “Call recordings are personal data”, and in our article on GDPR (the EU General Data Protection Regulation) in language-model projects, in the part on the lawful basis. For a CRM-entry project, those rules leave three things to build: the notice telling the other person that the call is recorded and why; an agreed retention period for recordings and transcripts, after which they are deleted; and an entry that holds only the fields sales needs, not the whole conversation copied into a note.
Anatomy of a proposed entry
A good proposed entry is not a call summary. A summary gets read; an entry changes CRM fields, so every field has to be checkable in a few seconds. We suggest this layout:
- Contact and company — who wrote or who the call was with, matched to an existing CRM contact or marked as new.
- Source — a link to the thread, note or form the entry came from.
- What was agreed — two or three sentences, without judgements and without details that are not in the source.
- Next step with a date — who, what and by when; if the source has no date, the field stays empty with the note “no deadline”, not with a date the model made up.
- Open questions — what the customer asked that nobody has answered yet.
- A quote next to every field — the source passage the field was taken from, so the salesperson does not have to open the whole thread.
The salesperson has three buttons: approve, edit, reject. Every decision is recorded, because those records are how you judge whether the system works (more on that below). How to design the approval itself — what the approver must see, within what time, and when oversight can be relaxed — is covered in our article on human in the loop.
Which fields the model fills in, and which it never guesses
This is the most important table in the article. It splits the fields of an entry into three classes by where their value comes from, not by how well a given model performs.
| Field class | Examples | What the system does | What the salesperson does |
|---|---|---|---|
| The value is written in the source | contact, date of the call, what was agreed, the next step and its deadline, the customer’s questions | fills in the field and attaches a quote from the source | checks and approves |
| The value is in the source but needs interpretation | the customer’s objections, a competitor mentioned, who decides on the customer’s side | proposes a value flagged for checking, with a quote | decides whether the interpretation is right |
| The value is a decision, not a fact | deal value, probability of winning, stage change, discount | does not fill it in; may quote a figure from the e-mail in a note, with its source | enters it personally or leaves it unchanged |
The rule that keeps the third class in order: anything that feeds the sales forecast or deal scoring is entered by a person — whatever class the field would otherwise belong to, and whatever the pilot shows. If the customer mentioned their budget in an e-mail, that is worth recording in a note — but the deal value is the salesperson’s decision about what they will realistically sell. A model filling it in from e-mails would put numbers into the forecast that nobody stands behind.
The second class is the most interesting one in a pilot. How closely a salesperson has to check fields such as “competitor mentioned” is settled on your data, from the approval log, not in advance. The field’s class does not change: an interpretation stays an interpretation, even when it is often right.
Two CRM hygiene numbers you can count today
Before you deploy anything, write down two numbers. Check whether your CRM can count them with a filter — neither needs an integration.
- The share of open deals with a next step that has a date. Filter: open deals that have a planned activity (a task, meeting or call) dated today or later. Divide their number by the number of all open deals. A deal without a next step is usually a deal nobody is keeping track of.
- Deals without contact. Filter: open deals with no customer contact or sales action for N days. Set the number of days yourself, based on the length of your sales cycle, and do not change it later. Neither an entry added by the system nor a scheduled task is contact, and an entry filled in after the fact counts from the date of the conversation, not the date it was saved. Write down how many such deals there are.
We do not give values these numbers “should” reach, because they depend on your industry, the length of your cycle and how your team uses the CRM. What counts is the change against your own starting point: the same filter before the pilot and after it. Both numbers show how orderly the CRM is — whether agreements and next steps actually reach it. They do not measure whether the system reads e-mails and notes well (the pilot log described below shows that), nor whether salespeople contact customers more often: better capture can also reveal deals where nothing has happened for a long time.
AI in your CRM: a built-in assistant, or an integration with the system you already have
Some CRM systems already have assistants that do something similar. Before you commission an integration, check exactly what they do — not from the pricing page, but from the documentation. Below is what the documentation of three CRM systems describes, as at 12 October 2026. This is not a ranking and we do not compare prices; availability depends on the plan and can change.
| System and feature | What it uses | What it drafts | Does anyone approve before saving |
|---|---|---|---|
| HubSpot, deal progression card (beta; Sales Hub and Service Hub on Professional and Enterprise plans) | e-mails, notes, and call and meeting transcripts logged in HubSpot; requires recording and transcription to be switched on, plus HubSpot Notetaker or a connection to Zoom, Microsoft Teams or Google Meet; salespeople need an e-mail inbox connected to HubSpot | suggested deal property updates (the screenshot in the documentation includes amount and next step) and recommended actions | each suggestion is accepted or dismissed; there is also an “approve all” button, and auto-updates can be switched on in the settings |
| Bitrix24, CoPilot in CRM | phone call recordings (from 10 seconds to an hour) and chats recorded on potential customers and deals (in Bitrix24: leads and deals), and e-mails stored in the CRM — in leads and deals it processes the first incoming e-mail automatically by default, and the settings offer manual processing or automatic processing of all incoming, all outgoing or all e-mails; in contacts and companies, manual only | transcript, summary, filled-in fields in the CRM form | fills empty fields straight away and marks them; when a field already has a value, it suggests a change to confirm |
| Livespace, AI suggestions and note summaries | notes and calls; the documentation states that suggestions do not work for e-mails | suggested tasks with the title and date filled in, summaries of long notes | according to Livespace, AI only adds information and only after you approve it; it does not change or delete existing data |
Two practical observations follow from this table. First, the assistants differ in whether they change fields without asking: Bitrix24 fills empty fields straight away, HubSpot waits for acceptance but lets you switch on automatic updates, and Livespace states that it saves nothing without approval. Second, they differ in their sources: HubSpot and Bitrix24 read e-mails and calls stored in the CRM (HubSpot also notes, Bitrix24 also chats), while Livespace’s suggestions use notes and calls, but not e-mail. Also check where the content goes — Livespace, for example, says it sends note content via an API (an interface for exchanging data between systems) to OpenAI and that it is not used to train models.
A built-in assistant is enough when three conditions hold: you use one CRM, your reps’ e-mails and calls already pass through it, and its settings let you approve changes in the fields that matter to you and switch off changes to third-class fields and to any field that feeds the forecast or deal scoring. The automatic updates some systems offer are a capability, not a recommendation — leave them switched off in the first version. Then an integration has no justification.
An AI integration with the CRM you already have makes sense in the other cases: when e-mail or phone calls happen outside the system, when an entry needs data from several places (for example an order status from your ERP system, the software for orders, stock and invoices), when your CRM has no such assistant, or when you want a “no field without a person’s decision” rule that the ready-made feature does not give you. How to connect to popular CRM systems technically is covered in our article on AI integration with ERP and CRM, and the general rule for choosing between a ready-made tool and a project in our article on how to implement AI in a company.
What a pilot of AI in the CRM records
A pilot has to answer one question: does the field-class table above hold on your data? That is why it records decisions, not just whether the system runs.
- For each entry: the source (e-mail, note, form, transcript), the time from the end of the call or the last e-mail to approval, and the decision: accepted unchanged, edited or rejected.
- For each field: whether it was accepted unchanged, edited (with the kind of edit, for example a different date or a different contact), rejected by the salesperson, or left empty because the source had no data.
- For rejected entries: the reason in a few words — wrong contact, a thread unrelated to sales, an unnecessary entry.
- Missed entries: entries the salesperson added by hand because the system did not propose them.
The log contains customer data, so record only what the assessment needs — the kind of edit rather than the full content — and delete it when the pilot ends, by the agreed date.
A field that salespeople often edit needs better extraction or more careful checking. A first- or second-class field accepted unchanged over a longer period may get lighter oversight — never a third-class field, nor any field that feeds the forecast or deal scoring — but that is a decision taken on the data, following the rules in our article on human in the loop. The system’s permissions and the record of what it does in your systems are a separate topic, covered in AI agent vs chatbot. The stages of the pilot itself are described in our methodology.
When not to automate CRM entries — and what is deliberately missing here
Do not start if the real problem is that nobody looks at the CRM. Automatic entries will fill a system that still nobody reads. First settle who uses the CRM and for what — for example, whether the sales manager runs a weekly deal review in it. Do not start either when there are so few calls that a manual entry is a moment’s work, or when the assistant built into your CRM already handles your sources.
This article deliberately leaves out deal scoring (lead scoring) and automated message sequences to customers. We leave scoring out because you first need reliable data in the CRM, and an empty CRM does not have it — which is why we start with capture. Following up with a customer appears here only as the “next step” field on an existing deal: the system can draft a reply in an ongoing thread only when a next step has already been agreed with the customer. The salesperson always sends the draft. We do not build cold e-mail automation at all; why is explained on our what we don’t do page.
If, after counting the two numbers, you can see that the problem is capture rather than the CRM itself, this is exactly what we build at ploch.ai: proposed entries from e-mails and calls for approval, in the system you already have. More on which processes are suited to AI automation is on a separate page, and what makes up the cost of such a project is in our article on how much an AI implementation costs. When entries are meant not only to be created but also to trigger actions in other systems, that is already an AI agent project.
Sources, as at 12 October 2026
- HubSpot — “Move deals forward with deal progression” — a beta feature on Sales Hub and Service Hub Professional and Enterprise; uses logged e-mails, notes and transcripts, suggests deal property updates to accept or dismiss, with “approve all” and auto-update options; read 12 October 2026.
- Bitrix24 — “CoPilot in CRM: Call transcription and automatic field updates” — transcription, summary and filling of empty fields from call recordings; a suggested change to confirm when a field already has a value; page updated 5 October 2026; read 12 October 2026.
- Bitrix24 — “CoPilot in CRM: Transcribe call recordings and analyze chats” and “CoPilot in CRM: How to process an email” — chats and e-mails as sources; empty fields filled automatically, changes to filled ones confirmed; by default the first incoming e-mail in a lead or deal is processed; read 12 October 2026.
- Livespace — “AI in CRM” — the statement that AI only adds information and only after approval; read 12 October 2026.
- Livespace — “Asystent AI w Livespace” (in Polish) — AI suggestions from notes and calls, not available for e-mails; summaries of notes longer than 200 characters; note content sent via an API to OpenAI and not used to train models; read 12 October 2026.