A HubSpot implementation checklist that survives the first quarter
A HubSpot implementation that survives its first quarter needs written exit criteria for every deal stage, lifecycle definitions agreed between marketing and sales, routing rules with an SLA, and a deliberate decision to skip reports whose underlying properties are still empty. Portal settings are the easy part.
By HubReven
Most checklists that rank for this term enumerate portal settings. Turn on this, connect that, import your contacts.
You can complete every item on those lists and still have a portal nobody uses in March. The settings are not what fails. What fails is that nobody wrote down what "Qualified" means, so three reps interpret it three ways, so the pipeline report is fiction, so leadership stops looking at it, so the reps stop updating it.
This is the checklist that addresses that instead.
1. Decide the object model before you import anything
The first irreversible decision is what your business calls things and how that maps to Contacts, Companies, Deals and custom objects.
Questions to answer in writing:
- Is the unit you sell a Deal, or is a Deal a container for several of them? If you sell multi year contracts with annual renewals, a custom object usually beats cramming it into deal properties.
- Does a Company mean a legal entity or a location? Multi location clients break reporting when this is ambiguous.
- Which properties are you creating because you need them, and which because the old system had them? Import is the cheapest moment to drop a field forever.
A property architecture with fewer, better defined fields beats a faithful copy of your old CRM every time.
2. Write exit criteria for every deal stage
This is the item that separates a portal that works from a portal that does not, and it appears on almost no checklist.
A deal stage is not a label. It is a claim about what is true. For each stage, write the sentence that has to be true for a deal to sit there:
| Stage | Exit criterion |
|---|---|
| Qualified | Budget confirmed, decision maker identified, problem stated in their words |
| Proposal sent | Written scope and figure delivered, not a verbal range |
| Negotiation | They have asked for a change to terms or price |
| Closed won | Countersigned agreement received |
Two rules make it stick. Criteria are observable by someone other than the rep, and no stage is allowed to mean "I feel good about it". If two people can look at a deal and disagree about which stage it belongs in, the definition is not finished.
Everything downstream depends on this. Forecast accuracy, conversion rates by stage, stalled deal alerts, all of it is arithmetic on top of these sentences.
3. Define lifecycle stages where both teams can see them
Lifecycle stage is where marketing and sales argue, usually for a year, usually without ever writing the definitions down.
Settle it before launch: what makes a Lead, what makes an MQL, what makes an SQL, and critically, who is allowed to move a record backwards and under what circumstances. Recycling rules matter more than the initial definitions because most records are not won or lost, they stall.
4. Build routing with an SLA attached
Routing without a time commitment is just assignment.
Decide who gets what, by territory, segment or round robin. Then attach the part that makes it real: how long the owner has before the record is reassigned or escalated, and what happens when they blow it. A one day SLA that nothing enforces is a suggestion.
The workflows to build here are unglamorous and they are the ones that hold: assignment, first touch timer, escalation, and a notification that goes to a manager rather than into a void.
5. Import deduplicated, not fast
Import is where portals get permanently poisoned.
Profile the source first: duplicate rate, association integrity, date format consistency, and whether there is a stable external ID to key on. Dedup with a reviewable log so every merge can be explained six months later. Rebuild associations and hierarchies rather than importing flat. Preserve activity history with its original timestamps and owners, because a CRM where every activity is dated go live day is a CRM with no history.
Then reconcile: a side by side report, object by object, signed off before anyone starts working in the portal. If that sounds like the reconciliation step in an integration, it is the same discipline for the same reason.
6. Build only the reports whose properties have data
The most common first quarter failure is a dashboard full of charts reading zero.
The rule: if the property behind a report has been populated for less than a full sales cycle, do not put that report on a dashboard yet. Ship the three reports that answer the questions leadership actually asks, and add the rest as the data arrives. Six accurate charts beat twenty aspirational ones, because the twenty teach everyone to ignore the dashboard.
7. Train by role, and write it down
One training session for everyone is one session that fits nobody.
Reps need their daily path: where their work is, how to log it in fewer clicks than the old way, and what the stage criteria mean in practice. Managers need the dashboards and the alerts. Admins need the workflows and what to do when one misfires.
Then the part that survives turnover: a written playbook and recorded walkthroughs. The person who joins in four months will not have been in the room.
8. Decide what you are deliberately not doing
Scope creep in an implementation looks like helpfulness.
Write down the things you are consciously postponing: the custom object you do not need yet, the integration that can wait a quarter, the attribution model nobody will trust until there is a year of clean data. A list of deferred items is what stops the launch date from moving.
The honest sequencing
If you only have time for part of this, do it in this order: object model, deal stage exit criteria, clean import, routing with an SLA. Reports, training materials and automation can arrive in month two. Stage criteria cannot, because every week without them is a week of data you will have to re-interpret later.
If your portal is already live and this post is describing problems you recognise, the diagnosis step is a portal audit rather than a rebuild, and the root cause is usually not a training problem.
Frequently asked questions
How long does a HubSpot implementation take?
Four to eight weeks for a single hub with a clean data source. The variable is almost never HubSpot configuration, it is how long it takes your team to agree on deal stage and lifecycle definitions, which is a decision, not a task.
Do we need a partner, or can we do this ourselves?
Plenty of teams do it themselves successfully. The parts that most often need outside help are the data migration and the deal stage definitions, the first because it is irreversible and the second because an outsider can force a decision two internal teams have been avoiding.
What should we do first if the portal is already a mess?
Stop adding to it. Audit what is there, fix deal stage definitions and data quality, then decide what to rebuild. Migrating a mess to a new portal produces a new portal with the same mess.
Can we import first and clean up later?
You can, and you will not. Cleanup that is not on the critical path does not happen, and every week of work added on top of bad data makes the cleanup more expensive.
Get the next one