HubSpot out of the box is good – until your business stops fitting the default model
HubSpot is genuinely good out of the box. That matters, because a lot of CRM advice starts from the opposite place. It treats the default setup as basic, temporary or somehow wrong, when for plenty of teams it is exactly what they need at the start.
A small business can sign up, add its contacts and companies, create a deal pipeline, connect a few forms, start sending emails, log activity and build some useful reports without designing a CRM from scratch. For a fairly linear B2B sales process, that can be more than enough. A contact fills in a form, sales follows up, a deal gets created, the deal moves through a set of stages, and the team can see roughly what is happening.
There is no problem with that. In fact, overcomplicating HubSpot too early is one of the easiest ways to make a portal harder to use than it needs to be.
The problem usually comes later, when the business becomes more nuanced but the CRM is still shaped around the original defaults.
HubSpot’s default model assumes a certain shape of business. Contacts belong to companies. Deals represent sales opportunities. Lifecycle stages broadly move forward. Marketing creates demand, sales follows up, opportunities move through a pipeline, and reporting sits on top of that.
That model is useful, but it is still a model.
Plenty of businesses do not quite fit it. They sell through partners. They run events and need proper attribution. They have subscriptions or memberships rather than simple one-off deals. They manage account health over several years. They have multiple brands, regions or product lines. They need reporting that people actually use to make decisions, not just dashboards that look tidy but do not quite reflect how the business works.
When that happens, HubSpot’s defaults do not usually break. That would almost be easier. Instead, they keep working, but the meaning starts to drift.
A field gets used for two jobs. A status is updated manually for a while, then gradually ignored. A report is technically correct, but built on the wrong object. A deal is associated with a partner, but nobody can tell whether that partner sourced it, influenced it, resold it or was simply connected to the account in some other way.
None of those things looks disastrous on its own. But over time, the business starts bending itself around the CRM rather than the CRM reflecting how the business actually works.
That is where useful HubSpot customisation comes in.
Not customisation as in “add more stuff”. Not complex workflows for the sake of it. Not making the portal look impressive. Good customisation is usually more practical than that. It means putting the right facts in the right place, so the system can be trusted.
Sometimes that means putting a fact on the object that lasts. Sometimes it means putting the fact on the relationship between two records. Sometimes it means deriving a status from something that is actually true, rather than asking someone to remember to update a field by hand.
That is the difference between a CRM that records activity and a CRM that explains what is going on.
Lifecycle stage is useful, but not if it is doing two jobs
Lifecycle stage is one of the clearest places where HubSpot’s default setup can start to drift.
Out of the box, HubSpot gives you a lifecycle stage field. It gives the business a shared language for where a contact or company sits in the funnel: subscriber, lead, MQL, SQL, opportunity, customer and so on.
That is useful. The issue is that teams often use the same field to answer two different questions.
The first question is historic: what is the furthest point this record has ever reached? That matters for funnel reporting. If someone became an MQL six months ago, you want to preserve that fact even if they later dropped out of the process.
The second question is live: where does this person or company sit right now? That matters for sales follow-up, routing, suppression, nurture and reporting on the current pipeline.
Those are different questions, but they often get squeezed into one field.
Imagine someone downloads a guide, becomes an MQL, books a meeting, has the meeting and then turns out not to be a good fit. Historically, they absolutely became an MQL. They may even have become an SQL. You want to keep that for conversion reporting, because it tells you the funnel worked up to a point.
But their current status is different. If there is no open deal, no active lead record and no current sales process, they should not still look like an active sales-ready lead.
The default lifecycle field is not great at handling that distinction, especially because it is usually treated as a forward-moving field. Once a record has moved up the funnel, nobody reliably moves it back. Reps might be expected to tidy it up when a deal dies, but in reality they close the deal, write the note and move on.
That is not a people problem. It is a model problem.
You can see it when the numbers stop making sense. Contacts sit at “Lead” despite having already become MQLs. Companies show as opportunities while key contacts still look like subscribers. Automations promote a record, suppression logic pushes it back, and company-to-contact lifecycle sync fights with both in the background.
The better model is to split the job in two.
Keep the default lifecycle stage as the historic version: the furthest stage this record has ever reached. That makes it useful for funnel reporting, because it answers questions like “how many contacts ever became MQL?” or “how many companies ever reached opportunity?”
Then create a separate live lifecycle or live commercial status field. That field should not rely on a rep remembering to update it. It should be derived from things that are actually true in the CRM.
A closed-won deal means customer. An open deal means opportunity. A booked meeting means SQL. An active lead record means MQL. If none of those things are true, the record drops into whatever earlier stage makes sense for the business.
That gives you two clean answers instead of one muddled one.
The historic field tells you what happened. The live field tells you what is true now.
That is a much better setup than asking one manually editable field to carry history, current status, sales intent and automation logic all at once.
I have written separately about lifecycle models and derivative fields, which go deeper on this specific problem. This post is the wider point: once one field is doing two jobs, the reporting will eventually stop being trusted.
Sometimes the version that would do the job properly is behind a higher tier
Not all customisation is about fixing something that is wrong. Sometimes the default setup is fine as far as it goes, but the thing you actually need sits behind a pricing tier the business is not on.
Conversion tracking is a good example.
Out of the box, HubSpot records a recent conversion on the contact. At a glance, that is useful. You can see the last form someone submitted or the last thing that pulled them back in.
The catch is the word “recent”.
That field overwrites itself every time the contact converts again, so it only ever holds the latest value. For a simple setup, that might be fine. But as soon as you want to understand conversions as a pattern rather than a single latest event, the default does not give you the history you need in any properly reportable form. The raw submissions may still sit on the contact timeline, but they do not give you a clean event record you can use for proper reporting.
That is where the obvious questions become hard to answer.
What lifecycle stage was someone at when they converted? Were they a brand-new lead downloading a first guide, or an existing customer registering for a webinar? How many conversions did we generate last month, and of what type? What is the conversion rate from one stage to the next? Which sources are consistently producing useful conversions, rather than just the most recent one?
All of those questions need a history of conversion events. A single field that keeps overwriting itself cannot give you that.
The cleanest fix would be a custom object: one record per conversion event, each stamped with the date, the source, the conversion type and the lifecycle stage the contact was at when it happened. That gives you a permanent, reportable trail instead of a latest-value field that keeps getting overwritten.
The snag is that proper custom objects require HubSpot’s Enterprise tier. Plenty of businesses are on Professional, where that door is shut.
So you build the capability from what you already have.
HubSpot’s object library includes a handful of standard objects – listings, services, courses and others – that many B2B teams will never use in their intended way. You can take one of those objects, rename it in the portal, add your own properties and use it to store the thing the business actually needs.
For conversion tracking, that might mean one record per conversion, created at the moment it happens, carrying the date, the source, the conversion type and the lifecycle stage at that point. That record can then be associated back to the contact and company, so the business has a permanent, reportable trail instead of one recent conversion field that keeps overwriting itself.
The same approach can work somewhere else. One unused library object might become a conversion object. Another might become an event object, used to track webinars, roundtables or in-person events properly.
The point is not that listings or services are magically the right objects. The point is that the business needs a record for something HubSpot is not otherwise preserving, and there may already be a standard object available that can be adapted before the client has to jump to Enterprise.
There are real trade-offs here. These are still HubSpot objects built for a different original purpose, not true custom objects designed from scratch around your model. You need to choose an object the business is unlikely to need later in its native form. You need to be careful with naming, associations, permissions and reporting so the portal does not become confusing. And the automation needs to be built properly – for example, with re-enrolment where needed – otherwise you risk capturing the first conversion and missing the rest.
But once that is handled, you have given the business something much closer to proper conversion history on a tier that, on paper, does not give you custom objects.
There is a wider point underneath this. “You need Enterprise for that” is not always the end of the conversation. Sometimes it is true. Sometimes the cleanest and most maintainable answer really is a custom object. But sometimes HubSpot already gives you enough pieces to model the process properly, as long as you are willing to think about the data structure rather than just accept the default field that happens to be there.
A person leaving a company is not just a contact status problem
Some CRM problems sound small until you look closely at what the data is actually trying to describe.
A contact leaving a company is a good example.
In HubSpot, a contact can be associated with a company. Out of the box, that tells you the person and the business are connected. But what happens when that person leaves?
The blunt options are not great.
You could delete the contact, but then you lose the history. That is usually a mistake. Someone who was a champion at one company might become a useful contact when they move somewhere else.
You could add an inactive checkbox to the contact. That might stop them receiving emails, but it does not really describe what happened. Inactive where? At which company? Are they inactive generally, or only no longer active at that employer?
You could use a contact status dropdown: active, left business, retired, deceased, no longer relevant. That is better than nothing, but it still puts the fact on the person rather than on the relationship.
That breaks down as soon as the person has more than one company relationship.
Say someone used to work at Company A, then moved to Company B. They should be treated as a previous contact at Company A and an active contact at Company B. A single status field on the contact record cannot express that properly.
The cleaner model is to use association labels.
The relationship between the person and Company A gets labelled “Previous company”. The relationship between the person and Company B remains current. That means the fact sits where it actually belongs: on the link between the person and the company.
This is a small change in the portal, but a big change in meaning.
You keep the contact. You keep the history. You stop treating them as a current employee where they no longer work. You stop marketing to them as though they are still in a role they left two years ago. And you give sales a clearer view of who actually sits inside the account today.
For people with no current employer, you might also use a holding company or a separate structure to keep them out of active account records while preserving the person and their history. The exact approach depends on the business, but the principle is the same: do not force a relationship fact into a person-level field.
The fact belongs on the relationship.
The moment a person can have more than one company relationship at once, a single status field on the person cannot keep up.
Partner-sourced revenue needs more than a basic association
The same association problem shows up in a different form when a business sells through partners, resellers, brokers or referral channels.
Out of the box, an association in HubSpot is just a line between two records. A deal can be associated with a company. A contact can be associated with a company. A lead can be associated with a contact.
That tells you there is a connection, but it does not always tell you what the connection means.
When a partner introduces a deal, that meaning matters. Did the partner source the opportunity? Did they influence an existing deal? Are they the reseller? Are they the bill payer? Are they simply connected to the same end customer in some other way?
If the deal is just associated with the partner company, all of that meaning gets flattened. You cannot separate “deals this partner sourced for us” from “deals that happen to touch this company”. You cannot report partner-sourced revenue cleanly. You cannot look at a partner and understand whether they are actually driving pipeline or just appearing on records after the fact.
The same thing happens with marketing attribution. A webinar, guide, roundtable or campaign might be connected to a lead, but unless the relationship carries meaning, it is hard to tell whether it sourced the lead, influenced an open opportunity, or simply appears somewhere in the contact’s activity history.
A common workaround is to copy a conversion name or campaign name into a text field. That can be useful in simple cases, but it is fragile. Timing can be unreliable. Later conversions can overwrite earlier ones. The field does not always tell you whether something actually created the opportunity or just happened near it.
Association labels give you a better model.
Instead of just associating a deal with a partner company, you label the relationship. Sourced. Influenced. Reseller. Broker. Introducer. Whatever language the business actually uses.
Now the relationship itself carries the meaning.
That makes reporting much cleaner. Partner-sourced revenue becomes reportable because the deal is not merely connected to a partner – it is connected with a specific meaning. Campaign-sourced leads become easier to separate from campaign-influenced leads. Event impact can be measured more fairly because the association tells you what role the event played.
The logic behind those labels matters. For example, you might label an event as “sourced” if the lead or deal was created after the event, and “influenced” if the deal already existed before the event happened. But that logic needs to be applied carefully. Doing it at company level can over-attribute wildly, especially where one company has hundreds of contacts and many unrelated deals. It is usually safer to resolve it at the level of the person who actually engaged, then associate that back to the relevant company or deal.
There is also a practical wrinkle here. If labels are applied by automation, you need a safety net for records created manually. A rep creating a deal directly in the UI may not apply the right label. That does not mean the model is wrong, but it does mean you need a small self-checking workflow that spots missing labels and fixes them where the evidence is clear.
The link between two records is not always the relationship. Sometimes the relationship needs a label before it becomes useful.
Account health should not live on a deal that is about to disappear
Account health is a simple concept, which is probably why it often ends up in the wrong place.
A customer has a red, amber or green status. Easy enough.
In many HubSpot portals, that status ends up on a deal record. It is understandable. The deal is where the team is working. There might be an onboarding deal, then a renewal deal, then an account management deal. The team opens the deal, updates the rating and moves on.
The problem is that deals are temporary.
A customer relationship might last for five years, but a deal might last three months. Every renewal cycle, every onboarding handover and every change in pipeline creates another point where the account health rating has to be copied forward correctly.
Sometimes that happens. Sometimes it does not.
The failure mode is not theoretical. Important customers can drop out of account-health reports simply because the rating lived on last year’s renewal deal and nobody carried it across to the new one. The relationship did not disappear, but the report behaves as though it did.
That is not really a reporting problem. It is a data model problem.
If account health describes the current customer relationship, it usually belongs on the company record. The company persists. The deal does not.
The company can hold the current health rating, the date it last changed and the reason for the change. Deals can still hold deal-specific information: contract value, renewal date, close probability, stage, commercial terms. But the health of the account should sit somewhere that survives the next pipeline transition.
There is a useful nuance here too. “Company” does not always mean the legal parent entity. Sometimes account health should sit at parent level because the relationship is managed centrally. Sometimes it should sit at subsidiary or brand level because the operational relationship is separate.
The CRM should reflect how the account is actually managed, not just what the corporate structure says.
That is the broader principle: durable facts belong on durable objects. If a fact describes a long-term relationship, do not pin it to a short-term record.
When out of the box is the right call
None of this means every HubSpot portal needs heavy customisation.
Plenty do not.
Out of the box is often the right call when the business is early, the sales process is simple and the cost of imperfect reporting is low. If the team is still working out who buys, how sales should run and what the pipeline stages really mean, a lighter setup is usually better.
You do not need a sophisticated lifecycle model before you know how leads are actually handled. You do not need custom association labels before you have a partner motion. You do not need adapted object-library records before the business has any need to preserve event or conversion history in that way. You do not need a detailed account-health model if customer success is still one person managing everything manually.
Over-designing HubSpot too early is a real risk. It creates a system that feels clever but is too heavy for the business to maintain.
The point is not to reject the defaults. The point is to notice when the defaults have started hiding the truth.
That usually happens when people start making real decisions from the CRM. Sales routing depends on the data. Revenue reporting depends on the pipeline. Customer success depends on account health. Marketing wants to know which events actually sourced leads. Leadership wants to understand conversion, not just activity.
At that point, “good enough” data stops being good enough.
The question to ask before customising anything
The best HubSpot customisation usually starts with one question:
Where does this fact actually belong?
If it describes a person, it probably belongs on the contact. If it describes a business, it probably belongs on the company. If it describes an opportunity, it probably belongs on the deal. If it describes a specific interaction, conversion or event, it may need its own record. If it describes the relationship between two records, it probably belongs on the association. If it describes a live status, it may be better derived from evidence than set manually.
That is the practical difference between HubSpot out of the box and HubSpot shaped properly around the business.
The default setup gives you a working model. A good customised setup gives you a trustworthy one.
And trust is the real point. Because once people stop trusting the CRM, they start rebuilding it elsewhere – in spreadsheets, Slack messages, private notes and weekly calls.
That is when HubSpot stops being the system of record and becomes the system people update after the real work has already happened somewhere else.
The aim is not to make HubSpot complicated.
It is to make it honest.
HubSpot out of the box is good. But the longer a business grows, the more important it becomes to ask whether the tool still fits the business, or whether the business has quietly started fitting itself around the tool.