Everything that goes into a HubSpot implementation that your team actually uses, written out from first principles. How the hub architecture fits together, how to design a CRM that reflects your real process, how to build automation that fires correctly, how to migrate data without breaking it, and how to connect HubSpot with the rest of your stack. No promotional content, no features glossed over. Just the mechanics of doing it properly.
Most HubSpot implementations fail quietly. The portal is configured, the team gets a walkthrough, and three months later half the features are unused, the data is a mess, and someone has built a shadow spreadsheet to track what HubSpot was supposed to handle. The platform is not the problem. The implementation was done backward: features first, process second, data never. What follows is how we do it the other way around.
HubSpot is built around a shared CRM database with specialised hubs layered on top. Every hub, Marketing, Sales, Service, CMS, and Operations, reads from and writes to the same contact, company, deal, and ticket records. That shared layer is both the platform's biggest strength and the most common source of problems when it is not designed deliberately.
The practical implication is that CRM design has to come before hub configuration. If you build the Marketing Hub workflows before you have decided what lifecycle stage progression looks like, you will spend the next six months backfilling the logic. We always start with the object model and the pipeline design, then build the hubs on top of a foundation that actually reflects the business.
HubSpot ships with a large set of default properties. Most implementations use fewer than a third of them and then add two hundred custom properties on top, one for every field someone asked for at the time without thinking about where the data would come from or who would maintain it. The result is a contact record with forty fields and twenty of them blank.
Good CRM design starts with three questions: what decision does this property support, who is responsible for keeping it up to date, and what is the source of truth? A property nobody can answer those questions for does not belong in the portal.
A deal pipeline should map exactly to how your sales team actually works, not how you wish they worked. That means stages defined by what the buyer has done, not what the seller wants to do next. "Proposal sent" is a seller action; "Proposal reviewed by prospect" is a buyer signal and a much stronger indicator of where the deal actually sits.
We build pipelines by interviewing the people who use them, then mapping the buyer's journey from first contact to closed, with a clear entry criterion and a clear exit criterion for each stage. Teams that had a pipeline and were not using it consistently usually find that the stages were defined by the previous sales manager in a way that does not match how deals actually move.
HubSpot's four standard objects (contacts, companies, deals, tickets) cover most use cases, but companies with more complex data models need custom objects. A SaaS company might need a Subscription object to track plan, MRR, and renewal date separately from the deal. A professional services firm might need an Engagement object to track project deliverables. Custom objects add power but also complexity, so the rule is: use them when the standard objects genuinely cannot model the data, not because it feels cleaner in theory.
Marketing Hub handles email, landing pages, forms, ads, social, and the automation that ties inbound activity to contact records. The configuration work that matters most is not the visual stuff; it is the logic underneath it.
The four things that determine whether Marketing Hub is actually working for you:
Sales Hub gives reps the contact timeline, email tracking, meeting booking, deal management, and sequences. The gap between what it can do and what most teams actually use is enormous, and it usually comes down to the same two problems: the CRM was not set up to reflect the real sales process, so reps trust the spreadsheet more than the portal; and the features that save the most time (sequences, templates, meeting links) were never configured by someone who knew how the team sells.
The configuration work we do on Sales Hub:
Service Hub manages customer support through a shared inbox, a ticketing pipeline, a knowledge base, and customer satisfaction surveys. The most common failure mode is a ticketing pipeline that was never mapped to the actual support process, so tickets sit in stages that do not mean anything and the reporting is useless.
We build the ticket pipeline from the support team's real triage and escalation logic, add SLA rules that reflect the commitments the team has actually made, and configure routing so tickets land with the right person without manual intervention. The CSAT and NPS surveys are only worth running if the data feeds somewhere useful, so we connect them to contact properties and dashboard views the team checks regularly.
Workflows are where HubSpot earns its licence fee back, and they are where the most expensive mistakes happen. A workflow that enrolls the wrong contacts, fires at the wrong time, or has a broken branch will corrupt your data without any visible error. We treat workflow design the same way we treat software development: requirements first, spec before build, test before activation.
Workflow types we build most often:
Lead scoring is one of the most requested features and one of the most often abandoned after implementation. The reason is usually the same: the score was built with point values that someone guessed, it was never validated against deals that actually closed, and after a month the marketing team had 600 MQLs that the sales team did not trust.
A scoring model that works has two components. Demographic fit (company size, industry, job title, region) tells you whether this is the type of company that buys from you. Engagement depth (page visits, email clicks, form submissions, demo requests) tells you whether this particular contact is actually interested right now. The two scores should be tracked separately and combined at the MQL threshold, because a perfectly fitting company with no engagement is just a list of cold prospects, and a highly engaged contact at a company that is too small or the wrong industry is a time sink for the sales team.
Data migration is where implementations get delayed, and the delay is almost always because the source data was messier than expected. The rule we apply: do not start a migration until you have done a full audit of the source system. That means understanding the object model, mapping every field to a HubSpot property, profiling the data quality (completeness, duplicates, outliers), and agreeing on what gets migrated versus what gets archived.
The migration itself follows a specific sequence. We run a test migration to a sandbox portal first, review the output with the client, fix the mapping issues, then run the full migration to production with a validation pass before the cutover. Activities (emails, calls, notes, meetings) are migrated separately from records because they have different data shapes and different acceptable quality levels.
Almost every CRM migration surfaces duplicates. Contacts created from web forms, imports, and manual entry over years rarely have the consistent email addresses and domain names that make automated deduplication reliable. We run a fuzzy match analysis against email, phone, name, and company before the migration, review the matches by confidence tier, and merge or archive in batches with a full audit trail.
HubSpot has a built-in duplicate management tool that handles obvious matches. The harder cases (same person with two different email domains, or a contact and a company record that should be associated but are not) need human review and sometimes an Operations Hub data quality workflow to catch new duplicates going forward.
HubSpot sits in the middle of a stack, not at the edge of it. The value of the data it holds depends on how well it stays in sync with the systems that generate and consume that data. A contact that exists in HubSpot but not in your billing system is a gap in your customer view. A deal that closes in HubSpot but does not trigger a Stripe invoice is a broken process.
Integration options in roughly ascending order of complexity:
HubSpot's reporting is powerful and widely underused. The default dashboards are a reasonable starting point but they answer the questions HubSpot assumes you have, not the questions your team actually needs to answer. We build reporting from the decisions that need to be made, not from the charts that are easy to create.
The reports that tend to matter most in an early implementation:
| Report | What it tells you |
|---|---|
| Contact lifecycle stage breakdown | Where contacts are accumulating or stalling in your funnel |
| Deal velocity by stage | How long deals spend at each stage and where they go when they leave |
| MQL to SQL conversion rate | Whether marketing and sales agree on what a good lead looks like |
| Email deliverability by campaign | Open rate, click rate, and unsubscribe rate by send, with a baseline to compare against |
| Workflow enrollment errors | Contacts that failed to enroll or hit a broken step, caught before they become data quality issues |
| Rep activity summary | Calls, emails, and meetings logged, so adoption of the CRM is visible rather than assumed |
Adoption is where most implementations fail, and it is the part most implementation partners skip because it happens after the handover. A portal that is technically correct but not used is not an implementation; it is an expensive archive.
The factors that drive adoption are not complicated, but they require the implementation team to care about them. The interface needs to be configured to show people the information they need to do their job, not the full depth of what HubSpot can store. A sales rep who opens a contact record and sees forty fields, most of them blank, will go back to their spreadsheet. A rep who opens a contact record and sees the five things they need before a call will use it.
We run role-specific onboarding sessions rather than a generic product walkthrough. Marketing sees the campaign setup, form logic, and email tools. Sales sees the pipeline, sequences, and meeting links. Support sees the ticket pipeline and the knowledge base. Each session ends with the team using the tool for their actual work, not a demo scenario, so any process mismatches surface before go-live rather than in a support ticket two weeks later.
The thirty days after launch are the highest-risk period for adoption. We stay available during that period, monitor the portal for usage signals (workflow enrollment errors, properties being bypassed, stages that never have deals in them), and run a check-in call at week two to address what has come up in practice.
An honest list of the failures we see most often and how to avoid them:
That is the full methodology. When you want it applied to your portal, the next step is a free audit: a real review of your actual setup, a prioritised roadmap, and no obligation to proceed.
A free audit on your real portal, the gaps and their costs quantified, and a fixed scope to build what it maps out. Findings in a week.
Get a free HubSpot audit