Why ‘Mostly Working’ Is the Most Dangerous State for a CRM

“This Feels Clunky… but I Can’t Quite Explain Why”

This is usually how the conversation starts.

I’m on a call with a client, screensharing their portal in HubSpot, and they’re walking me through how they handle memberships.

They say something like:

“So the member fills out the form, we update the contact, then when they renew we overwrite those fields… and finance checks a spreadsheet because some members pay online and some get invoiced.

It mostly works.

It’s just… kind of a mess.”

That pause at the end?
That’s the tell.

Nothing is technically broken—but everyone is doing extra mental gymnastics just to understand what they’re looking at.

The Membership Was Living on the Contact Record

In this case, everything lived on the Contact:

• Membership level
• Start and end dates
• Member number
• Payment type
• Renewal status

And my first response is usually gentle:

“Okay — quick question. Can one person ever have more than one membership over time?”

There’s always a beat.

“Yes. Of course.”

And that’s when I say the thing that usually lands:

“Then a membership probably isn’t a contact field. It’s its own thing.”

You can almost see the lightbulb flicker.

Why It Felt Wrong (But No One Could Name It)

Here’s what was actually happening behind the scenes:

• Every renewal overwrote history
• Staff couldn’t tell which membership they were looking at—just “the current one”
• Reporting couldn’t answer basic questions like:
  • How many memberships expired last quarter?
  • How many were renewed late?
• Finance needed logic that didn’t belong on a Contact at all

No one was using HubSpot “wrong.”  They were just asking the wrong object to do the job.

The Fix Wasn’t More Fields — It Was Structure

I introduced a Membership custom object.

And before I even talk about workflows or reports, I explain it like this:

“Contacts are people.
Memberships are agreements.
Agreements have lifecycles.”

Once framed that way, the model becomes obvious.

Now:

One Contact → many Membership records

Each membership has its own:

• Level
• Term
• Renewal status
• Payment method
• Member number
• Contacts stopped being cluttered
• History stopped disappearing

Nothing fancy. Just honest data modeling.

The Same Conversation Happens With Loan Applications

Different client. Different industry. Same moment. They’re using Deals to track loan applications.

I ask:

“Does every application turn into a funded loan?”

They laugh.
“No.”

“Can one borrower submit more than one application?”

“Yes.”

“Then your Deal record is doing too much.”

Loan applications have underwriting stages, documentation, and compliance requirements.
Deals should represent funded outcomes—not every attempt.

Once applications moved to a Loan Application custom object, the noise dropped immediately.

Sales saw funded deals.
Operations saw applications.
Reporting stopped lying.

This Is the Pattern I See Over and Over

By the time someone calls me, they’re usually saying:

“We had to add one more field…”

“Only two people really understand this…”

“We track part of this outside HubSpot…”

“Reporting is… inconsistent.”

That’s rarely a training issue.

It’s usually a sign that:

• Something happens more than once
• It has its own lifecycle
• And it shouldn’t overwrite itself

That’s custom object territory.

“But Will This Be Confusing for My Team?”

This is the next question — and it’s a fair one.  The answer is no, because custom objects look and behave exactly like native ones:

• Same record layout
• Same activity timeline
• Same properties panel
• Same associations to Contacts, Companies, Deals

If your team knows how to open a Deal record, they already know how to use a Membership or Loan Application record — or any other custom object that is created.

A Few Setup Things I Always Talk Through Live

This is where I slow people down in meetings.

Associations First (Always)

I’ll usually say:

“Before we build anything, we need to decide who this connects to and how.”

One-to-many vs one-to-one matters more than almost anything else.  Pipelines Should Match Reality.  And if the object has stages, they should reflect real operational steps, not recycled sales stages with new names.

Ownership & Visibility

I always ask:

“Who actually works this record day to day?”

Because custom objects don’t just affect one team — they affect the whole portal.

What You Need in HubSpot to Do This

To create custom objects, you’ll need either:

• An Enterprise tier of Sales, Marketing, Service, or Operations Hub
  or
• Operations Hub Professional or Enterprise

Once they exist, they behave like first-class objects — but reporting and automation still depend on the hubs you own.

The Way I Usually Wrap This Conversation

I’ll end client calls with something like:

“If HubSpot feels harder than it should,
it’s usually not because you’re missing a feature.

It’s because the system doesn’t match how your business actually works.”

Custom objects aren’t about making things complicated.
They’re about stopping the workarounds.