CRM best practices that survive a real team

Why CRMs decay, in order of frequency

We get called into systems that are already installed more often than into greenfield projects, and the complaints repeat. Ranked by how often we hear them:

1. The pipeline is not believed, so the forecast is rebuilt in a spreadsheet every Monday.
2. Records sit with no owner and no next date, so nothing is chased and nobody is accountable for that.
3. Two people entered the same customer twice under slightly different names, and now both records have half the history.
4. Fields were made required at launch and are now filled with a full stop, which is worse than empty because it looks like data.
5. Stages mean different things to different people, so conversion rates measure vocabulary rather than performance.
6. The one person who understood the configuration left.

Notice that none of those are product defects. Every one is a practice that was never decided, or was decided once and never enforced. That is good news, because practices are cheaper to fix than software.

One owner, one next date, no exceptions

This is the single rule that does the most work. Every live record has a named owner and a dated next action. Not a team, not a queue, not the sales inbox. A person, and a date.

The reason it matters more than it sounds: a record without a next date is invisible. It does not appear on anybody's list, it does not trigger anything, and it will be found six weeks later when someone searches for something else. Most lost revenue in small businesses is not lost to competitors, it is lost to silence.

Two supporting rules make it stick. First, assignment happens by rule, not by goodwill, so every enquiry has an owner within seconds of arriving, before any human sees it. Second, the system has one report that exists purely to embarrass the rule: records with no next action, or with a next action in the past. Read it weekly, in a meeting, out loud. That report is the cheapest management tool in the building.

When we build a system, that report ships in the first release and appears on the home screen. It is deliberately impossible to avoid.

Define stages by their exit criteria, not their names

Pipeline stages are where most reporting goes wrong, because they are usually named after a feeling. Interested, warm, hot, nurturing. None of those can be verified, so different people move records at different moments and the numbers mean nothing.

Fix it by writing an exit criterion for each stage: the observable event that must have happened for a record to leave it. Not what the salesperson believes, what is on record.

Two consequences follow. Conversion rates become comparable between people, because the same event moves every record. And the stage becomes automatable: if leaving quoted requires a written response, the system can chase for that response by itself.

Keep the count low. Five to seven stages is right for almost everyone. Every extra stage divides your data into smaller pieces and makes the funnel report noisier rather than more precise.

Naming conventions for deals, accounts and jobs

Unglamorous, and it pays back every day. A record's name is the thing people read in lists, search boxes, notifications and reports, and inconsistent names make search useless, which makes duplicates inevitable.

The convention we use unless a client has a better one, and the reasoning behind each part:

• Accounts: the legal or trading name only, with no suffixes such as Ltd or Inc unless two records genuinely need separating. No branch, no region, no salesperson initials. Those are fields, not name parts.
• Deals: account, then what is being bought, then the period. For example Harbour Plumbing, boiler replacement, Q1. Readable in a notification without opening anything.
• Jobs: site address, then work type, then date. The address first, because field teams search by address and never by customer.
• Matters and cases: client, then matter type, then your internal reference. The reference last, because humans scan from the left and nobody recognises a number.
• Documents: record name, document type, version date. Never final, never final version two.

Three rules underneath the convention. Put the thing people search for first. Never encode information in a name that belongs in a field, because names cannot be filtered or reported on. And enforce it with a default value that the system generates, rather than with a note in a handbook nobody reads, which is the only enforcement that has ever worked.

In systems we build, record names are generated from fields on creation and editable afterwards. Consistency by default, escape hatch when reality disagrees.

Fewer required fields than feels comfortable

Every required field is a toll charged on every record, forever, usually to a person holding a phone in one hand. Make ten fields required and you have not improved your data, you have taught your team to type a full stop ten times.

The test for a required field is not is this useful. It is: will we filter, report or automate on this, and would we rather have no record at all than a record missing it? Almost nothing passes. Name, one contact method, owner and source usually pass. Almost everything else should be optional at creation and required later, at the stage where it actually matters.

Stage gated requirements are the compromise that works: a quote cannot be marked sent without a value, a job cannot be completed without a photo, a matter cannot be opened without a conflict check. The requirement lands at the moment the person has the information, which is why they comply instead of inventing.

Data quality is not a training problem. It is a design problem wearing a training costume.

The same logic applies to picklists. Twelve options that nobody can distinguish produce worse reporting than four that everyone can. If two options are chosen at similar rates by different people for the same situation, they are one option.

Permissions: design them once, from roles

Permissions get set up in a hurry at launch and then become impossible to reason about, because they grow by exception. The fix is to define them from roles and a short list of sensitivities before anyone is invited in.

Start by naming the things that are genuinely sensitive in your business rather than guessing at a hierarchy. Typically: costs and margin, salaries and rates, medical or case notes, client financial details, and anything a regulator can ask about. Everything else is usually fine to make visible to the whole team, and visibility is what makes a CRM collaborative rather than a set of private lists.

Four rules that prevent the usual mess. Permissions attach to roles, never to individuals, so a leaver is removed by taking away a role. There are always at least two administrators, because one is a single point of failure the day they are on a plane. Export and delete are separate permissions from edit, and both are logged. And access to sensitive fields is logged with who looked at what, because that is the first question asked after any incident.

Review it twice a year against the actual staff list. Every permission audit we have run has found at least one account belonging to someone who left, and usually a contractor from a project that finished.

Data hygiene and the limits of enrichment

Two related practices, one of which is oversold.

Deduplication has to be preventive. Cleaning duplicates quarterly is treating a symptom. Check for a match at the moment of creation, on email first and phone second, and show the person the possible match before they can save. Merging afterwards is lossy: notes get orphaned, attachments get stranded, and the merge itself is rarely reversible. When a merge does happen, keep both original identifiers on the surviving record so history stays traceable.

Enrichment is useful at the edges and dangerous in the middle. Filling in company size, industry code or a registered address from a public source saves typing and is generally safe, because the source is authoritative and the field is factual. Appending guessed contact details, inferred seniority or predicted intent from a data broker is a different activity: the accuracy is unverifiable, it decays fast, and in several of our markets it creates a lawful basis problem you will have to answer for.

The practical rule we apply: enrich facts from sources you could show a customer, never enrich anything a salesperson will read as truth without checking, and always store where a value came from and when. A field with no provenance is an opinion that has been promoted to data.

The hygiene routine worth running monthly takes twenty minutes. Records with no activity for ninety days, records with no owner, contacts with bounced email, and accounts with no contact at all. Four queries, fixed in one sitting, and they stop the slow rot that makes a system untrustworthy after two years.

Training that does not depend on a launch day

A one day training session at go live is the standard approach and it teaches roughly nothing, because people cannot learn a workflow they have not yet needed.

What works, in the order we do it:

1. Put real data in before anybody is trained. A system full of sample records teaches people that it is a toy. Migrate first, train second.
2. Teach one path, not the system. Twenty minutes on the exact sequence that person does twelve times a day. Nothing else. They will find the rest.
3. Train in their own record. Not a demo account. The first thing they do in the session is a real piece of work that would otherwise have been done elsewhere.
4. Nominate one person per team as the local expert and train them for an hour longer. Questions go to a colleague at the next desk, which is the only support channel with a one minute response time.
5. Come back at week three. That is when real questions appear, once habits have formed and the edge cases have been hit. A second session then is worth three at launch.

Two things to avoid. Do not run the old system in parallel for more than a fortnight, because parallel running is how a team decides which one to keep and they will keep the familiar one. And do not write a manual: record two minute screen captures per task instead, because nobody reads a manual and everybody watches a clip. This is the approach behind our CRM implementation work, and the reason we insist on migrating data before training rather than after.

CRM training tips that actually stick

Most CRM best practices articles end with train your team. Training is where adoption is won or lost, so here are the specific CRM training tips we use on every rollout, in the UK spelling some clients prefer: CRM best practises.

1. Train on the team's own records, imported before the session, never on sample data.
2. Teach one job per session, such as logging a call or moving a deal, not the whole system.
3. Give each person a one page sheet with their five daily actions and nothing else.
4. Hold a fifteen minute check in after the first week, when the real questions appear.
5. Name an internal champion who answers questions for the first month.
6. Record short screen videos of each task and link them from the CRM itself.

The measure of training is not attendance. It is whether the records are complete two weeks later, which the monthly review below will show.

Structuring data so the CRM and the finance system agree

The most expensive practice to retrofit, and the cheapest to decide at the start: which system owns each field, and what a customer even is.

Start with the identity question, because everything else follows from it. Is your customer the company, the site, the individual or the household? A trades business usually answers property. A charity answers person, then household. An accountant answers entity, of which one client can have six. Answer it once, write it down, and let both systems use the same answer. Most integration pain we are hired to fix is two systems that disagree about what a customer is.

Then assign a single owner to each shared field. The accounting system owns the legal name, billing address, credit terms, invoices and payments. The CRM owns contacts, pipeline, activity, quotes before acceptance, and service history. Anything with two owners will produce a conflict inside six months, so the rule is one owner and a read only view for the other side.

Finally, keep a stable identifier that never changes and never gets reused, and store the other system's identifier alongside it on every record. It costs nothing at build time and it is the difference between a reconciliation that takes an afternoon and one that takes a fortnight. The same principle governs the ERP boundary, set out in ERP versus CRM, and it is the first document we write on any integration project.

The monthly review that keeps all of it true

Practices decay unless something checks them. One meeting a month, thirty minutes, five numbers, and a named person who owns the system.

• Records with no owner or no next action. Target zero, and it is achievable.
• Records that have not moved a stage in thirty days. Not all of them are dead, but every one needs a decision.
• New duplicates created since last month. If this is above zero, the creation time check is not working.
• Enquiries with no source recorded. This number is your marketing reporting quality, expressed honestly.
• Stage conversion rates compared to three months ago. A sudden change is usually a definition drifting, not performance improving.

None of this needs a consultant and none of it needs new software. It needs somebody whose job includes the health of the system, thirty minutes a month, and the willingness to say a number out loud in front of the people who produce it. Businesses that do this keep their CRM for a decade. Businesses that do not replace it every three years and blame the software each time.

CRM optimization, and a strategy example

CRM optimization is the quarterly version of the monthly review: removing what nobody uses and tightening what everybody does. Look at fields that are empty on most records, reports nobody opened, automations that never fire and stages where deals sit for months. Each of those is either a training problem or a design problem, and the answer is usually to delete it.

A CRM strategy example makes this concrete. A twenty person services firm sets one goal for the year: grow repeat revenue from existing clients by a fifth. The strategy follows from that goal. Every client gets an owner and a review date, renewals appear ninety days ahead, and the one report that matters is revenue per client this year against last. Everything else in the CRM supports that report or gets removed.

What a healthy record looks like from above

Every practice in this guide is really one idea seen from different angles: a record should always be in somebody's hands, with a dated reason to touch it next, and it should leave each stage on an event rather than on a hunch.

Read across the diagram and you can audit any system in ten minutes. Pick twenty live records at random and ask four questions of each: does it have an owner, does it have a next date, can you name the event that will move it out of its current stage, and is its source recorded. Score out of eighty.

Anything above sixty and your practices are holding. Below forty, no change of software will help, because the same records will decay in the new system inside a quarter. We run exactly this audit before quoting a replacement, and it is the reason we occasionally tell a client their CRM is fine and their habits are not.