If you just bought HubSpot Service Hub and you are staring at a setup checklist that runs three pages, you are in the same place every team starts. The Service Hub feature surface is wide, the marketing-led onboarding tries to introduce all of it at once, and the result is usually a two-week setup project that produces something less useful than a focused one-week build.
This guide is the version that works. The exact order to set things up, what to set up later, what to skip entirely, and the part of the workflow most teams forget until the first big customer bug. If you follow this, you will have a working Service Hub for one channel by the end of the second day, a healthy queue by the end of the first week, and time left over to do the parts that compound.
In this article
1.
2.
3.
4.
5.
6.
7.
The Right Order: Lifecycle First, Then Features
The single highest-leverage decision in HubSpot Service Hub onboarding is the order of setup. Most teams try to configure features in the order they appear in HubSpot's UI, which goes from settings to automations to surveys to knowledge base. This produces a setup where automations fire before tickets are flowing, surveys ask about a service the customer has not used, and the team gives up halfway through.
The order that works inverts that. Get the basic ticket lifecycle running first. One inbound channel. One pipeline. The smallest set of statuses that covers the work. Watch real tickets flow through it for a week. Only then add the next layer.
The principle is that complexity should follow problems, not anticipate them. Every feature you configure before you know you need it is a feature that gets ignored, misused, or worked around. The teams that ship the best Service Hub setups are the teams that say "no, not yet" to the most features for the longest.
Day One: The Five Things That Actually Matter
Five settings get you a working Service Hub for one channel. Everything else can wait.
- 1
Create one ticket pipeline
Start with a single pipeline called Support. Resist the urge to create separate pipelines for bugs, billing, sales handoffs, and onboarding on day one. One pipeline keeps the queue simple, lets the team build muscle memory, and surfaces the patterns that justify splitting later.
- 2
Define five ticket statuses
New, In Progress, Waiting on Customer, Waiting on Engineering, and Closed. Five statuses cover almost every team's lifecycle. The "Waiting on Engineering" status is the one most teams skip and the one that does the most work later, because it cleanly separates tickets that depend on your team from tickets that depend on someone else's.
- 3
Add the four ticket properties that drive routing
Severity, Source, Account Tier, and Topic. Severity drives SLA and escalation. Source tracks where tickets come from so you know which channels matter. Account Tier surfaces customer impact without leaving the ticket. Topic enables later reporting. Four properties is enough on day one. More properties means more fields nobody fills in correctly.
- 4
Connect one inbound channel
Pick the channel with the most current ticket volume, usually a support email address. Get tickets flowing through that one channel end to end. Skip the temptation to connect chat, social, and forms on day one. A working email pipeline beats a half-working five-channel pipeline every time.
- 5
Configure assignment for new tickets
Round-robin or single-owner assignment is enough on day one. The fancy routing rules can wait until you have data on what the team is actually triaging.
That is day one. Two to four hours of focused work, and the team can start working tickets in the new system. Everything below is the second week of onboarding, not the first.
Week One: Make the Queue Calm
By the end of week one, the team should be working tickets in HubSpot and the queue should feel calm. The features below are what get you there. Each is configured only after the basic flow is working, not before.
Snippets and canned responses. The reps will need the same five or six replies over and over. Put them in HubSpot Snippets with short slash commands. The biggest leverage is the first-reply acknowledgment and the closing reply when a ticket resolves. The full set of templates is covered in the bug report reply email templates guide.
A basic SLA per severity. Time to first response and time to resolution, scoped to the four severities defined in your Severity property. The targets should come from your team's actual current performance, not from a benchmark blog. The method for setting them is in the support SLA management guide.
Severity-driven assignment. Critical tickets page the on-call. High tickets route to a designated senior rep. Medium and Low tickets stay in round-robin. This is where the routing rules start earning their keep, but they only work because the Severity property and the lifecycle were already in place.
Ticket forms or inbound forms. If customers are submitting bugs through a website form, the form should write directly to the Support pipeline with the right properties prefilled. The required fields on the form should mirror the eight fields from the bug tracking template guide.
By the end of week one, the team should be filing tickets, severities should be assigned consistently, SLAs should be visible, and the reps should be using snippets for the common replies. Anything beyond this is week two or later.
Week Two: The Pieces That Compound
The features in this section are valuable but only after the basics are working. Most teams that fail at Service Hub onboarding fail because they tried to set these up on day one.
A small knowledge base. Start with five articles covering the questions the team answers most often. Five is the right number for week two; fifty is the wrong number. The articles earn their keep when reps stop having to write the same answer in three different tickets per day.
Automations for the most common ticket types. A bug report submitted through a form should auto-assign severity based on a property. A high-tier customer should auto-route to a senior rep. Automations multiply leverage when they are tuned to real patterns, and create chaos when they are configured before the patterns are clear.
Customer satisfaction surveys. The post-resolution survey is the cheapest customer-feedback mechanism HubSpot offers. Turn it on after the team is closing tickets cleanly, so the survey is asking about a real experience rather than a half-broken one.
Reporting dashboards. Volume by severity, response time by rep, ticket-to-resolution time by source. Build the dashboards once the data is real. Build them on day one and you spend a week explaining why the numbers are zero.
The Engineering Handoff Most Teams Forget
The part of Service Hub onboarding most teams skip until volume hits is the path from a customer-reported bug to engineering work. The standard HubSpot onboarding does not cover this because it sits outside HubSpot. The reps file the ticket, mark it Waiting on Engineering, and then the workflow stops being a Service Hub problem and starts being a coordination problem.
Most teams handle this for the first few weeks by pinging engineering on Slack. The pattern works at low volume and breaks the moment the queue grows. Tickets sit at Waiting on Engineering for weeks. The customer never hears whether the bug shipped. Engineering has no view of customer impact. Support and engineering are looking at two different versions of the same bug.
The fix is a real two-way sync between the HubSpot ticket and the engineering tracker. For teams running Linear, that pattern is covered in the Linear HubSpot integration guide. A purpose-built sync like IssueLinker creates a Linear issue from the HubSpot ticket in one click, mirrors status and comments both ways, and stages the customer-facing reply for the moment the fix ships. Support stays in HubSpot, engineering stays in Linear, and the bug stays connected.
If you are onboarding Service Hub and the customer-reported bug flow is one of the workflows you need to support, set this up in week two. Doing it once during onboarding is much cheaper than retrofitting it three months later after the queue has piled up.
Add the engineering handoff during onboarding, not later
If your team runs HubSpot Service Hub and engineering runs Linear, IssueLinker handles the ticket-to-issue sync, status mirroring, and customer-facing reply staging out of the box. Set it up during onboarding and avoid the retrofit three months in.
What to Skip
Five Service Hub features most teams configure on day one and should not.
Multiple ticket pipelines. One pipeline is enough until the team has real data showing why a second one would help. Most teams that split early end up with parallel queues that nobody triages.
The full HubSpot Service Hub property library. Service Hub ships with dozens of default properties. The team needs four or five. Hide the rest. Properties that exist but nobody fills in actively erode trust in the data.
Complex routing rules with conditional logic. Round-robin or single-owner is fine on day one. Routing rules with conditions become someone's full-time job, and they almost always need to be rewritten three months in.
Customer portals. HubSpot Service Hub includes a customer portal where customers can see and reply to their own tickets. It is useful at scale and noise at small scale. Wait until customers ask for it, not before.
Workflows that fire on every status change. The temptation is to wire up notifications for every state transition. The result is a Slack channel that everyone mutes. Start with notifications on Critical only, and add more state-change notifications when the team explicitly asks for them.
Onboarding Day-by-Day
A practical schedule for the first two weeks of Service Hub onboarding.
Day 1: Five core settings. Pipeline, statuses, four ticket properties, one channel, basic assignment.
Day 2: Train the team on filing tickets in the new pipeline. Watch them file the first five tickets each. Adjust the property options based on what they actually use.
Days 3 to 5: Snippets and canned responses. Set the SLAs using the team's current performance as the baseline. Set up severity-driven assignment.
Day 6 to 10: First retrospective. Review the tickets filed in the first week. Adjust property options, status definitions, and severity criteria based on real usage. Configure the engineering handoff if customer-reported bugs are part of your workflow.
Days 11 to 14: Build the first three reporting dashboards. Add the first five knowledge base articles. Turn on the CSAT survey. Set up the first ticket-form automation.
By the end of week two, you should have a working Service Hub setup the team uses without complaint. The features you have not configured yet are the right features to add as the team hits friction with them, not before.
The post worth reading next is the support ticket system guide, which puts Service Hub in the broader category of support tools and helps you decide whether you picked the right one. For the SLA piece, support SLA management covers the targets in more depth.