HubSpot implementation: getting it right the first time

A HubSpot implementation is mostly a series of decisions. Which objects hold what, which properties you create, how many pipelines, what lifecycle stages mean, who can see what, and what feeds the reports. Get those right and HubSpot is the best CRM most small and mid-sized businesses will ever use. Get them wrong and you have an expensive address book that nobody trusts.

I set up, fix and extend HubSpot for businesses in Wollongong and across the Illawarra. Most of the portals I am asked to fix were not set up badly on purpose. Someone clicked through the defaults, imported a spreadsheet and hoped. This guide is how to avoid that.

Before you touch HubSpot

Do these three things before anyone logs in to configure anything:

1. Write down the processes HubSpot will run. Lead to client, quote to won, onboarding, renewals, support. One page each: trigger, steps, owner, data, done. (The systems guide has a template.)
2. List the questions you want reports to answer. "Where do our best clients come from?" "How long does a deal take?" "What is in the pipeline for next quarter?" Your reports dictate which properties and stages you need.
3. Decide what HubSpot owns. Contacts, companies and deals almost always. Quotes, projects, invoices and tickets depend on your other tools. Agree the source of truth for each before you build integrations.

If you cannot say what a report should show, you are not ready to create the properties that feed it.

Objects: what lives where

Objects are the main types of record in HubSpot. Pick the right ones and keep their jobs clear.

The two questions I ask before creating anything

• Can one contact or company have many of these? If yes, it is probably a separate object (a deal, ticket or custom object), not a property.
• Does it have its own lifecycle or status? If yes, it wants a pipeline, which means a deal, ticket or custom object.

Example: a property management business might be tempted to store "property address" on the contact. But an owner can have several properties, and each property has its own status, tenants and history. That is a custom object, or at minimum a carefully designed deal or company structure. Storing it as a contact property breaks the first time someone buys a second property.

Properties: fewer, better, documented

Properties are the fields on each record. This is where most portals go wrong, usually by creating too many.

• Use default properties first. HubSpot has sensible defaults for most things. Do not create "Mobile Number 2" when "Mobile phone number" exists.
• Dropdowns over free text for anything you will filter or report on. Industry, region, service interest, lead source detail.
• Name clearly and fill in the description. Future you, and the AI tools reading your portal, will thank you.
• Group them. Use property groups so the right fields show together on records.
• Decide where each property is set. By a form, by a rep, by a workflow, by an integration. If nobody sets it, do not create it.
• Keep a property register. A simple sheet: name, object, type, purpose, who sets it, where it is used.

A good starting portal for a service business often needs only 15 to 30 custom properties across contacts, companies and deals. If you are at 150 in year one, something has gone wrong.

Pipelines and deal stages

A pipeline is the series of stages a deal moves through. Start with one pipeline unless you genuinely have different sales processes, such as new business versus renewals, or two divisions selling different things in different ways.

Rules for good stages

• Each stage is defined by something that happened, not a feeling. "Quote sent" beats "Warm".
• Five to seven stages, plus Closed won and Closed lost.
• Each stage has required properties so data is captured at the right moment (for example amount and close date before "Quote sent").
• Win probabilities are set honestly, and reviewed after six months against reality.
• Closed lost has a required "lost reason" dropdown. This is some of the most valuable data in the portal.

Example pipeline for a B2B service business

Lifecycle stages

Lifecycle stage sits on contacts and companies and says where they are in their overall relationship with you. It is different from deal stage, which is about one opportunity.

Decide, in writing, what each stage means for your business and what moves someone into it. Then automate as much as possible: deal created sets Opportunity, deal won sets Customer. Lifecycle should only move forward. Use a separate property to track former clients rather than moving people backwards.

I go into detail on defining and repairing lifecycle stages in the CRM data clean-up guide.

Users, teams and permissions

Permissions are boring until a junior staff member bulk deletes 3,000 contacts. Set them up properly from day one.

• Limit super admins to one or two people who understand the portal.
• Use teams to group users by function or region, and to control record visibility where needed.
• Restrict delete, export and bulk edit to people who need them. Export rights matter for privacy as well as tidiness.
• Restrict property creation so new fields go through the portal owner, not whoever needs one today.
• Assign seats deliberately. Paid seats cost money. Not everyone needs a full sales or service seat. Check what each person actually needs to do.
• Offboard properly. When someone leaves, remove access and reassign their records the same week.

Integrations

HubSpot sits in the middle of most stacks I build. The question for each integration is: what syncs, in which direction, and which system wins if they disagree?

Before switching any integration on, map the fields. Know which HubSpot properties each one writes to, and whether it can create new records. Integrations are one of the biggest sources of duplicates and junk properties I find. More on connecting the wider stack in systems integration.

Reporting and dashboards

Build reporting from the questions you listed at the start. A good first set for a service business:

• Pipeline by stage and expected close month (what is coming).
• Deals won and revenue by source (what marketing is working).
• Win rate and average deal size by service and by owner.
• Average time in each deal stage (where deals stall).
• Lost reasons (why you lose).
• Speed to lead: time from enquiry to first contact.
• Activity: calls, meetings and emails logged per rep, if that matters in your business.

One dashboard for leadership, one per team. Fewer reports that people look at weekly beat 40 reports nobody opens. If a report is wrong, fix the data or the definition. Do not build a spreadsheet next to it.

Migrating to HubSpot

Migration is where good intentions go to die. The rule: clean before you move, map before you import, test before you switch.

What to bring across, and what to leave

• Bring: active and recent contacts and companies, open deals, won deals for history and reporting, recent notes and key attachments.
• Think hard about: very old closed deals, years of email history, every attachment ever uploaded.
• Leave: junk, duplicates, test records, fields nobody can explain. Keep a dated archive export of the old system for reference.

Example: a business moving 25,000 contacts from an old CRM often finds that after cleaning, 10,000 to 15,000 are worth bringing across. That is less to map, less to pay for, and a cleaner start.

Common HubSpot mistakes

• Importing before designing. The spreadsheet's columns become your property model.
• Property sprawl. A new field for every request, no descriptions, half of them duplicates.
• One pipeline per salesperson, or a pipeline per product when the process is the same.
• Vague deal stages like "Hot" and "Warm" that mean different things to different reps.
• Lifecycle stages set by hand and never updated.
• Everyone is a super admin.
• Integrations switched on without field mapping, creating duplicates and junk properties.
• Workflows nobody owns, some of them contradicting each other.
• Marketing contacts left unmanaged, so you pay to store people you will never email.
• No training, so the team keeps working out of their inboxes and spreadsheets.

When custom apps make sense

HubSpot's standard tools cover most of what a small or mid-sized business needs. Custom development on HubSpot's developer platform, such as app cards that show data from other systems on a record, custom integrations and backend logic, makes sense when:

• Your team constantly switches to another system to look something up while working a HubSpot record.
• You need to push or pull data with a system that has no native integration, or the native one does not do what you need.
• Your process needs a calculation, validation or action that workflows cannot handle cleanly.
• You want AI features working inside HubSpot on your own data, under your own rules.

It does not make sense when the standard tools would work if the process were simpler, or when you are building around a data problem that a clean-up would fix. My HubSpot custom app work starts from $15,000, so I will always check whether a property, a workflow or a native integration would do the job first.

FAQ

Next steps

Write down your processes and the questions you want your reports to answer. That one exercise will make every HubSpot decision easier. If you want someone to design it with you, or fix a portal that has already gone sideways, get in touch.