Contents6 sections
Field notesARTICLE
The Required Field Nobody Fills In
Every CRM has one. It is mandatory, three quarters of records carry the same default value, and everything downstream quietly assumes it means something.
Costa5 min read
Short answer
An assistant should leave a field empty rather than fill it with a plausible value, because an empty field is a visible gap and a guessed one is a false fact that everything downstream treats as true. The right response to a field nobody fills in is to make the gap countable, then either fix the process that should populate it or delete the field.
Key facts
- The assistant writes only values the customer actually gave, and leaves the rest empty.
- An unfilled field is recorded as unknown rather than as a default, so it can be counted.
- Where the fact matters, the assistant asks one short question instead of inferring it.
- Anything ambiguous is handed over with the ambiguity intact rather than resolved by guess.
Every CRM has one. Source, or property type, or segment, or how they heard about you. It is marked required, so it is always filled in, and if you count the values three quarters of the records say the same thing.
That value means nothing. It is what the form insisted on and what somebody picked to get past it, and it has been accumulating for years.
The field, and why it stays empty
Nobody is being lazy. The field is usually asking for something the person filling it in does not know at that moment.
Source is filled in by whoever creates the record, who was not there when the customer decided to write. Budget is filled in before anybody has discussed money. Property type gets a value while the customer is still describing a situation rather than a requirement. The field is not being skipped out of carelessness; it is being answered before the answer exists.
So people put in the first option, or the one at the top, or whatever gets the record saved. The default becomes the modal value in the database, and everything downstream starts treating a shrug as a fact.
Three things downstream that break
Any report that groups by it. The pie chart says most of your leads come from one place, and what it means is that most of your leads were created by someone in a hurry.
Any routing rule that reads it. Records get assigned by a value nobody chose deliberately, which is how a whole category of enquiry ends up sitting with the wrong person for two days.
Anything an assistant reads. This one is new, and it is the reason the old problem has stopped being tolerable. A field that misled a colleague who knew to discount it will not mislead an assistant in the same forgiving way: it reads the value at face value, at speed, in front of a customer.
Why a guess is worse than a gap
An assistant is genuinely capable of inferring most of these. It could read a conversation and pick a plausible source, a plausible budget band, a plausible segment. It would be right a good share of the time.
That is exactly the failure. A gap is honest and countable: you can query how many records lack it and decide whether that matters. A guess is a fact of unknown quality mixed into facts of known quality, and after a month nothing in the system can tell you which records are which. The rule is the same one that governs what an assistant writes into a record at all: never write a value the customer did not give.
What it can honestly fill
More than people expect, and it is worth naming the difference.
What the customer stated, verbatim or as a value. What the system already knows: channel, time, language, which listing or unit the conversation was about. What follows unambiguously from a rule, like a price band that comes out of the quote it just produced.
Everything else stays empty, and the conversation is attached underneath so the person who picks it up can see what was actually said.
Making the gap loud instead of filling it
An empty field only helps if somebody counts it.
One query: records created this month, grouped by whether the field has a real value. Run it once and the honest number is usually a shock, because the previous number was manufactured by the form. Then there are two decisions, and both are fine.
Fix the process: the field gets filled at the moment the answer exists rather than at record creation, by whoever is there when it does. Or accept that nobody will ever know and stop pretending, which brings us to the last option.
The field that should be deleted
Some of these fields are not underfilled. They are unnecessary, and they have survived because deleting a field feels riskier than keeping one.
The test is whether any decision in the business has ever changed because of that value. Not whether it appears in a report, whether it changed something. Where the answer is no, the field is costing you a small piece of everybody's attention on every record, and it has been for years.
An assistant like Omni AI works on top of the CRM you already run, so it inherits whatever your fields are worth. What it will not do is make a thin record look thicker by filling it with plausible values.
Which is why the first month is uncomfortable and worth it. The empty fields were always empty; they had a value written over them. Seeing the real number is usually the most useful audit a business has ever had of its own data, and nobody would have commissioned it.
Questions this raises
- Our CRM will not save the record without that field.
- Then it has an explicit unknown option or it needs one, and adding it takes minutes. A mandatory field with no honest value forces everybody who touches the system to lie in the same direction.
- Could the assistant infer the value from the conversation?
- Sometimes, and that is precisely the danger. An inference is right often enough to be trusted and wrong often enough to matter, and nothing downstream can tell which record is which.
- How do we know which fields are dead?
- Count the distribution. Any required field where one value covers three quarters of records is either genuinely skewed or dead, and one afternoon of reading records tells you which.