AI telesales CRM fields: a technical checklist

The field list is the report

The most discussed part of call automation is the script; the least discussed is what the call leaves behind in the CRM. Yet it is that second list which decides what any report can ever show.

The rule is simple: nothing that is not stored as a field can be measured. If the customer's budget came up in the conversation but was written into a free-text note as a sentence, the information exists — and it is not in the report, not in a filter, and not in a campaign.

This article is the CRM field checklist for a calling flow: the mandatory minimum, how outcome codes are built, the fields extracted from a call, the place of free text, field design rules, what should not be stored, and how to add fields to a database that already exists.

The mandatory minimum

The minimum set for a calling flow is eight lines. With fewer, reporting cannot be built; with many more, the first stage does not need them.

• Lead status: new, in progress, won, lost, unreachable
• Stage: where it sits in the pipeline
• Source: where the enquiry came from, at campaign level
• Owner: whose work it is now
• Contact attempts: how many times it has been called
• Outcome code of the last call
• Date of the next step: a specific day
• Close reason: for closed leads only, from a fixed list

With those eight you can already calculate conversation rate, qualification rate, attempts and follow-up delay. Most of the reporting rests on eight fields.

Usually six of them already exist and two are missing: the date of the next step and the close reason. Those two produce the most and are the cheapest to add.

Outcome codes have to be a fixed list

An outcome code says in one word how a call ended, and it must not be free text. A result written as prose cannot be counted — «spoke», «talked», «made contact» become three rows and three different values.

• Conversation happened — interested
• Conversation happened — not interested
• Conversation happened — call back later (date and reason required)
• No answer
• Unreachable or wrong number
• Wrong person or wrong company
• Handed to an operator

There should be no more than seven. On a long list the operator starts thinking and picks the most general option — so the list is long and the data is poor.

One code carries a special rule: «call back later» can only be written together with a date and a reason. Without that constraint it becomes the place every unresolved case accumulates.

Fields extracted from the call

When an AI voice agent is used, the scenario decides in advance which fields the conversation has to produce. That list is as important as the script and should be kept short.

1. 1Fit fieldsProduct or service category, scale, budget range, timing. These are qualification itself and the most used fields in any report.
2. 2Decision fieldsWho decides, whether further approval is needed. One field, a fixed list of two or three options.
3. 3Contact fieldsConvenient hour, preferred channel, alternative number. These three change the result of retries directly.
4. 4Outcome fieldsOutcome code, next step, date of the next step. Written at the end of the scenario, and never left empty.

Once the extracted list passes ten or twelve, the call lengthens and the risk of it being cut short rises. Six or seven is enough in a first version; the rest is collected at a later stage.

Free text: one sentence, no more

A free note field is needed, but its role is narrow: it holds the nuance the fields do not capture, and it exists for the next conversation rather than for reporting.

The practical form is a one-sentence summary: the main issue in the customer's own words. A long note does not get read on the next call — the rep does not have time for five lines before dialling, but will glance at one.

The second rule for free text: nothing kept there should be used for reporting. If a piece of information keeps appearing in the notes and keeps being needed in a report, it should become a field. Searching the notes as a substitute for reporting works for a while and then stops.

Field design rules

How a field is built decides whether it gets filled in.

• A fixed list wherever possible — free text only where it is unavoidable
• A date field is a date type, not text — otherwise filters do not work
• Keep mandatory fields few: too many produce false completion
• Name the field in the words the team uses, not in system terminology
• Every field needs an owner: who fills it in, and at which stage
• A field no longer used is deactivated rather than deleted — the history survives

The third line deserves emphasis. As the number of mandatory fields grows, the operator finds the quickest way to satisfy them — usually the first option in every list. The data then exists and is wrong, which is more dangerous than an empty field.

What not to store

What is not written to the CRM requires as much of a decision as what is.

The second group is an operator's subjective judgement. Notes like «not a serious customer» or «waste of time» get in the way of whoever works that account later, and become a problem if the customer ever makes a data request.

The third group is data that already lives in another system. Order history, payment status and stock levels belong where they are and should be displayed through an integration when needed. A copied snapshot is stale within a fortnight.

Adding fields to an existing database

Most companies are not starting from nothing: the CRM already holds thousands of rows, and new fields will be empty for all of them. That is normal and should be planned for.

1. 1New fields are required going forward onlyTrying to fill old rows by hand is the most commonly abandoned project. The field becomes mandatory for calls from today.
2. 2Backfill automatically where you canFields like source, date and status can often be derived from existing data.
3. 3Reporting accounts for the transitionCompletion rates are low in the first months, and that does not mean the system is failing. Compare within the new period only.
4. 4Clean out the old fieldsAdding a field is a good moment to deactivate two or three that are no longer used. More fields always means a lower completion rate.

Measuring completion

The fields themselves have to be measured, because a field that is not filled in is the same as a field that does not exist.

• Overall completion: what share of mandatory fields is filled
• By field: which one is empty most often
• By operator: this is a behaviour and should be measured
• How often «other» is chosen: if it is high, the fixed list is incomplete
• Value distribution: if one option is picked 90 per cent of the time, the field carries no information

How these connect to the wider call reporting is shown in telesales call metrics, where outcome code completion is the condition on which the other six metrics can be trusted.

Fields on the Vexvon side

Vexvon's CRM side holds most of this checklist as standard.

• Lead: status (new, in progress, won, lost, unreachable), stage, category, priority, close reason, contact attempts, reminders and a duplicate link
• The customer record ships with nine default pipeline stages, adjustable per company
• Custom fields can be added as JSON — sector-specific fields do not require a model change
• The fields to extract from a call are defined at scenario level
• A one-sentence summary is produced from the conversation
• One timeline shows events from ten sources in order
• CSV import checks for duplicates

The full field list and the structure of the customer record are on the CRM page. What gets written to the customer record on the chat channel is covered in chatbot and CRM: the customer record — the fields there differ because the channel does.

First step

Open the CRM and check which of the eight fields exist. The two that are missing are usually the date of the next step and the close reason — and adding them is an hour's work.

Then look at the list of outcome codes: if there are more than seven, shorten it. To build the field set for your own process, get in touch.