Articles

What a CRM has to record before it is worth anything

Six facts worth keeping about a buyer, why contacts and opportunities are different records, and the field every team skips.

By Anes Hamdaoui6 min read
  • crm
  • data
  • sales
All articles

A CRM earns its keep when it holds six things nothing else holds: who decided, how they decided, what this customer bought before, who else is involved, what they refused, and what happens next. Most systems, used daily, record none of them: their fields describe a sales method, not a customer. The record is worth something the moment a colleague who never met this buyer can continue the conversation without calling anyone.

What are the six facts a record has to hold?

Who decided. Not the job title on the card — the person who can say yes and the person who can say no, usually two people. A record with one name and one number often has the wrong one.

How they decided. The comparison they ran, whom they asked, what worried them. One sentence carries it: came through a referral, compared two quotes, wanted delivery before the season. That predicts the next four calls better than a probability.

What they bought before. From you and from someone else. A customer already running a system asks different questions, and one burned once needs the warranty conversation early.

Who else is involved. The accountant who signs, the brother who owns the shop, the technician who will use it. Deals die in rooms nobody recorded.

What they refused. The option rejected and why. It is the most useful thing in the file and the first thing deleted, because it is not required and writing it feels like an essay.

What happens next. One sentence, one date, one owner. Not a stage, not a percentage. "Send the delivery schedule Thursday, Anes" tells the next reader whether the record is alive.

None are features. They are what a salesperson says on the drive back; a system with nowhere to put the answer is a filing cabinet for phone numbers.

Why do a contact and an opportunity have to be two records?

Because a person outlives a purchase. The contact is who they are: the number that answers, the name they are called by, everything said to them. The opportunity is one discussed purchase, with a start, a value and an outcome. Merge the two and every deal overwrites the last one.

The damage is specific. The status field then means two things at once — whether this person is alive to us, and whether this deal is open — so the report guesses. A second purchase destroys the record of the first, and a buyer who refused in March and returns in October leaves one record instead of two. Keep the contact, open a new opportunity, close the old one with its reason.

What happens when the notes field becomes the real database?

It does, in every system that has one, because free text accepts what structured fields refuse. That is not the failure. The failure is notes with no shape, which nobody can search.

Four habits keep them useful. Date every note and sign it. One note per event, not one growing wall per customer. Newest at the top. Write facts rather than opinions: "asked for the invoice in the company name, accountant needs it Monday" survives a change of salesperson; "difficult customer" does not.

The other half is promotion: a sentence that appears in twenty records is a field asking to exist, if anyone will filter by it.

Which field does every team skip, and always needs?

The reason a deal was lost. It gets skipped because it arrives at the worst moment, when nobody wants to write about a failure.

So do not ask for a paragraph. Ask when the record closes, offer short structural reasons — price, timing, no stock, nothing decided — with one line of text beside it. Require it on the losing path only, and keep "no answer" as an honest option. Count how often it is chosen: that count measures the team, not the customer.

The field answers the only question that changes what you sell: is the offer wrong, the delivery wrong, or the price? It also needs a reader: once a month somebody opens the last twenty losses, because a reason typed by the person who lost the deal is a claim, not a finding.

How do you test whether a record is good enough?

Hand it to someone who has never spoken to the customer, and give them two minutes. They should be able to say who decides, what the buyer wants, what has been said, and what happens next. If they must call the account manager, the record is a personal memory with a login attached.

The fact Where it lives Without it
Who decides, who is involved A contact per person A deal stalling in an unrecorded room
How they decided, what they refused A dated note per event Every call starts from zero
What they bought, what is next One opportunity per purchase History overwritten

It also has to survive the salesperson: if the only person who can interpret it has left, the file is a diary that cannot be handed over.

A decision procedure

  1. Take the last ten deals and answer the six questions from the record alone. Note what you cannot.
  2. Split the model: contacts for people, one opportunity per purchase, the old one closed.
  3. Build the field list from the questions you failed. Delete what nothing answers.
  4. Give notes a shape: date, author, one event, newest first.
  5. Make the lost reason a short list plus one line, asked when the record closes.
  6. Hand five records to a colleague who does not know those customers. Whatever they ask is the missing field.
  7. Check one number monthly: records with no next step.

Where this goes wrong

  • The record is measured by activity. Calls logged, emails attached, fields filled. A complete record can still say nothing about the buyer.
  • The pipeline becomes a to-do list. A deal sitting in a stage with no date is stored, not worked.
  • Notes are written for a manager. The colleague who needs a briefing gets a transcript.
  • Every loss is price. Price is the reason nobody argues with, so it answers everything.
  • The import decided the model. A flat spreadsheet loaded as one table, so person and purchase were never separated.

What this does not cover

This is about what a record must contain, not which product to buy, and it does not cover migrating years of history. It assumes the salesperson knows the buyer: where the buyer comes through a distributor or a tender, how they decided may be unknowable, and recording that beats inventing a reason. No schema makes a team write things down if it has decided not to; a field can only stop punishing those who do.

We build the record around the questions a buyer actually asks — six facts, people kept separate from purchases, a lost reason somebody reads — then test it on the colleague who inherits it.

Services in this article

Start a project

Have something to build?

One short brief is enough. You get a written scope and a fixed quote before anything starts.