Decide Who Counts as the Same Customer Before You Automate Your CRM

Buyers ask about interfaces, timelines and price. Almost nobody asks how the system is supposed to tell that two incoming transactions belong to the same customer. That single rule decides whether your CRM is worth more after a year of automation, or less.

The mechanism is dull. An automation creates a record because it was told to create a record. It has no idea whether the person or the company already exists unless somebody defined how to recognise them. Without that definition, the database grows with every order, every web form and every trade fair list, and no error message ever appears.

Why duplicates never show up during acceptance

A broken workflow announces itself. A duplicate record does not. It sits there properly filled in, with a name, an address and a history of its own. It surfaces months later, when two sales people work the same account differently, when an invoice goes to an outdated address, or when a report shows more new customers than actually existed.

Testing during the build runs on a handful of sample transactions, and in a handful of samples the same customer never appears twice. The damage accumulates quietly and becomes expensive to repair, because by then quotes, orders, documents and tasks hang off each duplicate. Merging is no longer a database command at that point. It is manual work.

What makes two transactions the same customer

The question sounds technical. It is commercial. In consumer business the email address carries you a long way, as long as you have agreed in advance that capitalisation is irrelevant and that a second address means a second record.

In business to business it stops working. A hospital orders through central purchasing, a ward reports additional demand, administration asks about the invoice. Three senders, one customer. In the other direction, a shared mailbox for purchasing hides several people with different authority.

Three keys tend to hold up between companies. The customer number from your leading system, provided it actually travels with the incoming transaction. The VAT identification number, which is often missing in ordering. And the combination of company name, postcode and town, which always remains an approximation, because legal form suffixes, accented characters and abbreviations make the same name look different.

There is an uncomfortable conclusion in that list. If the triggering transaction carries no reliable key, no software can produce safe matches. In that case the first task is not automation. It is getting the key into the transaction, through a mandatory field in the order form or a customer number in the account area.

Nobody outside your company can set this rule

Is the customer the company or the person. Is a branch office a separate customer or a delivery address. Does a buyer who changes employer move with the account or start a new one. Is a purchasing group one customer or many. These are decisions your sales organisation owns, not your supplier.

A provider can propose options and explain the consequences. Someone on your side has to decide, and they have to decide before the build. Naming that person up front spares you the most expensive version of this project, which is a finished automation that gets rebuilt after the rule is finally clarified.

What should happen to the doubtful cases

Every matching rule has a grey area. Same company name, different postcode. Same address, different contact. Same person, different employer.

There are three ways to handle it, and you should pick one before anything gets built. Merging automatically is the most convenient and the most dangerous, because merged records are close to impossible to separate afterwards. Always creating a new record is honest but fills the database you were trying to keep clean. Routing to a review list is usually right, because a short daily list for the office is far cheaper than a scrambled customer base.

The review list needs an owner. A list nobody reads is just a slower version of the same problem.

The existing database is a separate item

A clean rule prevents new duplicates. It does not remove old ones. Cleaning up the existing base is a project in its own right: finding candidates, deciding each case commercially, merging, carrying references from orders and documents across, and checking the result.

Say so in your request for proposals. Otherwise you will compare a quote that includes the cleanup with one that does not. The gap will look like a cheaper supplier when it is in fact a different scope.

What belongs in the quote

Four points make offers in this area comparable. The key used to recognise an existing customer. The behaviour in doubtful cases, including who works the review list. The treatment of existing data, either included or explicitly excluded. And which system wins when the shop holds a different address than the ERP.

Sophera Consulting works in exactly that order. Look at the process, write down the matching rule, then build, then hand over with documentation, at a fixed price and without a subscription. The entry point is the free Automation Check.

The recommendation

Settle the matching rule before you request quotes, not after. This needs no technical knowledge, just half an hour with your sales lead and a written answer to two questions. How do we recognise the same customer, and what do we do when we are not sure.

With those two sentences you get comparable offers, a fixed price that holds, and a CRM that improves through automation instead of merely filling up. Without them you get a system that creates records faster than your team can sort them.