What a CRM consultant costs, and leaves behind

A CRM consultant builds you a state. Somebody in your company has to hold it afterwards, and that person is rarely named in the statement of work. This is one engagement walked through from November to March, priced at each step, to show where the cost that nobody budgeted for actually turns up.

The short answers

• The build is not the expensive part. On the example below, twelve weeks of consultant time comes to about $96,000. The cost that hurt arrived four months after the invoice, and it was not on any proposal.
• Buy the build, hire the operation. A migration is bounded work with an end date and renting deep platform skill for it is sensible. Deciding what a field means and refusing the twelfth pipeline stage is continuous, and it only accrues to somebody who stays.
• The published day rate is vendor pricing. Agency consulting is advertised at $200 to $400 an hour, by a firm selling the service, with no sample disclosed. That is a list price, not a benchmark, and the example below uses the bottom of it.
• The admin-ratio folklore drives the overbuy. The commonly quoted enterprise practice of seven to ten administrators per thousand users makes an internal hire look expensive. FoundHQ’s analysis of Yelp reports 3,000 users supported by a 30-person core team containing five admins. One company is not a ratio, but it is enough to stop treating the folklore as one.
• The question that decides the outcome is asked in November and answered in March. Who owns the configuration on the Monday after go-live? If the answer is “the team”, it is nobody.
• What extends a migration is not record count. It is undocumented automations nobody knew were running, and the number of people entitled to object to a field being deleted.
• This example is constructed. Every figure below is either a cited source or a labelled assumption you should replace with your own. It is not a client account and is not offered as evidence of anything beyond the shape of the problem.

The company

Mid-sized B2B software business in the US, about 90 staff, roughly 25 of them in go-to-market roles. Four years of CRM history on a platform chosen when the company was twelve people. Around 40,000 account and contact records. Four integrations: the marketing automation platform, the billing system, a support desk and a data enrichment tool.

The presenting problem was the one that always presents. Nobody trusted the pipeline number. The CRO’s forecast and the board pack disagreed. Two people produced different win rates for the same quarter and both could show their working.

An internal audit found the specifics:

• 214 fields on the opportunity object, of which 31 had been populated in the last twelve months
• Seven pipeline stages, two of which no rep could define consistently
• Three overlapping automations writing to the same close-date field, added in 2023, 2024 and 2025 by three different people
• Two of the four integrations syncing on schedules nobody had reviewed since setup
• No data dictionary of any kind

This is an entirely ordinary state for a four-year-old CRM. It is what happens when a system of record grows by accretion, and it is worth saying that none of it indicates incompetence. Every one of those 214 fields was added by somebody solving a real problem that week.

What the consultant was asked to do

The brief, as written: migrate to the new platform, rationalise the data model, rebuild reporting, and train the team.

The brief, as it actually was: decide what this company means by a qualified opportunity, and make everybody live with the answer.

Those are not the same job, and the gap between them is where most of this money goes astray. The first is a build. The second is an act of authority that a contractor does not hold, and the statement of work made no reference to it.

Twelve weeks, week by week

Weeks	What happened	Consultant days	Internal days
1–2	Discovery, systems audit, stakeholder interviews	8	6
3	Data model design, field rationalisation proposal	4	2
4	Stage-definition workshops. Ran over.	5	9
5–7	Build: objects, fields, permissions, automation	15	4
8–9	Integration rebuild, four systems	10	5
10	Data migration, cleanse, dedupe, two rehearsals	6	7
11	Reporting layer, dashboards	5	3
12	Cut-over, two days of training, handover session	7	12
1–12	Total	60	48

Week four is the interesting row, and in this shape of engagement it is always the interesting row. The consultant proposed reducing seven stages to five and cutting 214 fields to 46. Both proposals were correct. Neither could be approved, because approving them required somebody to tell a regional sales lead that the field they had asked for in 2024 was going away, and no one in the room had the standing to do that.

The compromise: five stages, 71 fields. The extra 25 fields were the ones with an objector attached. That is not a technical outcome. It is an organisational one, and it was decided in a workshop the consultant could facilitate but could not adjudicate.

The invoice, and the part that is not on it

At $1,600 a day, which is the bottom of the published agency rate of $200 to $400 an hour at eight hours, 60 consultant days is $96,000. That rate is a vendor’s list price rather than a survey, the same page puts retainers at $3,000 to $27,000 a month, and an independent consultant may quote below it. Treat it as the assumption it is.

Line	Cost	Basis
Consultant, 60 days at $1,600	$96,000	Assumption: the bottom of a vendor’s published hourly range, at eight hours
Platform licences, year one uplift	$18,000	Assumption. Yours will differ by seat count and tier
Internal time, 48 days	$21,800	Assumption at ~$100,000 loaded, 220 working days
Data cleanse tooling	$2,300	Assumption
Total, delivered project	$138,100

The engagement went well. The migration completed on schedule with two rehearsals behind it, reporting agreed with itself on the day of cut-over, and the training was competent. By the standard the proposal set, it succeeded.

March

Four months later:

• 71 fields had become 96
• A sixth pipeline stage had been added, informally, by relabelling an existing one
• Two of the new dashboards had been superseded by exports to a spreadsheet, because a regional lead wanted a cut the dashboard did not offer
• The close-date automation had a fourth rule written against it, added to fix a symptom of the third
• The data dictionary the consultant produced had not been opened since January

Nobody did anything wrong. Each individual change was a reasonable person solving a real problem that week, which is exactly the sentence that describes how the original 214 fields got there. The company had bought a clean state and had not bought the thing that keeps a state clean, which is a person with the standing to say no.

The $138,100 was not wasted. It bought four months.

The question nobody asked in November

Who owns the configuration on the Monday after go-live?

In this example the answer, never written down, was “the RevOps-minded sales ops analyst, alongside their existing job”. That person had no mandate to refuse a request from a regional lead, no time budgeted for the work, and had not been in the room for most of the decisions they were now expected to defend. They were not the owner. They were the person the tickets went to.

Ownership of a system of record means three things, and all three have to be real:

The standing to refuse. Most of the work is saying no to reasonable requests, because the twelfth stage is always individually justifiable and collectively fatal. Refusal needs a mandate somebody senior has actually granted.

Knowing why, not just what. The value is in the reasoning behind two hundred small decisions. That is why a two-day handover does not transfer ownership. It transfers mechanics.

Time that is protected. Ownership as the fifth priority of somebody’s existing job is decoration. It needs a named allocation.

If none of those three is true of a named person before the engagement starts, the engagement will produce a clean system that degrades on a predictable schedule, and the company will conclude in eighteen months that the implementation was poor. Usually it was not.

The ratio that makes the overbuy look sensible

The reason companies buy the build and skip the owner is usually an arithmetic that looks sound.

The commonly quoted enterprise practice is seven to ten Salesforce administrators per thousand users. At 90 staff that implies you are nowhere near needing one, so a consultant looks like the efficient choice. FoundHQ’s analysis of Yelp reports 3,000 users supported by a 30-person core team containing five administrators, well under the ratio at a company with genuine complexity. That is a single company and not a survey, so treat it as an existence proof rather than a planning number.

But the ratio is the wrong instrument regardless of its value, because ownership does not scale with users. It scales with the number of people entitled to ask for a change, and with how much disagreement there is about what the numbers mean. A 90-person company where three regional leads each want their own view of pipeline has more ownership work than a 400-person company with one agreed definition. Counting seats measures the wrong thing.

For what the permanent alternative pays: Glassdoor reports a median total pay of $115,000 for a CRM manager, on a base range of $64,000 to $116,000, and ZipRecruiter an average base of $102,130. Total pay and base pay measure different things, which is most of why they disagree; the full band methodology is set out separately and is not repeated here.

Note that the ownership question does not require a full CRM manager at this size. It requires a named person with a mandate, protected time and access, which can be part of an existing senior role if it is made explicit. What it cannot be is unassigned.

What should have been in the statement of work

Four clauses, all cheap to insert in November and impossible to add in March.

Clause	What it prevents
A named internal owner, identified before kick-off, in the room for design decisions	The handover going to whoever the tickets reach
Administrative access held by your staff from day one, not transferred at the end	An undiscovered dependency on the consultant’s account
The data dictionary as a numbered deliverable with an owner, not an appendix	A document that is never opened
A written list of what was deliberately not built, and why	Next year’s team mistaking a decision for an oversight

A vendor who declines all four has told you something useful before you have spent anything. Most will agree readily, because none of it costs them delivery time. It is simply not what proposals are usually written to cover.

There is a fifth clause worth considering and it is harder: a change-control convention that survives the engagement, naming who may add a field and what has to be true first. It will not be followed perfectly. It moves the default from “add it” to “ask”, which over a year is the difference between 96 fields and 78.

What this example does not prove

It is a constructed example. The company is not a client, the figures are a mix of cited rates and labelled assumptions, and nothing here should be read as evidence about how CRM engagements perform in general. There is no published study we are aware of that measures CRM implementation outcomes against a control, and the day rate is a vendor list price rather than a sampled figure.

The pattern it illustrates is real and common, but the specific numbers are inputs for you to replace, not findings.

Two honest counterpoints. Some consultants do insist on a named owner and refuse work without one, and those engagements go materially better. The failure described here is a joint one, not a vendor problem. And some companies genuinely need only the build: if you are migrating because you are consolidating onto a system another team already owns and operates, the owner already exists and none of this applies.

Worth noting on scale, too: 15,384 marketing technology products were mapped in the 2025 State of Martech, up 9 per cent on 14,106 a year earlier. The number of systems that can write to your system of record keeps rising, which makes the ownership question harder every year rather than easier.

Buy the build, name the owner

The consulting spend in this example was reasonable and the work was good. The $138,100 bought a correct system and four months of it staying correct.

What it could not buy was the standing to refuse the ninety-seventh field, and that was never something a twelve-week engagement could have supplied. Decide who holds the system of record before you decide who builds it. The build is the part you can rent.

Related reading

• Revenue operations consulting: buy or hire, for the general version of this decision across all ops work rather than the CRM case.
• GTM engineer versus RevOps manager, for what a CRM manager owns against the adjacent operations roles.
• RevOps salary benchmarks, for the full bands and why the salary sources disagree.
• What to look for in a first ops hire, if the owner this article describes would be your first operations person.
• Why ops hires fail in the first 90 days, for what happens to an owner appointed without a mandate.
• How to hire a RevOps manager, for the search once you have decided the ownership is a seat.