A CRM client record needs 14 fields, grouped into 7 buckets: identifiers, contact, segmentation, value, lifecycle, ownership, audit. Two fields per group. That is the working set. Anything more is configuration debt; anything less can't anchor a report.

This article is the reference. Field-by-field. Type-by-type. Vendor-neutral — the same set holds whether your client book lives in a CRM, a sheet, or a flexible database. The point isn't which tool runs it. The point is which fields earn their square inch on the record.

Most CRMs ship with eighty fields on the Company object. Most spreadsheets grow to eighty columns. Both happen for the same reason: nobody decided what to drop. The 14 fields below are the decision.

What we mean by "field"

A field is a typed slot on a record. The record is the unit your team works on — a client, a contact, a deal. The field is one piece of information about it: a name, a value, a date, a status. The collection of fields, viewed across many records at once, becomes a table or a view. Group those records by stage, and the same data becomes a pipeline.

Fields aren't free. Each one is a question your team has to answer when they create or update a record. Five fields cost five seconds; fifty fields cost a minute and a half — every time. A record with fifty fields and 70% completion is worse than a record with fourteen fields and 95% completion. The first can't be filtered; the second can.

The 14-field set below is the floor — the minimum every record should carry — not the ceiling. Industry-specific fields exist (a real-estate CRM will track a property identifier, an agency CRM will track a retainer model). When you add one, name its group first. If it doesn't fit a group, ask whether it belongs on a different object.

The seven groups of a working client record

Every workable client record covers seven groups. Two fields each. The groups are vendor-neutral — they apply whether you run a CRM, a flexible database, or a spreadsheet that hasn't broken yet.

Identifiers — what makes this record unique and dedup-able.
Contact — how the team reaches the account, and through whom.
Segmentation — what bucket the account belongs to, for filtering and reporting.
Value — the financial weight of the account, in numbers your reports can sum.
Lifecycle — where the account stands today, and when you last touched it.
Ownership — who is responsible internally, and how the account got here.
Audit — when the record was created, and who changed it last.

If a field doesn't sit in one of these groups, treat it as a flag: it might belong on a related record (a deal, a person, an interaction), or it might be a habit nobody questioned. Audit it.

The 14 fields, group by group

1. Identifiers (2 fields)

Account name

Type: text, unique, required.
Why it matters: the human handle for the account. Every other field hangs off it.
Rule of thumb: one canonical spelling. Pick "Acme Corp" or "Acme Corporation," not both. Inconsistent names are the leading cause of duplicate records.

External ID (tax ID, VAT, EIN)

Type: text, unique.
Why it matters: the only field guaranteed to be globally unique and stable. The legal identifier (CIF, NIF, VAT, EIN, depending on jurisdiction) lets you dedup on import, reconcile against accounting, and survive a renamed company.
Rule of thumb: capture the tax ID for any account you'll invoice. For prospects you may never invoice, leave it blank — it's optional, but the slot stays.

2. Contact (2 fields)

Primary contact

Type: relation to a Person record.
Why it matters: the one human you talk to. Storing it as a relation (not a free-text name) means a report can pivot from accounts to the people behind them — and a person's email change updates everywhere automatically.
Rule of thumb: one primary, even if you talk to five people. The primary is the one you'd call first if the deal stalls.

Website

Type: URL.
Why it matters: a single canonical pointer at the account's public surface. Useful for enrichment, for catching duplicates, and for a one-click open from inside the record.
Rule of thumb: the root domain (acme.com), not a deep link.

3. Segmentation (2 fields)

Industry

Type: single-select.
Why it matters: stored as text, "Industry" gives you 200 unique strings; stored as a single-select, it gives you a chart. Same field, different type, different decision surface.
Rule of thumb: start with 8–12 industry buckets that match your book of business. Add an "Other" option. Audit the list every six months — if "Other" is the largest bucket, your buckets are wrong.

Size band

Type: single-select.
Why it matters: headcount as a free-text number is noise. As a band — 1–10, 11–50, 51–200, 200+ — it's a filter, a chart axis, and a pricing-tier proxy.
Rule of thumb: four bands is enough. More than seven and the chart loses its shape.

4. Value (2 fields)

Account value

Type: currency.
Why it matters: a numeric field with a currency type gives you a sum, an average, and a column footer at the bottom of the table. A text-typed amount gives you nothing — not even a sort that respects orders of magnitude.
Rule of thumb: annualized expected value, not lifetime. Lifetime drifts; annualized stays comparable across accounts.

Open pipeline

Type: currency, computed via relation rollup from open deals.
Why it matters: account value tells you the floor; open pipeline tells you what's in motion right now. Together they answer the question every weekly review asks: which accounts deserve a touch this week?
Rule of thumb: if the rollup isn't supported, store it as a manual currency field and update it on the cadence your forecast already runs on. Don't make it a guess.

5. Lifecycle (2 fields)

Status

Type: single-select.
Why it matters: the answer to "where does this account stand?" — a CRM-wide question that has to be one click away. A four-option select (Lead, Active, Paused, Churned) covers ~95% of SMB books.
Rule of thumb: keep the option set short. Each new option you add doubles the explanation cost for every new hire.

Last touch

Type: date.
Why it matters: every retention conversation starts with "when did we last talk to them?" If the field is missing or stale, the answer is a guess. With the field, the answer is a sort.
Rule of thumb: updated on meaningful interaction (a call, a real email, an in-person), not on every notification. Auto-fill if your tool supports it; otherwise enforce it as part of the weekly account review.

6. Ownership (2 fields)

Account owner

Type: user reference.
Why it matters: every record needs a name attached. "The team owns it" means nobody owns it. The owner field powers personal queues, escalation rules, and the basic "what's mine?" view that keeps reps honest.
Rule of thumb: one owner per account. If two people genuinely co-own, the field still picks one and the other is on the deal record or as a watcher.

Source

Type: single-select.
Why it matters: how the account entered the book. Referral, Inbound, Outbound, Event, Partner — five options is plenty. The reason this lives at the account level (not the deal level) is that account-level source survives across many deals and tells you which channels actually grow your book over a year.
Rule of thumb: capture it once, at creation. Backfilling source six months later is folklore, not data.

7. Audit (2 fields)

Created date

Type: date, auto-populated.
Why it matters: cohort analysis, win-rate-by-vintage, list hygiene — none of it works without a creation date. Most CRMs and most flexible databases set this for free; the discipline is to never overwrite it on imports.
Rule of thumb: auto-only. If a human can edit it, the field is no longer a fact.

Last modified by

Type: user reference, auto-populated.
Why it matters: the cheapest accountability signal you have. When a record changes and a report breaks, "who touched it last" closes the loop in seconds.
Rule of thumb: pair it with a last modified at timestamp if your tool exposes both. They're the audit trail's smallest viable form.

Looking for the printable version? A one-page reference card with all 14 fields, the type, and the rule of thumb is available as a free PDF — built to print, tape next to the monitor, and hand to the new hire on day one. Link at the bottom of this article.

Pick the type before you pick the name

A field's type decides what reports it can produce. Same name, different type, different decision surface:

"Industry" as text is a column. As a single-select, it's a chart axis and a filter.
"Account value" as text is a string. As currency, it's a sum at the bottom of the column, an average, and a sort that respects magnitude.
"Last touch" as text is "last week." As a date, it's a sort, a "stale > 30 days" filter, and a leading indicator.
"Account owner" as text is "Maria." As a user reference, it's a personal queue, a permission boundary, and a working set.

The cost of typing a field correctly at creation is one click. The cost of retyping a column of 800 records six months later is most of an afternoon — and the loss of every historical record where the conversion is ambiguous. Type first, name second.

Common mistakes when designing CRM fields

Five patterns we see in audits of SMB client books:

Free-text where a select belongs. Industry as text, status as text, source as text. The data exists, but it can't be filtered, charted, or counted. The fix is mechanical: convert to a single-select and migrate the existing values into the closest option.
The field that's always blank. Most records have it empty; a few have a stray value from someone's old workflow. If the field is blank on 70%+ of records, it can't anchor a report. Drop it.
Ten variations of the same thing. "Notes," "Last note," "Comments," "Remarks." Pick one, archive the rest. Each duplicate splits the team's attention and degrades the master record.
Per-deal data on the account. Deal value, deal stage, expected close date — these belong on a deal record, not on the account. Storing them on the account means you can only ever track one deal per client. Most agencies have multiples.
Eighty columns, one record. The clearest sign that field design has slipped. The record has become a museum of historical decisions. The 14-field set is the cure: drop, group, retype, ship.

The line we use in audits: a record is a tool, not a museum. Fourteen fields, used every week, beat eighty columns nobody fills in.

How to ship the set: 14, then a month, then maybe 15

Field design is a half-hour decision, not a quarter-long project. The sequence:

Define the 14. Use the set above as the starting template. Adjust the segmentation buckets and the lifecycle options to match your book; leave the structure intact.
Migrate the existing book. Export your current sheet or CRM. Map the columns onto the 14 fields. Anything that doesn't map gets archived in a separate file — not deleted, just out of the way.
Run the set for a month. No new fields. No "let's also track…" If a question can't be answered, write it down.
Add the fifteenth field only when you reach for it twice. A single moment of "I wish I had this" is folklore. Two moments is a signal. The discipline of waiting for the second moment is what keeps the record at fourteen instead of eighty.

The reverse — designing for every imaginable case before you start — is how a sheet ends up at eighty columns and zero confidence. Configuration is a basic right, not an achievement. Ship the floor, run it, raise it on evidence.

Get the printable version

We've prepared a printable reference card to keep on hand while you build or audit your CRM. One page, ready to print.

Download the 14-field PDF reference

What fields should a CRM have? 14 essentials for SMBs