HubSpot Onboarding Checklist: 10 Things to Configure Before You Go Live

Every HubSpot go-live we have been called in to rescue was configured competently. That is the uncomfortable part. The properties existed, the pipeline had stages, the emails sent. What was missing was agreement: two teams using the same word for different things, a stage that meant one thing to sales and another to finance, and a portal that quietly stopped being trustworthy about six weeks after launch.

So a HubSpot onboarding checklist that is only a list of features to switch on will not save you. The switches are the easy half, and HubSpot's own onboarding covers them well. The half that decides whether the portal survives contact with your team is a set of decisions nobody enjoys making: what counts as a lead, who owns a record after a handoff, which fields are mandatory, and who is allowed to create things.

This is the checklist we actually run before a launch date, in the order we run it, with the items we deliberately leave switched off. Ten items, three tiers, one owner each.

Why Launches Go Sideways in Month Two, Not Week One

Go-live week usually looks fine. The problems arrive later, and they are remarkably consistent.

The data model was designed around the import file. Someone exported the old system, saw forty-one columns, and created forty-one properties to receive them. Now there are three fields that could plausibly hold an industry, two that hold a region, and nobody can write a report because no single field is reliably populated. Properties are cheap to create and expensive to retire, which is exactly the wrong shape for a decision made in a hurry.

Stages describe the deal instead of the commitment. When a stage is named after an internal activity — "proposal sent," "in discussion" — two reps can put the same deal in different stages and both be right. Forecasting on top of that is arithmetic performed on opinions. Stages need an exit criterion the customer would recognize, which is a conversation between sales and leadership, not a configuration screen.

Everyone can create anything. By month three there are nine lists that look identical, four active workflows nobody claims, and a property called "Status 2." No single act of carelessness caused it; it is the predictable output of a portal with no naming convention and no limits on creation rights.

Go-live is treated as the finish line. The project has a launch date, a plan and an owner. The day after launch it has none of those, because the implementation team dissolves and the portal becomes everybody's job, which means it is nobody's. That is the same failure mode we describe in the complete guide to HubSpot implementation for mid-market companies — the build is the beginning of the operating system, not the delivery of it.

The Launch-Ready Ten

Three tiers, in this order. Tier one is what you cannot retrofit cheaply. Tier two is what has to work the hour you launch. Tier three is what keeps the portal clean once real people are using it. If your launch date is close and something has to slip, slip from the bottom — never from tier one.

Tier 1 — Foundations (items 1–4)

1. The property and data model, written down first. Before creating a single field, write the list of questions the business needs to answer about a contact, a company and a deal. Each question earns at most one property. Decide the type deliberately — a dropdown you control beats a text field somebody free-types into — and decide who is allowed to add options to it. Anything the import file contains that no question needs goes in a notes field or nowhere. A model with thirty deliberate properties outperforms one with a hundred inherited ones every time.

2. Pipelines and stage definitions, one pipeline per sales motion. Not one per team and not one per product. If new business and renewals behave differently, they are different motions and deserve different pipelines; if two regions run the same process, they share one. For each stage write the exit criterion in a sentence a customer would recognize, and agree the probability leadership will forecast on. HubSpot's pipeline and deal stage documentation covers the mechanics; the sentences are yours to write and they are the actual deliverable.

3. Lifecycle stages, plus one written definition of a lead. Lifecycle stages arrive with sensible defaults, and the defaults are not the problem. The problem is that marketing and sales usually hold different definitions of the moment a contact becomes a lead worth calling, and neither has written theirs down. Get both in a room, agree one definition and one owner for the transition, then configure to match. This single agreement prevents more downstream reporting arguments than any other item on this list.

4. A clean import, matched on a unique property. Import into a sandbox-style dry run before the real thing: map every column explicitly, match on a unique identifier such as email rather than name, and check what HubSpot will do with the rows it cannot match. Decide in advance whether questionable historical data comes across at all — a smaller, trusted dataset beats a complete, doubted one, because the first time a rep finds a wrong record they stop believing all of them. Run duplicate management after the import and before you let anyone in.

Tier 2 — Day-One Process (items 5–7)

5. Users, teams and permissions that match how work is assigned. Set teams up to mirror the real reporting structure, because that is what record visibility and reporting will key off later. Grant the narrowest permission set that lets each person do their job, and keep super-admin to a named few. This is far easier to do before launch than to claw back afterwards, when removing an access level someone has grown used to becomes a negotiation.

6. Email authentication and connected inboxes, tested end to end. Authenticate the sending domain before your first send, not after a deliverability problem. HubSpot documents email authentication setup in detail and it involves DNS records, which means it involves whoever controls your DNS, which means it takes longer in calendar time than in work time. Start it early. Then connect the inboxes reps will actually send from and send real test messages to an external address, because a logged activity nobody receives is worse than no logging at all.

7. One complete path from form to owner. Pick your highest-value form. Put the tracking code live on the site, submit the form as a stranger would, and follow the record all the way through: it creates or updates the right contact, sets the right lifecycle stage, notifies a named person, and appears on their list of things to do today. One path that works end to end is worth more at launch than twelve forms wired to nothing. Add the rest in week two, once you have watched one of them behave.

Tier 3 — Guardrails (items 8–10)

8. A naming convention, and limits on who can create. Agree a pattern for lists, workflows, forms and reports that puts the owning team and the purpose in the name, and write it somewhere people will find it. Then restrict creation rights for the asset types that accumulate fastest. This is the cheapest item on the list and the one most often skipped, and it is the difference between a portal you can audit in an hour and one you cannot audit at all.

9. Required properties at the gates that matter, and nowhere else. Make a small number of fields mandatory at the specific stage transitions where the data must exist — a close date and amount before a deal can enter a late stage, a lost reason before it can be marked lost. Resist making everything required at creation: reps route around friction, usually by typing a placeholder, and a required field full of placeholders is worse than an empty optional one because it looks populated in a report.

10. One named owner and a thirty-day review, booked before launch. Put a person's name against the portal, not a team's, and get the review in calendars while everyone still cares about the project. The agenda is fixed and short: what did people work around, which fields are empty that should not be, which stage is collecting deals that never leave. Booking it before go-live is the trick — after go-live, the attention has moved on and the meeting never gets scheduled. What that review turns into over the following quarter is the subject of our HubSpot RevOps setup guide for the first 90 days.

What to Leave Switched Off

A checklist is as much about what you do not build. Each of these is worth doing later, and actively harmful in launch week, because it needs real data or real behavior to calibrate against.

Lead scoring. A score built before there is any conversion history is a list of guesses with a number on it, and sales will discover that within a fortnight and stop trusting it permanently. Wait until you can see which behaviors actually preceded a deal, then build it properly — the approach is in our guide to a HubSpot lead scoring model sales will actually use.

Executive dashboards. Reporting reads the stage and lifecycle definitions you just agreed, and those definitions will move once real deals start flowing through them. Let them settle for a few weeks before anyone builds an executive dashboard, or you will rebuild it twice and lose credibility both times.

A large workflow library. Two or three automations that matter, launched and observed, beat twenty launched blind. Every workflow is a thing that can fire unexpectedly, and launch week is when you have the least capacity to work out which one sent that email.

Custom objects and non-critical integrations. Custom objects are powerful, tier-dependent and hard to unwind, so check your subscription and then check whether a property would do the job. Integrations that are not required for someone to do their job on day one should go live afterwards, one at a time, each with its own verification — a two-way sync failing quietly during launch week is a genuinely bad week.

Four Mistakes That Survive Go-Live

HubSpot Onboarding: Frequently Asked Questions

What should be on a HubSpot onboarding checklist?

Ten items, in three tiers. Foundations you cannot retrofit cheaply: the property and data model, deal pipelines and stage definitions, lifecycle stages with one written definition of a lead, and a clean import matched on a unique property. Day-one process: users, teams and permissions; email sending-domain authentication and connected inboxes; and one working path from form submission to an owner. Guardrails: a naming convention with limits on who can create assets, required properties at the stage gates that matter, and a named owner with a thirty-day review booked before launch. Everything else, including lead scoring, custom objects and executive dashboards, is deliberately left for after go-live.

How long does HubSpot onboarding take for a mid-market company?

The configuration is rarely the constraint. In our experience the calendar is set by how fast the company can settle its definitions: what counts as a lead, when a deal enters each stage, who owns a record after a handoff. Teams that book those decisions as scheduled working sessions with the people who own the numbers move quickly; teams that treat them as questions to answer later go live on time and spend the following quarter reconciling reports. Sequence the agreements first and the build compresses around them.

What should you not configure before going live in HubSpot?

Anything that needs real data or real behavior to calibrate. Lead scoring should wait until there is conversion history to score against. Executive dashboards should wait until the stage definitions have survived a few weeks of use. Large workflow libraries, custom objects and non-critical integrations all add surface area to debug during the one week your team is least able to absorb it. Launch with the smallest configuration that lets work happen correctly, then build on a foundation you have observed.

Is HubSpot's own onboarding enough, or do we need a partner?

HubSpot's onboarding is genuinely good at the product half: it shows you where the features are and how to switch them on. It cannot make decisions your company has not made, and most of the Launch-Ready Ten is decisions rather than clicks: one definition of a lead, one owner per stage, which properties are mandatory and which are optional. If those agreements already exist and are written down, product onboarding may be all you need. If they do not, that is the work, and it is the part that determines whether the portal is still trustworthy in month six.

References

• HubSpot — Set up and customize your pipelines knowledge base documentation (pipeline structure, deal stages, stage probability).
• HubSpot — Use lifecycle stages knowledge base documentation (default stages, stage transitions and automation).
• HubSpot — Manage email authentication knowledge base documentation (sending-domain authentication and the DNS records it requires).
• HubSpot — User permissions guide and Manage duplicate records knowledge base documentation (permission sets, teams, deduplication).
• Ontrac Solutions — The Complete Guide to HubSpot Implementation & Consulting for Mid-Market Companies (the engagement shape these ten items sit inside).
• Ontrac Solutions — HubSpot RevOps Setup: What to Build in Your First 90 Days (what the thirty-day review turns into).

This article is for general informational purposes only and does not constitute legal, financial, tax, or accounting advice. Product capabilities referenced reflect HubSpot's publicly documented features as of mid-2026 and may vary by subscription tier; verify against your own subscription before building.