Introduction

A cleaning company owner who hired two people and took a lease against a $340k weighted pipeline containing deals that had died in March, because two salespeople updated before meetings and one had stopped in February; and an architecture firm's deduplication that stopped for three weeks when two salespeople turned out to have both been working the same client for two years, making the owner field a commission decision.

The forecast somebody hired against

A commercial cleaning company had five salespeople, a CRM Dilan had implemented eight months earlier, and a dashboard on the wall of the owner's office.

In April the dashboard said the weighted pipeline was three hundred and forty thousand dollars. The owner had been watching it climb since January, and in May he hired two additional operations staff and took on a lease for a second van, because the work was clearly coming.

By August it had not come. Not most of it.

The CRM was not broken. Nothing had failed. Everybody had been trained, twice, and everybody said the system was fine.

What had actually happened was this. Two of the five salespeople updated their records properly. Two updated them on the morning of the monthly meeting, moving things forward so their pipeline looked reasonable and closing nothing, because closing something as lost is an admission. And one had stopped entirely in February, so his section of the pipeline was a photograph of February with dates that had quietly become historical. The three hundred and forty thousand contained deals that had died in March and were still sitting at sixty percent, and deals with two different salespeople's names on them because nobody had ever decided who owned that account.

The owner had made a hiring decision from a number that was confidently wrong.

Here is the thing that matters. If that pipeline had been a spreadsheet, he would not have hired anybody. A spreadsheet that is sixty percent updated looks sixty percent updated — there are blank cells, there are stale dates, and everybody who reads it discounts it accordingly. A CRM that is sixty percent updated produces a clean number in a coloured box, and nobody discounts a clean number in a coloured box.

A half-used CRM is not less useful than a spreadsheet. It is worse than one, because it converts incomplete information into confident information, and somebody acts on it.

The merge that was really about commission

The second story is quieter and it is where a great many implementations quietly stall.

An architecture firm had three sources of contacts: an old system, a shared spreadsheet, and two salespeople's own lists which they had been maintaining privately for years. Dilan's job was to import all of it, deduplicate, and assign owners.

Two hundred and forty duplicates in, they hit a record that appeared in both salespeople's private lists. Then another. Then eleven more. Both people had been working the same client for two years, each believing the relationship was theirs, each with different notes about the same conversations, and neither aware of the other.

Merging those records was not a data task. It meant deciding whose notes were the record of truth, whose name went in the owner field, and — because the firm paid commission on the accounts you owned — who got paid on the next project.

Dilan stopped and handed it back. It took three weeks to resolve, it delayed the go-live, and the client was not pleased about either. It was also the only correct thing to do, because the alternative was for a contractor with no authority to make a commission decision by choosing a value in a dropdown.

Deduplication is a business decision wearing technical clothes, and merging is frequently irreversible.

What this book is about

This is a manual for configuring CRM systems — sales pipelines, service workflows and follow-up — for small organisations, alongside a job.

It covers requirements gathering, pipelines, custom fields, imports, deduplication, permissions, automations, dashboards, training and adoption. But the reason those two stories open it is that configuration skill is not what decides whether this works as a business. Four structural facts do, and most CRM advice mentions none of them.

The four rules

Rule one — you are encoding a sales process that does not exist yet.

A pipeline demands named stages with criteria for moving between them. Most small businesses do not have that. They have habits, three people who each do it differently, and a founder who knows which enquiries are worth chasing but cannot say how. Setting up a CRM forces the business to decide how it sells, frequently for the first time — and that decision belongs to them, takes weeks they had not budgeted, and produces arguments. If you decide it for them to keep the project moving, you have taken on a job you cannot be paid enough for.

Rule two — the data you inherit is wrong, and merging it is a business decision.

Every implementation starts with an import: a spreadsheet, an old system, an inbox, somebody's private list. It contains duplicates, dead records, people who left in 2021, and the same company spelled four ways. Deduplicating means deciding whose version of the truth wins and who owns the relationship — and in most systems, a merge cannot be undone.

Rule three — the CRM makes things visible, and visibility is political.

It shows whose pipeline is thin, who has not contacted anybody in three weeks, and which relationships belong to whom. That is a management tool, and the people using it know it. Resistance is rarely about the interface. It is about exposure, territory and commission — and you will be handed decisions that are really about trust, dressed up as configuration questions.

Rule four — a half-used CRM is worse than a spreadsheet.

Partial adoption does not reduce the value proportionally. It inverts it, because the output is a confident number nobody discounts. And the users are salespeople, who are measured on outcomes rather than on data entry, and who have a rational reason to prefer the version of reality in their own head.

And the interaction is the whole risk. Rule one means the process is undecided. Rule three means people have reasons not to record it accurately. Rule four means the result is not merely incomplete but actively misleading. And rule two means the foundation was wrong before anybody typed anything. That is why process work and adoption work, rather than configuration skill, are what make this business.

The numbers this book is built on

The economic unit is revenue per system under support — what an implementation returns across a year of changes, new joiners, pipeline adjustments, report requests and hygiene work.

The leading indicator is hours per system-month, tracked as a curve. It should fall after the first months and flatten. A system whose hours never fall has a findable cause, and it is usually that the process was never actually decided.

The master variable is pipeline hygiene — the share of open opportunities with a current stage, an owner, and a next action dated in the future. It is not a soft measure. It decides whether every report in the system is true, whether the client trusts what they see, whether the renewal happens, and whether anybody in the business defends the CRM when somebody proposes replacing it. It is rule four expressed as a number.

And the risk indicator is the count of supported systems where somebody is making decisions from a dashboard while hygiene sits below the agreed threshold. Target zero. That is the cleaning company in April: nothing was broken, nothing alerted anybody, and a hiring decision was made from a number that had stopped being true in February.

How to use this book

Read Part One in order. Chapters 5 to 8 are the four rules in full, and everything afterwards depends on them.

Everything else can be read as needed. Part Two sets the business up. Part Three is the work itself — pipelines, fields, imports, permissions, automations, dashboards, training and adoption. Part Four is the money and the records. Part Five is the year, the procedures, the numbers and the plans.

There are sixty-eight resources at the back and one hundred and forty-eight AI prompts, four per chapter. The ⚠ symbol marks a risk, a load-bearing constraint, or a clause in a prompt you should not delete when you adapt it.

Two things to do before anything else. Read your own employment contract, including any IP and conflict clauses. And take Chapter 15 and Resource 18 to somebody qualified where you are — liability, customer personal data in a system you configured, marketing consent, and the employment questions that arise when a system monitors people's activity — before you accept a client rather than during your first year.

And one thing to establish on every engagement, before you configure anything: who inside the business is going to insist this is used, and what happens when somebody does not. Without a named answer, you are building the cleaning company's dashboard.

©2026 James Henderson / https://localhandyman.work

Chapter 1 — What CRM Setup and Customization Actually Is

The system is easy and the agreement is hard — almost nobody can get five salespeople to agree what "qualified" means.

1.1 The job is not configuring the CRM

Configuring is perhaps a fifth of it, and it is the fifth people picture.

The rest is finding out how the business actually wins work, getting them to decide a process they have never had to write down, auditing data nobody has looked at properly in years, making decisions about ownership that are really about money, and then persuading people who are measured on revenue to type things into a box.

The distinguishing feature of this trade is that the system is easy and the agreement is hard. Any competent person can build a pipeline in an afternoon. Almost nobody can get five salespeople to agree what "qualified" means.

⚠ If you are good at platforms and uncomfortable with disagreement, this business will not work. The failures are almost never technical. Chapter 5.6.

1.2 What you are actually selling

Not a configured system.

You are selling a process the business has agreed, recorded in a system, that the people who sell actually use — with numbers somebody can trust. Four things: that the process is decided, that the system reflects it, that it is maintained, and that the reports are true.

Clients buy the second. They assume the first already exists. They have not thought about the third. And they only discover the fourth matters when a report turns out to be wrong. Chapter 8.2.

⚠ Sell the four, priced separately, from the first conversation. A system sold as a configuration job produces the cleaning company's dashboard. Chapter 4.1.

1.3 Why "set up our CRM" is the wrong unit

The phrase hides an enormous amount.

"Set up our CRM" can mean one pipeline, five fields, three users and a clean import — which is a fortnight of evenings. It can mean the same thing with two sales teams who work overlapping accounts, four years of contacts across three sources, a commission scheme nobody wants to discuss, service workflows as well as sales, and an owner who wants to see everything — which is four months, most of it not configuration.

The unit that predicts effort is not the CRM. It is the number of people who must change how they work, whether a process exists to encode, how bad the data is, and how many boundaries there are between who may see what. Chapter 11.3.

⚠ When somebody says "we just need it set up", the word doing the work is "just", and it means they have pictured the software rather than the agreement. Chapter 4.2.

1.4 The four rules, in brief

Rule one — you are encoding a sales process that does not exist yet. A pipeline demands named stages with exit criteria, and most small businesses have habits rather than a process. Chapter 5.

Rule two — the data you inherit is wrong, and merging it is a business decision. Deduplication means deciding whose truth wins and who owns the relationship, and it is usually irreversible. Chapter 6.

Rule three — the CRM makes things visible, and visibility is political. Resistance is about exposure, territory and commission rather than about the interface. Chapter 7.

Rule four — a half-used CRM is worse than a spreadsheet. Partial use inverts the value, because the output is a confident number nobody discounts. Chapter 8.

And the interaction is the risk. One leaves the process undecided, three gives people reasons not to record accurately, four turns the result into something misleading, and two means the foundation was wrong to begin with.

1.5 What makes this different from other systems work

Worth stating plainly, because the assumptions from adjacent trades do not transfer.

From internal tools work. There, the failure is abandonment and the tool becomes unused. Here, partial use is the failure, and it is worse than abandonment because it produces output. Chapter 8.1.

From software configuration generally. The hard part is not the system's limits; it is that the requirements do not exist until somebody in the client's business decides them, and deciding costs them arguments.

And from any trade where users want the tool. Salespeople do not want a CRM. They may accept one. The gap between those two is where this work lives. Chapter 8.6.

⚠ The skill that matters most is running a disagreement to a decision without owning the decision, which is a conversational skill rather than a technical one. Chapter 5.8.

1.6 Who is realistically good at this

Not the fastest configurer.

Somebody who can sit in a room while two people disagree about what "qualified" means and not resolve it for them to end the discomfort. Chapter 5.6.

Somebody who asks how the last five deals were actually won rather than how the sales process works.

Somebody who will tell an owner that two of their five people have not updated anything in five weeks, factually, without softening it.

And somebody who writes decisions down, because in eight months nobody will remember why the third stage exists.

⚠ Temperamentally, the trait that matters most is tolerance for being in the middle of somebody else's internal politics without taking a side or taking it personally. Chapter 7.6.

1.7 What it costs you in a normal week

Implementation blocks. Evenings and weekend mornings, where the configuration and the documents happen.

Change windows. Small, frequent and interrupting — a new joiner, a field, a report somebody needs before Thursday. Chapter 33.2.

And obligation load — the standing awareness of every supported system: whether hygiene is holding, whether an automation is still running, whether anybody has left. Chapter 33.1.

⚠ Adoption work does not fit in any of the three neatly, because it happens during the client's working day and you have a job. Say so before the engagement rather than during it. Chapter 26.4.

1.8 The skill that actually decides your margin

Not platform fluency.

It is getting the process decided before you configure anything, because a system built on an undecided process is rebuilt — and rebuilding a pipeline after people have used it means migrating live deals, retraining, and explaining. Chapter 20.9.

And that compounds into hygiene, which is this book's master variable, because a pipeline people disagree with is a pipeline they do not maintain. Chapter 35.4.

⚠ The economics of this trade are decided in a room, before anything is configured, by whether the client will actually make the decisions. Chapter 11.6.

1.9 What this book assumes

That you have a job and a few evenings. That you can learn one CRM platform properly rather than five superficially. That you have very little to spend beyond a subscription and a domain.

That you have not yet had somebody make a decision from a report you built, which is where everything changes.

And that nothing here names a platform, a vendor, a plan, a price or a feature — because all of them change, and a specific quoted from memory is exactly the failure this trade punishes.

1.10 Chapter summary

Configuring is a fifth of it; the rest is process, data, ownership and persuasion. The system is easy and the agreement is hard — almost nobody can get five salespeople to agree what "qualified" means. You are selling a decided process, recorded, maintained, with numbers somebody can trust, and clients buy only the recording. "Set up our CRM" ranges from a fortnight to four months, and the predictors are people who must change, whether a process exists, data quality and permission boundaries. It differs from other systems work because partial use is worse than abandonment and because the users do not want the tool. The people who do well can sit in a disagreement without resolving it for others. And margin is decided in a room, before anything is configured.

AI prompts for this chapter

Prompt 1 — Separating the four things being bought

Here is a client enquiry about setting up a CRM: [PASTE]. Separate what they are asking for into four things — a sales process the business has agreed, a system that reflects it, people actually maintaining it, and reports somebody can trust. ⚠ Do not estimate hours or cost. ⚠ Do not name any CRM, vendor or feature. ⚠ Identify which of the four the enquiry assumes already exists, and turn each assumption into a question for me to ask.

Prompt 2 — Unpacking "just set it up"

Here is how a client described what they want: [PASTE]. List every ambiguity that could change the effort by more than double — number of people who must change how they work, whether a documented sales process exists, how many data sources will be imported, whether accounts are shared between salespeople, whether commission depends on ownership, and how many permission boundaries are needed. ⚠ Do not resolve any ambiguity by assuming the common case. ⚠ Do not produce a configuration plan. ⚠ Output questions only, ordered by how much the answer changes the work.

Prompt 3 — Self-assessment against the four rules

Here is my background and available time: [PASTE]. Ask me the questions that would establish whether I am suited to a trade where the process I am asked to encode does not exist yet, the inherited data is wrong in ways that require the client's decisions, the system exposes people's performance and relationships, and partial use produces confidently wrong numbers. ⚠ Do not reassure me. ⚠ Do not treat platform fluency as the main variable. ⚠ Include tolerance for sitting inside somebody else's internal politics as an explicit question.

Prompt 4 — Counting my three kinds of time

Here is my week: [PASTE]. Separate it into implementation blocks, change windows for supported systems, and background obligation load. ⚠ Treat adoption work as requiring the client's working hours rather than my evenings, and flag that as a constraint to state before an engagement. ⚠ Count obligation load as consumed capacity even in quiet weeks. ⚠ State how many supported systems this week could realistically carry.

⚠ AI checkpoint for this chapter

One — did it name a CRM, vendor, plan or feature? All of those change, and a stale specific is what this trade punishes. Chapter 37.4.

Two — did it estimate effort from a description? The predictors are people who must change, whether a process exists, data quality and permission boundaries — none of which appear in a first email.

Three — did it treat platform fluency as the main variable? The system is easy; getting five people to agree what "qualified" means is not.

Four — did it schedule adoption work into my evenings? It happens during the client's working day, which is a constraint to state before the engagement.

Do This Now

1. Write down, in one sentence, what you are selling — and check it includes the process being decided and the reports being true.

2. Count your three kinds of time separately, and note where adoption work actually fits.

3. Read your employment contract, including the IP and conflict clauses, this week.

4. Decide now that you will not configure a pipeline the client has not agreed.

5. Complete Resource 1, the ten-question self-assessment, and Resource 3, the four-rules reference.

©2026 James Henderson / https://localhandyman.work