HubSpot Implementation
Configuration of HubSpot against a documented set of requirements: objects and properties, pipelines, automation, permissions and reporting, tested before release.
Configuration against documented requirements
Implementation configures the platform to requirements the client has already established.
Objects, properties, pipelines, permissions, automation and reporting are built in a non-production portal and tested against those requirements before release.
Where the operating model itself is undefined, such as what a stage means or which system owns a field, that specification work belongs to a RevOps implementation. It is scoped separately rather than discovered mid-build.
The shape of the engagement
Phases, their overlaps, and the point at which each is accepted. Durations are scoped per engagement; the sequence and the acceptance points hold.
Buy this engagement
The reporting layer can be bought separately where the rest is already built.
| Item | What it covers | Price | Add to cart |
|---|---|---|---|
| Reporting Build | Dashboards and reports built to answer the questions you actually ask, on data you can trust. | $2,500 |
Scope not listed here is quoted. The full catalogue carries every item.
Your cart
Your cart is empty.
Our work on this
Published research and engagements covering the same subject, so the approach described above can be read at length rather than taken on description.
What is delivered
Each item below is a document or an artefact the client keeps, not an activity performed.
Configured portal
Objects, properties, pipelines, permissions and automation implemented in a non-production portal and promoted after acceptance.
Automation set
Workflows with enrolment, exit and suppression conditions defined, each triggered against a test record before release.
Reporting and dashboards
The reports agreed at the outset, each accompanied by a statement of how the metric is calculated.
Configuration documentation
What was built, why, and the procedures required to extend it without external assistance.
What this includes
How it runs
Requirements review
The requirements are confirmed in writing, gaps identified, and anything requiring a decision referred to the nominated owner before the build begins.
Staged build
Configuration performed in a non-production portal in dependency order, each subsystem tested before the next.
Acceptance testing
Each requirement is demonstrated against a test record, including automation exits, which are triggered rather than assumed.
Cutover
Promotion to production on a scheduled date, against a documented rollback position.
Enablement
Role-based training delivered against the written procedures, followed by an agreed support period.
Milestones
| Milestone | Accepted when |
|---|---|
| Requirements confirmed | Written requirements agreed and any outstanding decisions closed. |
| Build complete | All configuration present in the staged portal. |
| Acceptance passed | Each requirement demonstrated, including triggered automation exits. |
| Cutover | Configuration live in production with a rollback position recorded. |
| Handover | Documentation delivered and training completed. |
Ways of working
Implementation is ordinarily done-for-you through the build and moves toward advisory during enablement, so your administrator can extend the configuration afterwards. The client provides confirmed requirements, a nominated owner for outstanding decisions, and access to the systems in scope.
The engagement plan, the hour budget, the delivery spectrum and the weekly, monthly and quarterly cadence are common to every service and are set out in how we work.
Common questions
HubSpot Implementation FAQ
Onboarding establishes a working foundation and gets a team productive on the platform. Implementation configures the platform against a defined set of requirements, including automation, integrations and reporting. Many clients begin with onboarding and add implementation as requirements develop.
Configuration is performed in a non-production portal wherever the subscription allows and promoted after acceptance. Where it does not, work is staged and scheduled so that changes are reversible and announced.
Then defining them is the first piece of work, and it belongs to a RevOps implementation rather than to platform configuration. Building against undocumented requirements produces a portal that satisfies whoever was in the room.
Migration is scoped separately because its effort is governed by the condition of the source data rather than by the target configuration. It is commonly delivered alongside implementation.
Tell us about your needs and we'll provide a customized solution and timeline.