HubSpot Implementation Services: How to Scope, Sequence and Price One

Two firms quote the same HubSpot implementation at eighteen thousand and ninety-four thousand. Both are honest numbers. They differ because one has scoped a configuration exercise against a clean starting point and the other has scoped a data migration, an integration to a finance system, a rebuild of forty-one reports and the training required for a team that has never used a CRM. The buyer, reading two proposals that both say "HubSpot implementation", has no way to tell which they are being sold, and the cheaper one is not the cheaper outcome.

This article sets out what an implementation contains, so the difference between those quotes is legible before either is signed. It begins with what the work actually delivers, then covers the six inputs that determine its size — which is the part a buyer can assess themselves. It then sets out the phase sequence and what blocks what, because sequencing errors cost more than estimating errors. Pricing models follow, with the trade each one makes, then the delivery spectrum, and then acceptance criteria, which proposals omit more often than they include. It closes with how to select a provider, the antipatterns that make implementations run long, and the checks worth running before signing anything.

The Six Deliverables

An implementation is not an installation, and conflating the two is where the confusion in the opening paragraph begins. HubSpot is provisioned in minutes and the licence is live before anybody starts; what is being bought is the configuration of a revenue system onto it. Six deliverables recur.

A data model. Objects, properties, their permitted values and the relationships between them, derived from how the business actually sells rather than from the defaults.

Migrated data. Records moved, deduplicated and reconciled, through an import or an integration. Of the six deliverables listed here, this is the one underestimated more consistently than any other.

Process automation. Workflows that enforce the process rather than describe it, including the routing, the notifications and the stage gates.

Reporting. The dashboards the business will actually run on, which is a shorter list than the one requested and a longer one than the defaults provide.

Integrations. The joins to finance, to the product, to the website and to whatever else holds customer data.

Enablement. Training, documentation and the first weeks of supported use, without which the preceding five deliverables are configuration nobody adopts.

A proposal that does not name all six has either scoped them out deliberately, which is legitimate and should be stated, or has not thought about them, which will surface later as a change order.

The Six Inputs That Determine Size

A buyer can estimate the scale of their own implementation before speaking to anybody, and doing so is the single best protection against a proposal priced for a different business.

1. Record volume and quality. Not how many records, but how many systems hold them and how much they disagree. One clean source is a week; four sources with overlapping duplicates and no shared identifier is the largest line in the project.

2. Object complexity. Whether the business sells something that the standard contact, company and deal model already describes adequately. A firm selling subscriptions to named users fits it; one selling serialised equipment through dealers, or matters, or engagements that recur annually, needs custom objects and the design work behind them.

3. Integration count, and their direction. Each system connected is a decision about which side owns each field, and bidirectional sync costs several times what one-way costs because conflicts have to be resolved rather than avoided.

4. Reporting requirements. Specifically, the number of reports somebody currently depends on, which is always a longer list than the one produced from memory, and every item on it has to exist on the other side.

5. Process maturity. Whether the business is able to state its own sales process without inventing it in the room. Where it cannot, the implementation includes defining that process, which is consulting work rather than configuration work and is priced accordingly.

6. Team size and CRM literacy. Enablement scales with headcount and inversely with the team's prior experience of a CRM. A team moving from Salesforce needs different training from one moving from spreadsheets, and less of it.

Two businesses with identical licence counts can differ by a factor of five on these six, which is the whole explanation for the two quotes in the opening.

The Phase Sequence

Phases have dependencies, and sequencing errors are more expensive than estimating errors because they are discovered late.

Discovery establishes the process, the data sources and the reporting requirements, and everything downstream is derived from it, which is why compressing it is the leading cause of rework.

Data model design follows discovery and blocks everything downstream of it, because objects and properties cannot be designed before the process is known, and migration cannot begin before the model exists.

Migration follows the model and reliably runs longer than planned, because deduplication and reconciliation are where the time goes and both depend on decisions taken in the model.

Automation follows migration, because a workflow written against records that are about to change will be rewritten.

Reporting follows automation, since the reports depend on properties that the automation is responsible for populating.

Enablement follows everything else and must not be compressed to absorb overrun from earlier phases, because it is the phase that determines whether the preceding five are used at all.

The dependency that catches a project is the second: teams begin migrating while the data model is still in draft, and every model change after that point means remapping.

Pricing Models

Time and materials prices the work actually done, which suits projects whose scope will move — and most implementations' scope moves, because discovery changes what is known. It requires the buyer to trust the estimate and the provider to report against it honestly.

Fixed fee transfers scope risk to the provider, who prices that risk into the number quoted. It suits work whose scope is genuinely stable and known in advance, which in practice means a narrow implementation against a clean starting point. Where scope is not stable, fixed fee produces either a change-order argument or a provider quietly reducing quality to protect margin.

Milestone-based sits between them and works where acceptance can be defined in advance for each milestone. Defining that acceptance is the hard part, and it is worth the effort because it produces the criteria the project will ultimately be judged against.

Retainer suits the continuing work that follows an implementation rather than the implementation itself, because an implementation sold as an open-ended retainer has no defined end, which is a problem for the buyer rather than the provider.

At RevOps HQ projects are time and materials by default, with milestones used where scope is stable enough for acceptance to be defined in advance. The timeline is set on a Gantt and hours are budgeted against it, which is what makes the estimate checkable rather than a number.

The Delivery Spectrum

Implementations sit on a spectrum between two poles rather than in one of two categories, and the mix normally changes across the life of an engagement.

At one pole the provider performs the work, which is faster and produces a better-configured system, and which leaves the client's team knowing less about why the system is the way it is. At the other, the client's team performs the work under direction, review and training, which is slower and builds the internal capability that determines whether the system is still correct in two years. The industry terms for those two poles are done-for-you and advisory respectively.

The pattern that works in practice runs provider-performed through the phases that are hard to get right, meaning the data model and the migration, then moves toward client-performed through automation and reporting, where a team learns by building the things they will later have to maintain themselves.

A buyer should ask which mix is proposed and why it is proposed that way, because a provider defaulting to performing everything itself is optimising for its own delivery speed rather than for the client's position afterwards.

Acceptance Criteria

This is the section that proposals omit more often than any other, and it is the one deciding whether a dispute is even possible later.

Acceptance criteria state what has to be true for a phase to be complete, in terms a non-specialist can verify. "The data model is complete" does not qualify as one, because two people will disagree about whether it is true. "Every field on the legacy opportunity record is either mapped to a HubSpot property, explicitly abandoned with a reason, or flagged for a decision" is.

Three properties together make an acceptance criterion usable in practice. It is verifiable by the buyer without the provider's help. It is stated before the phase begins rather than negotiated at the end. And it is binary, because a criterion that can be partially met will be argued about.

A proposal without acceptance criteria is not cheaper. It has moved the cost from the estimate to the end of the project.

Selecting a Provider

Five questions that separate providers, none of which appears in a capability deck.

1. What would make this provider advise against the project? A provider who has never declined work is selling capacity rather than judgement.
2. Who actually performs the work? The person presenting in the room is frequently not the person who will configure the portal.
3. How is the data model decided? The answer reveals whether it is derived from the business's own process or applied from a template.
4. What happens when discovery changes the scope? This is the question that time and materials against fixed fee actually turns on.
5. What does handover contain? Either documentation, administrator training and a named internal owner, or a set of credentials and an expression of hope.

The HubSpot partner tier is worth almost nothing as a signal on its own, because it is largely a function of licence volume sold rather than of implementation quality.

Antipatterns

Migrating before the model is settled. Every subsequent model change means remapping, and the model always changes during discovery.

Scoping to the licence rather than the business. A Professional licence says nothing about how much configuration the business behind it requires.

Reporting requirements gathered from managers only. The reports people actually run are frequently not the ones their managers describe.

Enablement compressed to absorb overrun. The phase that determines adoption is the one sacrificed when earlier phases run long.

Configuration that encodes the current org chart. Routing and permissions written against named individuals break at the first reorganisation, silently.

No named owner on the client side. A system with nobody internally accountable for it begins degrading from the day the provider leaves.

Verification Before Signing

1. Are all six deliverables named, with the ones excluded stated as exclusions rather than absent?
2. Has the provider asked about all six sizing inputs? A quote produced without asking about record quality or integration count is a guess.
3. Are acceptance criteria stated per phase, binary and buyer-verifiable?
4. Is the sequence right — model before migration, automation before reporting, enablement not last-and-squeezed?
5. Is there a named client-side owner in the plan, with time allocated?

A provider who answers all five well may still be the more expensive quote. They are the quote that can be compared.

Boundaries of This Article

This describes the shape of the work and how to evaluate a proposal for it. It does not price implementations, because the six inputs above vary by more than an order of magnitude between businesses and a published figure would mislead rather than help.

RevOps HQ performs this work, which is an interest worth stating. The test offered here is whether the article is useful to somebody who engages a different provider, and it is written to be.

Two adjacent decisions are covered separately: how to conduct a RevOps audit sets out the diagnostic that should precede a large implementation, and CRM data migration covers the phase that reliably runs long.

In Summary

A HubSpot implementation delivers six things — a data model, migrated data, automation, reporting, integrations and enablement — and a proposal that does not name all six has either excluded some deliberately or not considered them.

Its size is determined by six inputs a buyer can assess without help: how many systems hold the records and how much they disagree, whether the business fits the standard object model, how many integrations and in which directions, how many reports somebody depends on, whether the sales process can be stated, and how large and CRM-literate the team is. Two businesses on identical licences can differ fivefold across those.

Two proposals at different prices are comparable only once both have named their deliverables, been asked about all six sizing inputs, and stated acceptance criteria per phase. Until then the cheaper number is not a cheaper project, it is a smaller description of the same one. Sequencing decides the rest: a project ordered correctly at a higher price finishes ahead of one ordered wrongly at a lower.