CRM Blueprint

A CRM doesn't organise your business. It records whatever organisation you already have.

Most CRM implementations fail the same way. The tool gets bought, data gets imported, everyone starts using it differently, and within a few months it's an expensive list of names nobody trusts.

This is the structure to decide before anyone enters a record.

Request Your Free Systems Audit · Read the workflow design principles

Decide these five things first

Pipeline · Fields · Tags · Ownership · Naming.

Each one is painful to change later, because changing it means migrating every record created under the old scheme.

1 · Pipeline

A stage is a state the record is in, not a task someone performs.

That single rule prevents most pipeline problems. "Send proposal" is a task. "Proposal sent" is a state. The second can be true or false by looking; the first can't.

Keep it to five to seven stages. More than that and people stop moving records, because the distinctions stop being meaningful.

A workable default:

For each stage, write down three things:

• Entry condition — what makes a record arrive here
• Exit condition — what makes it leave
• Maximum age — how long before it's considered stale

The third one is what stops a pipeline becoming a graveyard. Without it, records sit in "Negotiating" for eight months and your pipeline value is fiction.

Decide what "Lost" means. Specifically: how long without a response before a record moves there. Pick a number. Three weeks, six weeks — the number matters less than having one.

2 · Fields

Default to not creating the field.

Every field is something to fill in, keep accurate, and migrate later. A CRM with forty fields has thirty that are blank or stale, and the blanks make the full ones look unreliable too.

Before creating one, answer: what decision does this change? If nothing, it's a note.

A minimum viable set:

Dropdowns over free text, always. Free text cannot be filtered, counted or automated against. "Facebook", "FB", "facebook ads" and "social" are four sources as far as a report is concerned.

3 · Tags

Tags and fields do different jobs. Use fields for one-of-many attributes. Use tags for many-of-many facts.

A contact has one source. They might carry several tags: attended a webinar, requested an audit, is a past customer, asked about pricing.

Rules that keep tags usable:

• One naming convention, decided up front: lowercase, hyphenated, no spaces
• Prefix by family: src-, interest-, status-, campaign-
• Nobody creates tags ad hoc — one person approves new ones
• Review the list quarterly and merge the near-duplicates

Tag sprawl is the most common cause of a CRM becoming unusable, and it happens gradually enough that nobody notices until there are two hundred tags and four of them mean "interested."

4 · Ownership

Every record has exactly one owner. Not a team, a person.

• What's the rule for assigning a new record?
• What happens when the owner is away?
• What happens when they leave?
• Who sees records they don't own?

Unowned records are the ones that go quiet. A record that belongs to everyone belongs to nobody.

5 · Naming

Decide and write down:

• Companies — legal name or trading name? Pick one.
• People — Firstname Lastname, consistent capitalisation
• Opportunities — a pattern like [Company] — [What] — [Month Year]
• Dates — one format everywhere
• Phone numbers — with or without country code, consistently

These look trivial. They determine whether search works, whether duplicates are detectable, and whether any report you build is accurate.

6 · Deduplication

Decide before import:

• What makes two records the same? Email, then phone, then company plus name.
• What happens on a match? Update the existing record, never create a second.
• Who merges duplicates, and how often?

Most duplicate problems are designed in at import and compound from there.

7 · Required before a stage change

A small number of fields should be mandatory before a record can advance:

Lost reason is the one people skip and the one with the most value. Without it you cannot answer the single most useful question about your sales process: why do people say no?

Implementation sequence

1. Write the blueprint. All seven sections above.
2. Build the structure. Nothing else.
3. Import a sample — fifty records, not everything.
4. Check the sample. Fix what the structure got wrong.
5. Import the rest.
6. Write the procedure for using it. One page.
7. Train whoever uses it on the procedure, not the software.
8. Only then, build automations on top.

Automating before step 5 means rebuilding the automations when the structure changes. It will change.

Keeping it honest

Monthly: records past their stage maximum age, records with no next action date, new tags created.

Quarterly: fields that are mostly empty — delete them. Tags that mean the same thing — merge them. Stages nobody uses — remove them.

A CRM degrades by default. The maintenance is small and the alternative is a rebuild.

A CRM records the organisation you already have. Decide the structure before the first record, or migrate every record later.

Setting up or rescuing a CRM?

A free systems audit covers your structure, your data quality and what needs fixing first.

Request Your Free Systems Audit

More in this category

• SOP Template
• Workflow Template
• Process Mapping Template