What a lead record should actually hold

Every sales office argues about fields. Somebody wants profession added, somebody wants a rating out of five, somebody wants the wife's name because it helps at closing.

The arguments never resolve, because they are being had in the wrong terms — as a debate about what would be nice to know rather than about what will be filled in and acted upon.

There is a single test that settles them. For any proposed field: who reads it, and what do they do differently because of it? If neither half has an answer, the field is decoration, and decoration is not free — it makes the form longer, which makes capture slower, which means fewer enquiries get captured at all.

Identity: the fields that let you find the duplicate later#

The point of the identity fields is not to address the buyer politely. It is so that when the same person appears again through another channel, the system can recognise him.

The phone number is the spine. It is the only field in this market that is close to unique, close to stable, and always given. It should be stored in one normalised form — country code handled the same way every time, no spaces, no hyphens, no brackets — because a number stored two ways is two people as far as any comparison is concerned.

The name is a weak key. The same buyer appears as a full name on one record, an initial and a surname on the second, the same name with ji attached on the third, and a spelling the caller heard over a bad line on the fourth. Regional spellings vary and initials expand and contract. Keep the name, display it, never match on it alone.

Email is weaker still. Many buyers give none, or give one they never read, or give the family address that already sits on the son's enquiry. Store it. Do not build anything on it.

Alternate numbers deserve their own place, not a note in a remarks box. The spouse's number, the son's number, the office landline. These are the numbers that later cause a "new" enquiry that is not new — the whole mechanism is in one buyer, three enquiries.

Source, recorded once and never overwritten#

Source is where this enquiry came from: which portal, which hoarding number, which campaign, which broker, which walk-in.

The rule that makes it worth anything is that it is written at capture and never changed by a later touch. If the buyer later fills a form on the website, the record should gain a second touch — not replace its original source with the website. Every marketing decision you make afterwards depends on that first value being the truth about where the enquiry originated.

Systems get this wrong by design more often than by accident: last-touch overwriting is the easy thing to build, and it makes whichever channel calls last look like the channel that works. What the software does by default is what the numbers will say a year later, which is the argument in defaults are decisions.

Requirement and budget#

Requirement, in the words the buyer used. Two BHK, park facing, ground floor because the mother cannot climb stairs. A dropdown with 2BHK / 3BHK flattens that into a category and destroys the part that closes the sale. Keep a structured configuration field for counting, and keep the buyer's own sentence beside it. Both. They do different jobs.

Budget as a range, with the date it was said. Nobody has one number, and whatever was said in March is not what is true in September after he has seen four other projects. A budget with no date attached is treated as current forever, and the caller works from a figure that expired months ago.

Neither field should be mandatory at capture. A tele-caller with a moment of a stranger's attention gets a name, a number and a project. Requiring the budget before the record can be saved does not produce budgets — it produces records that never get saved, or a column of the same placeholder figure.

Stage, next action, history#

These three carry the whole system.

Stage, defined in words. Not a colour, not Hot / Warm / Cold. Each stage needs a written definition that two different people would apply identically: what has happened for a lead to be in it, and what must happen for it to leave. "Warm" means whatever the person typing it felt that afternoon. "Visit done, objection not yet answered" means something a manager can act on.

The next action, with a date and an owner. This is the most valuable field on the record and the one most often empty. Three parts, all required: what will be done, on what date, by which named person. Not a team, a person. A next action with no date is a wish, and a date with no owner belongs to nobody. The reason to insist on all three is that this is the only field a system can act on by itself, which is the subject of follow-up as a schedule.

History, which is every previous next action and what came of it. Not a remarks box that people append to until it is unreadable. Each completed action keeps its date, its owner, what was promised and what actually happened. This is what makes the record readable by somebody who has never spoken to the buyer — the manager on Monday, the replacement when the executive leaves, the CRM desk after booking.

What not to put in#

Fields nobody will fill. Every optional field that stays empty teaches the team that empty is acceptable, and that lesson spreads to the fields that matter.

A score computed from fields nobody filled. A rating out of a hundred derived from budget, timeline and profession, where two of the three are blank for most records, is arithmetic performed on absence. It looks authoritative on a dashboard and it is noise. Worse, people will start working the score instead of the record.

Free text where a date belongs. "Will call next week" in a remarks column cannot be sorted, cannot be counted and cannot ring. This is the single habit that carries the spreadsheet's central weakness into the new system — leads that die in an Excel sheet is mostly a description of that one failure repeated in different forms.

Anything copied from another record. The project's price list does not belong on the lead; copies go stale and callers quote them.

The short version#

The identity fields exist to catch the duplicate, so the phone number is the spine and everything else is a weak key.

Source is written at capture and never overwritten. Requirement keeps the buyer's own words alongside the structured value. Budget is a range with a date.

Stage needs a written definition, the next action needs a date and a named owner, and the history needs to hold every previous one. And for each new field somebody proposes: who reads it, and what changes because of it.