A CRM the team fills in,
not a database they endure.

We observe how your salespeople really work, not what the theoretical process describes. We configure the tool around that. We connect it to your website, your mail and your invoicing so the record fills itself in. We train, then we follow adoption through the first weeks.

What you get: A CRM your team actually opens, a database cleaned within the agreed scope, the connections that remove double entry, and four management indicators that mean something.

What you do not have to do: Describe an ideal process, impose data entry on your salespeople, or carry ten years of doubtful data into a new tool.

A CRM almost never fails for technical reasons. It fails behaviourally: if the team has to change the way it works to feed the tool, it will not feed it.

So we start from your real habits and from the data that already exists. We connect the CRM to the rest of your stack, website, invoicing, mailbox, so the record fills itself in as far as possible. What is left to type must be short and visibly useful to whoever types it.

Only then come the dashboards. Management built on incomplete data is worse than no management: it gives false confidence.

The practical consequence is that a CRM project is judged on a single indicator, six months later: the proportion of deals actually followed in the tool. An impeccable configuration with thirty per cent adoption is a failure, whereas a more modest configuration used by everybody changes the way the company is run.

Connecting your tools together is the other half of the subject, and it belongs to process automation. We have set out the platforms that carry it in our comparisons, in particular Make or Zapier and n8n or Make.

Failed CRM projects all look alike. The tool is in place, the licences are paid, and six months later deals are still being followed in a parallel spreadsheet. The causes are known and none of them is technical.

A process was modelled that does not exist

The configuration is often built from the sales process as people would like it to be, with its seven neatly named stages. The real process has three, two of which overlap, and it varies by type of deal. The tool then becomes a constraint that describes reality badly, and the team works around it.

So we start from observation: which stages your salespeople name spontaneously, where decisions are actually taken, and which information is genuinely used to follow up. The target process comes afterwards, and it resembles what exists more closely than people imagine.

Data entry is demanded with no visible return

A salesperson filling in ten fields so that their director has a dashboard will not fill in ten fields for long. Data entry lasts only when whoever does it gets something out of it: a follow-up that goes out on its own, a pre-filled quote, a history they no longer have to dig out of their mailbox.

That is the principle guiding our configuration. Every required field must be justifiable by a use that serves the person filling it in. Those that only serve reporting become optional or disappear.

It started with a dirty database

Carrying over inconsistent data amounts to installing mistrust from day one. Once the team has seen three duplicates and two contacts who left their company two years ago, it stops trusting the tool, and that trust does not come back easily.

Nobody looks after it afterwards

A CRM is a practice as much as a piece of software. Without somebody in house regularly looking at what is happening and correcting the drift, data quality falls month after month. We identify that person during the project, and we train them specifically, because their existence weighs more than the choice of tool.

The question of the right CRM almost always comes first, when it is settled last and quickly, once the real process is known.

Three families, three uses

• A tool centred on the sales pipeline, easy to adopt, suited to teams selling deal by deal. It is the default choice for organisations under twenty people.
• A complete suite linking marketing, sales and service, suited when several teams must share the same customer record. Richer, longer to set up, and quickly underused if the need is not there.
• A tool centred on sending and automating messages, suited when the main issue is email relationships across a large base rather than following complex deals.

The criteria that settle it

The number of people who will actually type into it, which is not the number of employees. The nature of the sales cycle, short and repetitive or long with several contacts. The tools already in place that will have to be linked, particularly invoicing and mail. And the person who will administer it, because a complete suite without an administrator becomes a tool of which a tenth is used.

The logic is the same as for any working tool, and we have set it out on a neighbouring case in our comparison Monday or Notion: functional richness is only an advantage if somebody exploits it.

What must not decide

The feature list, because all feature lists look alike and none says what will actually be used. And the promise of built-in artificial intelligence, which produces little value on an incomplete database. A forecast calculated on badly filled deals is a wrong forecast presented with confidence.

It is regularly half the workload of a CRM project, and almost never half the quote among our competitors. We would rather announce it.

What we always find

• Duplicates, often many, because the same company was entered under three spellings.
• Obsolete contacts, whose address no longer works, at a rate that climbs fast beyond two years.
• Information in fields meant for something else, in particular essential notes written into a free comment box.
• Data spread between the old tool, several spreadsheets and personal mailboxes, the last of which are often the most up to date.

How we go about it

We do not carry everything over. Carrying over an entire old database amounts to importing the mess into a new tool. We define a scope: accounts active over a given period, open deals, and genuinely useful history. The rest is archived, reachable, but outside the working tool.

The cleaning is then done in two passes, one automatic on what a rule can detect, one manual on what needs human judgement. That second pass is done by your teams and not by us, because we do not have the knowledge to decide, and we prepare it so that it takes hours and not weeks.

The point to settle before starting

Who owns a contact, and who has the right to see it. That is a question of organisation, not of configuration, and it produces the most lasting conflicts when it has not been asked. It also has a regulatory dimension, on retention periods and the right to erasure, which we frame at that point rather than afterwards.

An isolated CRM forces double entry, and double entry is what kills adoption. The value of an integration is measured by the number of data entries it removes.

The connections that pay back most

• The website to the CRM: a completed form creates the record and triggers the assignment, with no copying and pasting from a shared mailbox.
• The mail client to the CRM: exchanges attach themselves to the right deal, which removes the most hated and worst-performed task.
• The CRM to invoicing: a deal won triggers the quote or the invoice with the right information, without re-typing.
• The CRM to the calendar: follow-ups exist in the diary of whoever has to make them, not only in a list somebody has to remember to open.

These connections run on the same platforms as our other automation work, and the same rules apply: an automation touching a customer or an invoice must raise an alert a human can see when it fails.

Four figures are enough at the start

The number of deals entered in the month, which says whether the top of the funnel is filling. The conversion rate by stage, which shows where deals die. The average cycle length, which makes forecasting possible. And the amount actually signed, which is the only incontestable figure.

We deliberately ignore the rest at the start. A dashboard of thirty indicators is never consulted; four figures looked at every month change decisions. The others are added later, when the data is clean enough for them to mean something.

Adoption is the only measure of success for a CRM project, and it is the part people work on least. Here is what we have seen produce an effect, and what produces none.

What does not work

• A single training session on launch day. It is necessary and wholly insufficient: what people retain is what they use within the week, the rest is forgotten.
• The internal memo making the tool compulsory. It produces minimal data entry, done fast and badly, which is worse than none because the data becomes misleading.
• The dashboard shown in meetings to compare salespeople. It turns the tool into an instrument of control, and the data then adjusts itself to what people want to show.

What works

Starting with an automation that saves time in the first week, before asking for anything. A record created automatically from a website form, an exchange attached by itself to the right deal, a follow-up appearing in the diary: those gains are felt immediately and buy cooperation for the rest.

Then reducing what is compulsory to the strict minimum. Three fields filled in systematically beat twelve filled in half the time, because partial but reliable data allows decisions, whereas abundant and uncertain data allows none.

Finally, naming somebody in house who looks at the tool every week and corrects the drift. It is the factor that most clearly separates the projects still standing after a year from those that died out. We train them specifically during the project, and their role is written down rather than implied.

The signal to watch after three months

One question is enough to know where you stand: is there still a parallel spreadsheet? If there is, it shows exactly what the CRM cannot do for the people using it. That is valuable information, provided it is treated as a diagnosis and not as disobedience.

The phrase “CRM integration” covers such different scopes that two quotes cannot be compared without this detail.

What is always included

• Framing the real sales process, which is the actual work and not a formality at the start.
• Configuring the tool, its stages, its fields and its permissions.
• The connections to the website and the management tools, within the scope defined during framing.
• Carrying data over within the agreed scope, and preparing the cleaning.
• Training the users, and following adoption through the first weeks.

What is costed separately, and why

The CRM licences, which are in your name and depend on the number of users. Manual cleaning of the database, when your teams cannot take it on, because its size depends on the state of your data and not on our work. And bespoke development, when a business tool offers no standard way to connect.

The variable that makes the price

It is neither the number of users nor the tool chosen, it is the number of connections to establish and the state of the database to carry over. A team of three with six tools to link costs more than a team of twenty with two. It is the first question we ask when costing.