A CRM consultant is mostly paid to decide which system wins

A consultant is brought in to fix the CRM. Everyone expects the first week to involve the CRM. Instead it involves a whiteboard, and by Friday there is a diagram on it that nobody in the company has ever drawn: every system holding a customer record, which fields each one owns, and the four places where two systems both think they own the same thing.

Nobody had drawn it because no single person had ever needed the whole picture. Sales knew their half. Finance knew theirs. The gap between them was where every recurring problem lived, and it belonged to nobody.

That diagram is the job. The connector work that follows is real, and it is not what you are paying for.

The technical half is the learnable half

It is worth saying plainly, because the market prices it as if the opposite were true.

Moving records between two systems has a known shape. Authenticate — usually OAuth, occasionally an API key someone will need to rotate. Handle pagination, because the endpoint will return a hundred records and a cursor. Respect rate limits, which means backing off rather than retrying immediately. Make writes idempotent, so a retry does not create a second contact. Log enough that a failure is diagnosable a week later.

None of that is easy exactly, but it is well documented and it is the same every time. A competent engineer picks it up in a fortnight. If a proposal is priced mostly on this, you are paying a premium for something a native connector or an afternoon with the API docs may well cover.

The expensive half is that two systems disagree and both are right

Here is the shape of the actual problem.

The CRM holds a contact's job title. So does the marketing platform. A salesperson updates it after a call. An enrichment tool updates it overnight from a public profile that is eighteen months stale. Whichever system syncs last wins, so the value flips back and forth, and a segment built on job title produces different results depending on the hour.

Nothing here is broken in a way an error log would show. The sync works. It works in both directions, faithfully, forever.

The fix is not technical. It is a decision: for each shared field, which system is authoritative, and what happens to the other one's value. Sometimes the answer is that the CRM always wins because a human typed it. Sometimes it is that the enrichment tool wins unless a human has edited the field in the last ninety days, which needs a column to record that. Sometimes it is that the field should not be synced at all.

Making those decisions requires someone who can hold the whole map, and the authority to get sales and finance to agree in a room. That is the scarce thing. Working out which system owns which field is most of the value of the engagement, and it survives long after the specific connector has been replaced.

What the work actually consists of

In rough order, and the first item is the one clients most often ask to skip:

1. 01Mapping what exists. Every system, every field, every existing integration including the abandoned Zap somebody set up in 2023 that is still running.
2. 02Agreeing definitions. What counts as a qualified lead. When a deal is won — signature, first invoice, or first payment. These are business decisions with reporting consequences, and they are usually undocumented and inconsistently applied.
3. 03Deciding ownership per field. As above. Write it down where a non-engineer can read it.
4. 04Building. The learnable part.
5. 05Reconciling. A scheduled comparison that answers "do these two systems still agree", because they will drift, and you want to find out from a report rather than from a customer.
6. 06Handover. Documentation, credential ownership, and someone internal who has changed something unaided.

Step five is the one that separates a durable engagement from a demo. Two systems that agreed on go-live day will not agree in six months — someone will bulk-edit a field, an import will run twice, an API will change a default. A reconciliation job is the only thing that tells you.

The skills, including the one nobody lists

Search for what integration work requires and you will get API design, SQL, data modelling, ETL, one or two named platforms. All correct, all necessary.

The one that decides whether a project lands is none of those: the ability to get two people who disagree about a definition to commit to one, in writing, in a meeting. Most stalled integration projects are not stalled on code. They are stalled because "customer" means an account to sales and a billing entity to finance, and until somebody forces that question the data model cannot be settled.

The technical skills are a filter. That one is the differentiator, and it is worth probing for directly when hiring.

The titles mean roughly nothing, so ask what they do

The labels are used interchangeably in the market and none is protected, so the title tells you almost nothing. What tells you something is asking what the last three engagements involved and where each one went wrong.

Telling a good engagement from an expensive one

Signals worth weighting, in either direction:

Good. They ask about your reporting before your systems, because that reveals the definitions. They want to see real records, not a sandbox. They tell you something is not worth automating. They produce a written data model before writing code.

Expensive without being good. The proposal prices connector count. Discovery is a one-hour call. Nobody asks who owns a field. The word "seamless" appears more than once. The deliverable is described entirely in terms of what will be built, and not at all in terms of what you will be able to operate.

There is also a specific trap around migration. Moving data between CRMs is a distinct discipline with its own failure modes — deduplication rules, historical activity, field-level mapping of picklist values that do not correspond. If the engagement includes a migration as well as an integration, price and scope it separately. They are different projects that happen to touch the same systems.

Why the data quality question arrives first

Almost every integration project turns into a data quality project within the first fortnight, and the ones that pretend otherwise ship a sync that faithfully propagates rubbish into a second system.

Duplicate contacts that were tolerable in one place become two records in two systems with a sync loop between them. Free-text fields that were merely untidy become mapping failures. A consultant who starts with the data rather than the connector is not padding the engagement; they are doing the part that determines whether the rest works.

The check worth doing today

Pick one field that exists in two of your systems — job title, company size, lifecycle stage, anything. Ask two people which system is right.

If you get the same answer immediately, you have a settled data model and your integration problems are probably genuinely technical. If you get two answers, or a pause, you have found what a consultant would spend the first week finding — and you can start on it before anyone sends you an invoice.