When the System Fights the Team

How a multi-brand infrastructure services company turned a tangled HubSpot Sales Hub Enterprise instance into a system its team actually uses. In the four months that followed, calls logged climbed 43%, deals created climbed 91%, and quotes generated climbed 61%.

Services

Managed HubSpot services

By the time we were brought in, the sales team had mostly given up on HubSpot.

The reps who wanted to use it kept hitting permission walls. The reps who didn't want to use it had a reason to keep avoiding it. The reports didn't make sense to the people reading them. The system wasn't a tool. It was an obstacle.

Four months later, the same team was logging 43% more calls, creating 91% more deals, and generating 61% more quotes. Nothing about the team had changed. The system had finally stopped getting in their way.

This is how that happened.

A sharp business, an opaque system

A multi-brand infrastructure services parent company runs two specialized sister brands that work in sequence. One uses proprietary imaging and mapping technology to inspect the inside of full, operating wastewater and water treatment infrastructure, measuring sediment, sand, and grit without draining the system. The other follows with specialized equipment to clean and restore capacity to the infrastructure the first brand just mapped. Inspect, then clean. Many of their customers work with both.

It's a sharp model. Two sister brands, one parent company, one operational handoff between them.

What didn't match the sharpness of the business was the system behind it.

They had HubSpot Sales Hub Enterprise, but the instance had been built up over time, accumulating custom objects, custom properties, and reporting configurations that no longer had documentation to explain them. Permissions had been locked down so tightly that reps couldn't make routine updates without going to an administrator every other hour. Reports didn't make sense to the people reading them.

The frustration was widespread. A sales consultant working with the company found us on the HubSpot Solutions Partner directory and brought us in to take a look.

The owner's brief was direct:

• Improve user access. Get reps out of permissions jail.
• Reduce the number of custom objects and properties that were creating noise instead of clarity.
• Train users after they actually had the access to do their jobs.
• Address reporting issues and build dashboards that worked for execs and reps.
• Create automations that helped the work move.
• Provide ongoing support so the next set of decisions wouldn't get made in the dark.

The takeaway

Many B2B companies don't need a HubSpot implementation. They already have one. What they need is for the implementation they paid for to actually work, and that's often harder than starting from scratch. Walking into a HubSpot instance built over years means inheriting decisions you didn't make, by people who aren't there anymore, documented in places nobody can find.

Becoming HubSpot archaeologists

Most HubSpot engagements start with a blank canvas. This one started with a forensic dig.

Before we could optimize anything, we had to figure out what was actually in the system. What did each custom object exist for? What was each custom property meant to track? Why was this report built this way? What was the original logic behind these permissions?

There was no documentation. The people who had built the system over time weren't available to ask. The people still using it mostly avoided the parts they didn't understand. We became, as we started calling ourselves, HubSpot archaeologists—slowly excavating what each piece of the system was supposed to do, deciding what was worth keeping, and pruning back the parts that complicated rather than helped.

We worked across the organization to do it: the owner, sales reps on both sides of the business, the project manager who runs bids on the operations side, and a new fractional sales manager. Different roles, different needs, different ways of using the same instance.

The multi-brand complication

There's a layer to this engagement that doesn't show up in most HubSpot case studies: it's a shared instance. Both sister brands run on the same HubSpot environment, sharing accounts, contacts, and reporting.

That's harder than it sounds. Many of the company's customers are served by both brands: the inspection from one, the cleanup from the other. When the system isn't built for that, you get duplicate records, confused ownership, deals that belong to "someone" but nobody can quite say who, and reports that count the same activity twice.

We've started building this in deliberately. Dual ownership of contacts and companies when both brands work the same accounts. A post-sale pipeline that follows a deal through the work-and-billing period after it closes, so the operational handoff doesn't fall off the system. The architecture is catching up to how the business actually runs.

The takeaway

HubSpot optimization at a company with a real instance already in place is rarely about adding features. It's almost always about subtracting them: pruning the complexity that nobody had time to maintain, decoding what's left, and rebuilding around how the team actually works. The first job is to stop the system from getting in the team's way.

What's possible when the system gets out of the way

The hardest metric to move in a HubSpot engagement is the one that matters most: are people actually using it?

Adoption is what we've been able to shift first.

Comparing the four months before our engagement settled in (September–December 2025) to the four months after (January–April 2026):

• Calls logged in HubSpot: +43%
• Deals created: +91%
• Quotes generated: +61%
• Notes added to records: +22%
• Tasks created: +19%
• Emails logged: +13%

Closed-won deals stayed roughly flat in the same window, which is what we'd expect. Infrastructure services have long sales cycles. Deals created in January and February don't close in March. What these numbers show isn't a revenue lift. It's a system finally reflecting what the team is actually doing.

That matters. Everything downstream of accurate pipeline data (forecasting, capacity planning, account prioritization, sales and marketing alignment) depends on the data being honest in the first place.

The qualitative shifts are just as real, even if they don't show up on a dashboard. The older, less tech-savvy users on the team now feel comfortable calling us directly for help, because we're friendly and patient and don't make them feel like they're behind. The on-site super admin has more confidence managing day-to-day decisions on his own, and reaches out when he hits something that needs a second opinion. The system isn't a black box anymore.

What we're building next

The work isn't finished. With the immediate cleanup behind us, we've started mapping and building the second-stage improvements. That includes the dual-ownership and post-sale pipeline work mentioned above, additional automation to reduce manual touchpoints, and reporting that will eventually let the leadership team see each brand both separately and together, depending on the question they're asking.

It's the kind of work that's easier to do once the system is no longer fighting the team using it.

The takeaway

HubSpot adoption metrics (calls, notes, deals, quotes, tasks) are the foundation everything else gets built on. Without them, leadership is making decisions from incomplete data, forecasts are educated guesses, and the platform becomes shelfware that the team works around instead of with. Getting reps to use the system isn't a soft win. It's the win the rest of the value depends on.

If your business is in this place

You have HubSpot already. You're using a fraction of what you're paying for. The system was built over years by people who are no longer there, and nobody on the inside has the time to untangle it. The reps avoid it. The leaders don't trust the reports. The next round of HubSpot decisions keeps getting put off because nobody can quite explain how the current decisions got made.

The work doesn't have to start with replacing the system. It can start with decoding it.