HubSpot Implementation Plan: Decisions Before Settings

Most HubSpot implementation plans are a list of settings to configure: create the pipeline, import the contacts, build the dashboards. The result is a portal that matches the plan and not the sales process, and a second project six months later to fix it.

A useful HubSpot implementation plan is a list of decisions, each with a name next to it and a date. The settings follow from the decisions in hours. Below are the decisions that come before setup, and who should own each. If your question is how long the whole thing takes, we covered that in our post on the HubSpot implementation timeline.

Why a settings-first plan goes wrong

HubSpot makes configuration fast. A new deal pipeline is a few clicks under Settings, Data Management, Objects, Deals, Pipelines tab, according to HubSpot’s pipeline guide. So teams build first and argue later, and every argument after go-live changes something reps already use.

Some choices are also harder to undo than they look. HubSpot’s lifecycle stage documentation says the default lifecycle stage property only moves forward when HubSpot tools set it. Going back to an earlier stage takes a manual clear or a workflow. And a lifecycle stage that still has records in it cannot simply be deleted: per HubSpot’s guide to customizing lifecycle stages, you first move the records and remove the stage from the tools that use it. A definition you settle in week one is cheap. The same definition changed in month six means moving records and fixing workflows and reports.

The decisions in a HubSpot implementation plan

Write each of these down as one or two sentences, with an owner. If a decision has no owner, the plan is not ready.

1. What each deal stage means. One sentence per stage, in the buyer’s terms: what must be true for a deal to be there. Owner: head of sales. HubSpot requires both a Won and a Lost stage for sales reports to work correctly, so decide what “lost” means too, including deals that simply went quiet.
2. Where marketing stops and sales starts. Which lifecycle stages you use, what moves a contact from one to the next, and who does it. HubSpot’s default stages run from Subscriber to Evangelist, plus Other. You do not need all of them. Owners: head of marketing and head of sales together, with one tie-breaker named in advance.
3. Which data comes in and which stays behind. Migrate what someone will use, archive the rest. Owner: whoever runs revenue operations, or the founder if nobody does.
4. Who sees and edits what. HubSpot’s user permissions guide lets you set view, edit and delete access per object to all records, the user’s team’s records or only their own. Decide this per role before invites go out. Owner: head of sales, with the admin.
5. What the first reports must answer. Three to five questions leadership asks every week, written as questions, not chart names. Owner: CEO or founder.
6. Who owns the portal after go-live. A named person with hours in their week, not “the team”. Owner: whoever signs the budget.

What to check before setup starts

1. Every deal stage has a written entry rule that two reps would apply the same way.
2. The lifecycle stages you will use are listed, and the ones you will not use are named too. Customizing them requires Super Admin permissions, per HubSpot, so know who holds that role.
3. A permission matrix exists: each role against view, edit and delete for contacts, companies and deals.
4. The list of weekly leadership questions is agreed, and each maps to properties you actually plan to capture.
5. The go-live admin is named and has blocked time in their calendar for the first month.

Our take

The portal mirrors how the team really works. If the plan skips the process decisions, HubSpot will faithfully record the confusion, and no feature added later fixes that.

The second part is budget in hours, not only in licence fees. Each decision above takes an hour or two of a senior person’s time, and most of the delay in implementations comes from nobody being able to spend those hours. If your head of sales cannot set aside time for stage definitions in the next two weeks, move the start date. Starting setup without them is how you end up paying for the project twice.

When is a plan overkill? A founder-led team with one pipeline and a handful of users can write all six decisions on one page in an afternoon. That is still a plan, and it is enough.

FAQ

What should a HubSpot implementation plan include?

A written definition for every deal stage, the lifecycle stages you will use and who moves contacts between them, a data migration scope, a permission matrix by role, the questions your first reports must answer, and a named portal owner.

Who should own a HubSpot implementation internally?

One executive sponsor who can settle disagreements, usually the head of sales or the founder, plus a named admin who will run the portal after go-live. A partner can run the project, but your team makes the process decisions.

Can we change deal stages and lifecycle stages after go-live?

Yes, but it costs more later. Changing stages means moving existing records and updating the workflows and reports that use them, and HubSpot will not delete a lifecycle stage that still contains records. Settle the definitions before setup to avoid that rework.

This week, put the six decisions into one document with an owner next to each and share it with your leadership team. Any decision still without a name after that is the real start date of your implementation. If you are already live and the team is struggling, our sales team onboarding checklist is the place to start.

Related reading

• Salesforce to HubSpot migration: what to decide before you export