What a customer record should contain

A customer record is what your business remembers about a person after the conversation ends. Everyone agrees it matters. Almost nobody agrees on what belongs in it. So records grow. A field gets added for a campaign that ran once. A column appears because someone asked "can we capture that?" and the answer was yes. Two years later you have forty fields, and your team reads about six of them.

This article is about the other thirty-four. Which fields earn their place, and which ones you carry forever without ever reading again.

Start with what a record is for. It exists so the next person who talks to this customer can carry on from where the last one stopped, without asking them to repeat themselves. That is the whole job. If you want the longer version of that argument, what a CRM is actually for and what one customer record actually means both make it. Everything below follows from it: a field belongs in the record only if it helps the next conversation go better.

The test a field has to pass

A field earns its place when someone acts on it. Not admires it. Acts on it. Ask three questions of any field you are thinking of keeping:

• Who reads this, and when? If you cannot name the moment someone opens the record and looks at this specific field, it has no reader.
• What decision changes because of it? A field should tip a choice one way or another. What to say next. Whether to call or email. Whether this deal is worth another hour.
• What breaks if it is wrong or blank? If the answer is nothing, the field is carrying no weight.

A field with no reader, no decision, and no consequence is decoration. It looks like information. It behaves like clutter, because every field on the screen is a field the eye has to skip past to reach the ones that matter.

Regulators arrived at a version of the same test from a different direction. Under UK and EU data protection law, the personal data you hold must be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed" [1]. That is a legal duty, but it is also plain operational advice. Collect what the work needs. Stop there.

The fields that earn their place

Most of a useful record falls into three groups.

Who they are, and how to reach them

A name. One reliable way to contact them, and a note of which channel they actually answer on. A company or household if it is relevant to how you sell. That is nearly the whole of identity. You do not need three phone numbers if two of them have never been dialled. You need the one that works.

Where they are in the relationship

This is the part teams most often leave out and most often need. A status or stage. An owner — the person responsible for the next move. A next step, and the date it is due. These few fields are what turn a pile of contacts into a working pipeline, and they are the difference between follow-up happening and follow-up being forgotten.

What has already happened

The history. The thread of calls, emails, notes, quotes and invoices, in one place and in order. This is the field that saves the customer from being asked the same question twice. It is also where quotes and invoices belong — next to the conversation that produced them, not in a separate system, for reasons laid out in why quotes and invoices belong next to the conversation.

Notice what these three groups have in common. Each one is read at a specific moment, by a specific person, to make a specific decision. That is what earning a place looks like.

The fields nobody reads again

Now the other pile. These are the fields that get added with good intentions and then quietly decay.

• Free-text fields with no owner. A box labelled "notes" that everyone writes into and nobody curates becomes a wall of text no one reads.
• A source captured once and never maintained. "How did you hear about us" is useful in aggregate on the day it is collected. As a per-record field it is usually stale within a month.
• Duplicated identity fields. The same email in three places because three imports each added their own column. Now you do not know which one is current.
• Scores nobody defined. A "lead score" or "health" number that no one can explain is worse than no number, because people trust it anyway.
• Fields copied from another export "just in case." Data carried over from an old system because deleting it felt risky. It is read by no one and trusted by no one.

The reason these survive is that storage is almost free, so nothing forces a decision. But storage was never the cost. The cost is attention, and the cost is upkeep. The law makes the same point about time: personal data should be "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed" [3]. A field you no longer act on is a field you are keeping past its purpose.

A field's real cost is keeping it true

Here is the part that changes how you think about adding fields. Every field you keep is a field someone has to keep correct. A record with six accurate fields is worth more than a record with forty, half of them out of date, because a wrong field is not neutral. It sends the next person in the wrong direction with confidence.

Data protection law states the obligation directly: "every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay" [2]. Read that as a maintenance budget. Every field is a small standing commitment to keep it true. The more fields you carry, the thinner that budget spreads, until nothing is quite trustworthy.

This is why a record is only ever as good as the habits around it, an argument made in full in why your CRM is only as good as your habits. A thin record is easier to keep honest than a fat one. Fewer fields means each one gets more of the limited attention your team actually has.

The quiet fields worth keeping

A short list of fields that rarely get read directly but earn their place anyway:

• When the record was created, and by whom. Cheap to store, and the first thing you want when something looks wrong.
• Consent and contact preferences. Whether this person agreed to be emailed, and how. This one is not optional, and it protects you.
• A change history. Not a field so much as a property of the whole record: who changed what, and when. Most teams never think about it until they need it, which is the case made in the audit trail nobody thinks about.

These pass the test in a slower way. Their reader is your future self, at the moment something has gone wrong and you need to reconstruct what happened.

Design the record for the day you leave

One last check. A good record is one you could pick up and take with you. If a field only makes sense inside one tool, or cannot be exported in a form a human can read, it is trapped, and trapped data is fragile. The habit of being able to pull your customer data out cleanly, on any ordinary day, is worth building early — the reasoning is in the data you should be able to export on any Tuesday.

How this looks in practice

A workspace built around one customer record — identity, relationship state, and full history in a single place — is the model 360REV uses, so a quote, an invoice, and a support reply all attach to the same person rather than scattering across tools. The point is not the software, though. The point is the discipline. Add a field only when you can name its reader, its decision, and what breaks without it. Retire a field the moment none of the three still holds. A record kept thin and kept true will serve the next conversation. A record kept full and kept vaguely will not.