Skip to content
4 min read

CRM features: what you actually need in version one

A feature list for a CRM that ships: the six that earn their place in v1, the five that can wait, and the ones that quietly cost more than they return.

On this page
  1. The six that earn v1
  2. What can wait
  3. What costs more than it returns
  4. The order that works
  5. The takeaway

Most CRM feature lists are written by vendors, which is why they are long. A list written by someone who has to build and maintain one is shorter, because every feature is also a thing that breaks at 11pm.

Here is the split I use: the six that make a CRM genuinely usable, the ones that can wait, and the ones that cost more than they return.

The six that earn v1

1. Contacts with a single identity key. One person, one record, however many times they get in touch. In most markets the phone number is the real identity — normalise it on the way in, because the same buyer will arrive as +91 98765 43210, 098765-43210 and 9876543210 within the same week.

2. A pipeline with enforced transitions. Not a status column anything can write to. Define which stage can follow which, reject the rest, and log every transition:

php
const TRANSITIONS = [
  'new'       => ['contacted', 'lost'],
  'contacted' => ['qualified', 'lost'],
  'qualified' => ['won', 'lost'],
];

A free-text status column becomes fiction within a month — leads jump from "new" to "won" with no call recorded, and every conversion report built on it is wrong. This is the single feature that separates a CRM from a spreadsheet, and I went through the implementation in custom CRM development.

3. Activity history. Every call, message, note and stage change, with who and when. It answers the two questions the system exists for: what happened, and what happens next. It is also what makes handover possible when someone leaves.

4. Automatic lead capture. If leads arrive by someone copying them in, they will arrive late and incomplete. Web forms, ad platforms and marketplaces should write directly — and every one of those paths needs deduplication at capture and a retry-safe write, or the integration manufactures work instead of saving it. That is why idempotent APIs and webhooks matters before the integration count grows.

5. Ownership and assignment. Every record has exactly one person responsible right now. Unassigned leads are how "half of them evaporated by Tuesday" happens. Round-robin is fine to start; the rule matters more than its sophistication.

6. Search that is actually fast. Staff search by phone number mid-call, with the customer waiting. If search takes three seconds, they will keep using their own notes, and your data will rot.

What can wait

  • Reporting dashboards. If transitions are logged, every funnel report can be built later from data you already have. Build the logging in v1; build the charts when someone asks a specific question twice.
  • Email sequences. Valuable, but a separate product-sized problem — deliverability, templates, unsubscribes, bounce handling.
  • Custom fields UI. Let admins add fields later; in v1 a JSON column for domain context covers the long tail without a schema migration per request.
  • Quotes and invoices. Usually belongs with billing, not with sales.
  • Native mobile app. A responsive web interface covers the real need: read a record, log a call, change a stage.

What costs more than it returns

AI lead scoring in v1. Scoring requires outcome data — months of leads that went somewhere, with the reason recorded. On a pipeline that is three weeks old, the model scores noise with confidence, which is worse than no score because people act on it.

Deep org hierarchies. "Manager sees their team, director sees all regions" is a permissions matrix that touches every query in the system. Start with two roles. Add the third when someone is genuinely blocked.

Bidirectional sync with another CRM. Two systems both claiming authority over the same record is a conflict-resolution problem you will be debugging for years. Pick one source of truth and let the other read.

Configurable everything. Each setting is a branch, and branches multiply. Hard-code the process, change the code when the process changes — until you are selling the CRM to others, in which case configurability is the product and should be designed deliberately.

The order that works

  1. Contacts, pipeline, activity log — the core nobody can work without
  2. One lead source, captured automatically and deduplicated
  3. Assignment and search
  4. The second and third lead sources
  5. Reporting, once a real question has been asked twice
  6. Automation, once you can see where humans repeat themselves

Each step is usable on its own. That matters more than the list: a CRM that is useful in week six gets adopted and corrected, while one that is perfect in month six arrives after the team has built their own spreadsheets and stopped caring.

The takeaway

The feature list that ships is short: six things, each boring, each reliable. Everything beyond that should be earned by a question the current system cannot answer.

The failure mode is never a missing feature — it is a pipeline nobody trusts because the data is incomplete. Get the core right, log every transition, and the rest can be added in the order your team actually asks for it.

Frequently asked

What features should a CRM have?

At minimum: contact records, a deal or lead pipeline with explicit stages, an activity log, a way for leads to enter automatically, ownership so every record has a responsible person, and fast search. Everything else — reporting, automation, forecasting, integrations beyond the first — is valuable but depends on those six working first.

What is the difference between a CRM and a contact database?

A contact database stores people. A CRM stores what happened with those people and what should happen next. The pipeline stage and the activity history are what make it a CRM; without them you have an address book with extra columns, which is why teams abandon such systems within months.

Do small businesses need CRM automation?

Less than vendors suggest. Automation multiplies whatever process already exists, so automating a pipeline nobody updates produces automated noise. The sequence that works is: get the pipeline reliably updated, see where humans repeat themselves, then automate those specific steps.

Should a CRM have a mobile app?

A mobile-friendly web interface, yes, almost always — field sales and site visits are updated from a phone or not at all. A native app rarely earns its cost in v1, because it doubles the surface you maintain for an audience that mostly needs to read a record, log a call and change a stage.

Found this useful?Share on XShare on LinkedIn

Related reading