What an ERP Consultant Should (and Shouldn't) Do

A $40 million industrial distributor gets a consulting proposal for its ERP rollout: "Consultant will provide comprehensive project support throughout the implementation lifecycle, ensuring successful delivery of business objectives." Eleven pages, four different price ranges depending on "final scope," no named individuals, no defined deliverables tied to any of the line items. The CFO signs it anyway because the software vendor recommended the firm and the timeline is tight. Six months later the project is four months behind schedule, $180,000 over the original estimate, and nobody on the client side can point to a single document the consultant was contractually obligated to produce. This happens constantly, and it happens because most first-time buyers don't know what a consultant is supposed to deliver, so they can't tell a real proposal from a padded one.

What a consultant does beyond selling you the software

The software vendor sells and supports the platform. The consultant — whether an independent, a boutique firm, or part of a larger systems integrator — is supposed to do the work of making that platform fit your business. Concretely, that breaks into a handful of deliverables that should each show up as a named item in any serious statement of work:

• Requirements gathering and gap-fit analysis. Structured workshops with each department, documenting current-state processes and testing them against the software's standard workflows. The output is a gap-fit document listing every place the software's default behavior doesn't match how the business runs, and a recommendation for each: change the process, configure around it, or build a customization.
• Solution design, or blueprint. A written document describing exactly how the system will be configured — chart of accounts structure, approval workflows, item numbering scheme, integration points — that both sides sign off on before configuration work starts. This is the single most commonly skipped deliverable, and its absence is the single biggest predictor of scope disputes later.
• Configuration oversight. Actually building or directing the build of the system per the signed-off design, not just advising from the sidelines.
• Data migration coordination. Defining field mappings, cleansing rules, and validation criteria, and coordinating with whoever's doing the technical extraction and load, whether that's the consultant's own team or yours.
• Test script development and UAT coordination. Writing the specific transaction scenarios your team will run through during user acceptance testing, and tracking defects to resolution against a defined severity scale.
• Training delivery. Role-based training for end users, not a single all-hands demo three days before go-live.
• Go-live and hypercare support. Being reachable and useful for the 30-to-60-day period after cutover, when real transaction volume exposes what testing missed.

If a proposal doesn't map its fees to something resembling this list, with named outputs, you're buying hours, not outcomes.

Red flags in a consulting proposal

Vague deliverables. Phrases like "comprehensive support," "end-to-end guidance," or "best-in-class implementation services" that don't tie to a specific document, workshop, or sign-off point are a warning sign, not marketing polish. Ask directly: what will you hand us, and when? A competent firm answers that in a sentence per deliverable. A firm that can't is selling you time, not a result.

Day-rate padding. Watch the staffing plan, not just the total. A proposal that puts five consultants on-site full time for a project that a competent team of two could run is padding the invoice with bench time. A reasonable rule of thumb: for a mid-market single-entity implementation, roughly 50 to 250 users, a core team of a project lead plus one or two functional consultants, supplemented by a technical resource for integrations and data migration, is usually enough. If the staffing plan looks like six people from week one, ask what each of them is actually doing in weeks one through four — usually the honest answer is "ramping up," which you shouldn't be billed full rate for.

No defined acceptance criteria. Every milestone in the statement of work should have a stated, checkable definition of done — "design document reviewed and signed by client stakeholders X, Y, Z" rather than "design phase complete." Without that, a consultant can declare a milestone finished and invoice it while you're still finding gaps.

Uncapped time-and-materials with no not-to-exceed clause. T&M billing isn't inherently bad — it's honest about the fact that scope discovery is genuinely uncertain early on. But T&M with no cap and no checkpoint for re-approval is a blank check. Ask for a not-to-exceed number per phase, with a defined process for what happens if the estimate needs to move.

Bait-and-switch staffing. The proposal names a senior partner in the sales process, and a junior consultant two years out of school shows up to do the actual configuration. Ask for named individuals and their relevant project history in the contract itself, not just the pitch deck.

Structuring milestone-based payment

Paying 100% up front or 100% on completion both create bad incentives — the first removes any leverage you have if the work is poor, the second starves the consultant of cash flow and encourages corner-cutting to reach the final invoice faster. A milestone structure that works reasonably well for a mid-market implementation:

A meaningful holdback tied to that last milestone — even just 10% — matters more than its size suggests. It's the only leverage you have to keep a consultant engaged after they've technically "gone live" and are eager to move on to the next client. Without it, hypercare quietly turns into email response times measured in days instead of hours.

Systems integrator versus boutique functional consultant

These are genuinely different products, and picking the wrong one for your project size is a common expensive mistake. A large systems integrator, running dozens of concurrent ERP engagements across multiple platforms, brings bench depth for big, multi-track programs: simultaneous workstreams across finance, manufacturing, and multiple countries, with a formal methodology and layers of quality review. That depth costs more in overhead and typically shows up as more junior staff doing the hands-on configuration under a senior architect's oversight.

A boutique functional consultant — often a single person or small team who has done nothing but, say, NetSuite manufacturing implementations for the last eight years — brings narrower but deeper expertise, lower overhead, and direct access to the person actually doing the work rather than a layered team. For a single-entity, single-country implementation under roughly 150 users, a boutique consultant is frequently the better fit: faster decisions, no account-management layer, and pricing that reflects a smaller cost base. For a multi-entity rollout spanning several countries and modules running in parallel, the boutique model usually can't field enough concurrent bench strength, and the integrator's methodology and program-management muscle starts earning its premium.

A quick gut check: if your project has more than two or three simultaneous workstreams that need to run in parallel with dedicated leads, you're probably in systems-integrator territory. If it's one entity, one core team, and a defined sequence of phases, a boutique consultant can usually do it faster and cheaper.

There's a hybrid pattern worth knowing about too: some mid-market companies hire a boutique functional consultant to run the overall project and own the client relationship, then bring in a systems integrator's technical specialists on a subcontracted basis for one narrow piece, commonly a complex integration or a data migration with unusually messy source data. That arrangement can combine the boutique firm's lower overhead and responsiveness with deeper technical bench strength exactly where it's needed, without paying integrator overhead across the whole engagement.

Checking references properly

Almost every firm hands over two or three glowing references. The value isn't in whether the reference is positive — it's in what you ask once you have them on the phone. Two questions consistently surface more than a generic "would you recommend them": ask for a project that's a similar size and module scope to yours, not just any reference on their list, and ask directly what went wrong at some point during the engagement and how the consultant handled it. Every real project hits a rough patch — a missed deadline, a requirement that got discovered late, a key person leaving mid-project. A reference who says "honestly, nothing went wrong" either hasn't run a real project or isn't being candid. A reference who describes a specific problem and a specific, competent response tells you far more about how the firm behaves under pressure than a testimonial ever will.

It's also worth asking who on the reference's project actually did the hands-on configuration work, by name, and whether that's the same person named in your own proposal. Firms rotate staff across projects constantly; confirming the actual assigned team, not just the account lead who ran the sales process, closes off the bait-and-switch risk described above before the contract is signed rather than after.

Realistic day-rate ranges

Rates vary by region, software tier, and how in-demand a given platform's specialists are, but as a working baseline for U.S.-market engagements in 2026:

• Junior implementation consultant: roughly $100-150 per hour, usually working under a senior lead on configuration tasks.
• Independent boutique functional consultant, mid-market platforms like NetSuite, Business Central, or Acumatica: roughly $150-250 per hour, or $1,200-2,000 for a full day.
• Mid-tier regional systems integrator, blended team rate: roughly $200-350 per hour.
• Tier-1 or global systems integrator, large SAP S/4HANA or Oracle Cloud programs, blended team rate: roughly $250-450 per hour, with partner-level oversight often billed separately at $500-plus per hour.

A useful sanity check on any quote: multiply the blended rate by the staffing plan's total hours and compare that to your internal budget model, ideally the same one used to estimate total project cost when the business case was first built with something like an ERP TCO calculator. If the consulting line item alone approaches or exceeds the software licensing cost over the implementation period, that's not automatically wrong for a complex multi-entity rollout, but it's worth a direct conversation about why, staffed by whom, and against which specific deliverables.

Ongoing support after go-live: retainers versus project rates

The consultant relationship doesn't have to end at hypercare, and for most companies it shouldn't. Business requirements keep changing after go-live — a new state's sales tax rules, a new product line, a reporting request the original design didn't anticipate — and having a consultant on retainer to handle those is usually cheaper and faster than starting a fresh vendor search each time something comes up. Two structures are common. A block-hours retainer sells a fixed number of hours per month, often 10 to 40, at a modest discount off standard project rates, with unused hours either rolling over for a limited window or expiring. A named-support retainer instead guarantees a response-time service level, say a four-hour response for urgent issues, for a flat monthly fee regardless of hours actually used that month, which suits companies that want predictable budgeting more than banked hours.

Typical pricing for a mid-market single-entity company: a block-hours retainer with a boutique consultant runs roughly $2,500-$8,000 a month depending on hours committed, while a named-support retainer with defined service levels from a larger firm often starts around $3,000-$6,000 a month and scales with system complexity and user count. Whichever structure you pick, put an explicit escalation path in writing before you need it — what counts as an emergency, who gets contacted first, and what happens if the consultant doesn't respond within the agreed window. That clause is worth almost nothing during a calm month and is the only thing that matters during an outage at 4 p.m. on a Friday.

None of this is about distrusting consultants as a category — a good one is often the single biggest factor in whether an ERP project lands on time and actually gets used the way it was designed to be used. It's about being able to read a proposal the way the consultant's own project managers read one: deliverables, named staff, acceptance criteria, and a payment structure that keeps everyone's incentives pointed at the same finish line.