What fields should a CRM actually have?

Fewer than most teams start with. A field earns its place only if it maps to a decision someone makes or a report someone uses. Not because it seemed useful to capture at some point.

An admin approves every new account by hand. Nothing is created until then. We reply by email; no newsletter, no sequence.

app.salescrew.io/inbox
The unified reply inbox with classified threads

The short answer

  • A field only earns its place in the CRM if it maps to a real, recurring decision or report. Fields added because they seemed potentially useful tend to sit unfilled and unused within months.
  • Start with a small, deliberate field set and add only when a specific decision or report needs it. That beats adding fields whenever they occur to someone, and it beats planning an exhaustive list up front for needs that may never arrive.
  • Fill rate (what share of records have a value) plus whether a field appears in any real report or filter is the practical way to check if an existing field is still earning its place.
  • Weigh custom field requests against a real, recurring use case before adding them. Ungoverned field growth is one of the most common and hardest-to-reverse sources of CRM clutter.

Why more fields usually means less usable data

CRMs often accumulate fields the same way. Someone requests a field for a specific, sometimes one-off need. It gets added. It stays indefinitely, whether or not that need recurs. Over months and years, this produces a record view cluttered with dozens of fields, most of them sparsely filled. They make the important fields harder to find and slow down every rep who has to scroll past them.

The discipline that prevents this is asking, before adding any field, what decision or report it supports. A field that answers "what industry is this company in, because we segment outreach by industry" has a clear purpose. A field added because "it might be useful to know someday" rarely gets filled consistently. No one is accountable for keeping it current. It becomes exactly the kind of clutter a later cleanup project has to deal with.

A minimal starting field set for most B2B sales teams

ObjectCore fields
ContactName, email, phone, title, company link, lead source
CompanyName, domain, industry, size, address
DealName, stage, value, probability, close date, owner
ActivityType (call, email, meeting), date, outcome/disposition

A starting point; specific businesses will genuinely need a few fields beyond this, but most teams start with far more than this and use a fraction of it.

What to actually do with an existing, overgrown field list

Pull the fill rate for every custom field. Check which ones appear in any saved view, filter or report currently in use. Fields with low fill rate and no reporting use are strong candidates for archiving, not necessarily deleting outright. Archiving preserves the historical data while removing the field from active record views. For any new field request, ask what decision or report it supports before adding it.

Disclosure: SalesCrew is our product. Its contact, company and deal objects ship with a minimal default field set. Custom fields and AI-prompt fields are available as an addition, on the roadmap, rather than a default expectation that every team fills in dozens of fields from day one. It does not audit your existing field usage automatically. That review is still a manual exercise for the team running it.

A required field with no clear purpose gets filled with junk

Making a field required without a clear reason tends to produce placeholder or inaccurate data entered just to satisfy the requirement. That is worse than an empty field, because it looks complete while being wrong. Only require fields that are genuinely necessary for a decision or workflow.

Questions

Is it better to add fields as they seem useful, or plan them all upfront?
A small, deliberate starting set is safer than either extreme. Adding fields whenever they seem useful piles up unused fields over time. Planning every conceivable field up front over-builds for needs that never arrive. Start minimal and add only when a real decision or report needs a specific field.
How do you know a field is actually being used?
Check fill rate (what share of records have a value in that field) and whether the field appears in any report or filter someone uses regularly. A field with a low fill rate and no reporting use is a strong candidate for removal.
Should custom fields be added by request whenever a team member asks?
Not automatically. Weigh each request against whether it maps to a real, recurring decision or report. Ungoverned field growth is one of the most common sources of CRM clutter over time.