Optimizing CRM Architecture: A Case Study on Revamping HubSpot Systems

They had been paying for HubSpot for years. The licences were active. The deal stages existed. There was even a pipeline, technically. But when we pulled up their instance for the first time, what we found looked less like a revenue system and more like a filing cabinet that had been knocked over in 2021 and never picked back up.

Four reps across three states, each working their own process. No stage exit criteria. No routing logic. No documented handoff from sales to operations. Custom properties created and abandoned. Sequences nobody had turned on. And a distributor channel they were about to launch into, with zero infrastructure to support it.

This is the write-up of the rebuild. The client is a B2B manufacturer and supplier in the commercial sector, operating a recurring-revenue model with a growing distributor channel across multiple Australian states. They're anonymised here, but the architecture is real — and it applies to any B2B business sitting at the intersection of direct sales, channel partners, and an ERP-based fulfilment stack.

HubSpot is not the problem. It never is. The problem is that someone set it up once, handed it to the team with no documentation, and called it done. Every CRM mess we inherit looks exactly like this. Arsalan Faysal — Revenue Systems Architect

What the Audit Actually Found

We start every engagement the same way. Before we build anything, we document everything. Not what the client thinks exists — what actually exists.

The audit covered five areas: pipeline architecture, data integrity, integration health, property schema, and adoption evidence. What we found was a classic growth-stage CRM problem. The tool had been configured by someone who knew enough to get it running, but not enough to build something a sales team would actually live inside.

The audit deliverable was a written current-state document — not a slide deck, not a list of "opportunities." A plain-English diagnosis: here is what is broken, here is why, here is what we recommend, and here is the fixed-price scope to fix it. The client approved Phase 2 within four days.

The Distributor Data Model: How We Actually Built It

This is the part most HubSpot consultants get wrong. They reach for Custom Objects immediately because it sounds sophisticated. Or they build a flat structure and try to differentiate distributors via a single dropdown property. Neither works at scale.

For this client, the right answer was a parent-child company hierarchy combined with a carefully designed association schema and a set of custom properties at both levels. Here is why, and how we did it.

The Problem the Model Had to Solve

The client's commercial model creates a specific reporting need. A distributor is responsible for a portfolio of end-user accounts beneath them. When a distributor's account manager onboards a new end-user, that end-user relationship needs to exist on the HubSpot record independently — with its own contacts, deals, and activity history — but roll up to the distributor for channel reporting.

Revenue attribution had to work in two directions simultaneously. Leadership needed to ask "how much recurring revenue is Distributor A generating?" and also "what is the lifetime value of End-User Account 47 under Distributor A?" The same deal needed to answer both questions cleanly.

The Architecture We Deployed

DISTRIBUTOR CHANNEL DATA MODEL
------------------------------------------------------------------
COMPANY (Distributor)                      [Parent Record]
  |-- Record Type: "Distributor"
  |-- Properties: Territory, Channel Tier, Contract Date, 
  |               Monthly Recurring Revenue, YTD Revenue
  |
  +-- COMPANY (End-User Account)           [Child Record]
  |     |-- Record Type: "End User"
  |     |-- Associated to: Parent Distributor
  |     |-- Properties: Site Type, Equipment On Loan,
  |     |               Monthly Chemical Spend, Account Status
  |     |
  |     +-- CONTACT (Site Contact)
  |     |
  |     +-- DEAL (New Equipment Placement)
  |           |-- Pipeline: "Distributor Channel"
  |           |-- Property: Channel Partner [lookup -> Parent Co.]
  |           |-- Property: Deal Type: "Channel" vs "Direct"
  |
COMPANY (Direct Account)                   [Flat Record]
  |-- Record Type: "Direct"
  +-- DEAL (Direct New Business)
        |-- Pipeline: "Direct Sales"
        |-- Property: Deal Type: "Direct"

The critical implementation decision was keeping two separate pipelines — one for direct new business, one for channel deals. This sounds simple but it matters enormously for reporting. Mixing deal types inside one pipeline forces you to filter constantly and introduces human error. Separating them means every dashboard, every report, every automation can be scoped cleanly to one motion without ambiguity.

For the parent-child company structure, we used HubSpot's native company associations with the "Child Company" relationship type. No custom object needed. Each End-User account is associated to its Distributor parent, and both records carry a Record Type property that drives automation, reporting filters, and view permissions across the team.

One Pipeline. Three States. Non-Negotiable Exit Criteria.

The client had three sales reps operating across Victoria, New South Wales, and Queensland. Each had their own mental model of what "qualified" meant, what a proposal stage required, and when to hand a won account to operations. There was no shared definition of anything. In practice this meant pipeline reports were fiction — deals sat in stages they had outgrown, and nobody had the same conversation twice.

We built one documented pipeline with seven stages, mandatory exit criteria at each gate, and territory-based lead routing enforced by automation. The stages are not the interesting part. The interesting part is the criteria.

Stage Exit Criteria (the part most CRM builds skip)

The mandatory lost reason list is one of the highest-ROI things we build on every engagement. It takes ten minutes to set up and within a quarter it tells you whether you're losing on price, on product fit, on timing, or to a specific competitor. That data directly feeds the quarterly business review and the sales coaching process. Without it, lost deals just disappear into the void.

Territory Routing

Lead routing was built on a single property: State / Territory. Every inbound lead — from Jotform, from the website, from manual entry — gets a state value assigned either automatically (via URL parameter on web forms) or as a mandatory field on manual creation. A workflow then fires and assigns the deal and contact to the correct rep based on that property, sets their task queue, and notifies them via Teams.

No round-robin. No manual distribution. No leads sitting unassigned for three days while someone decides whose turn it is.

Making the Stack Actually Work Together

This client ran HubSpot alongside Cin7 Omni, Xero, PandaDoc, Jotform, and Microsoft 365. Every one of those tools was doing something. None of them were talking to each other in any meaningful way.

The integration brief was: build the minimum viable connected stack. Not everything integrated with everything. The right data, flowing in the right direction, at the right time. Here is what we built and why.

Microsoft 365 (Outlook + Calendar)

The Outlook integration was partially broken — emails were not reliably logging against contact records, and calendar sync was not configured at all. We reset the integration, enforced the HubSpot Sales Extension for every rep, and configured auto-logging rules scoped to known CRM domains. Calendar sync was set to two-way with a 60-day lookback. This alone saved reps an estimated 20–30 minutes per day in manual logging.

Jotform Lead Capture

The client used Jotform for web enquiries. Leads were landing in HubSpot but hitting a dead-end list with no routing, no lifecycle stage assignment, and no follow-up automation. We rebuilt the Jotform-to-HubSpot mapping: every submission now creates or updates a Contact, associates it to a Company if one exists, creates a Deal in the correct pipeline based on the form's enquiry type, assigns it to the correct territory rep, and enrols it in the appropriate welcome/qualification sequence. The whole thing runs natively with HubSpot's Jotform integration. No Zapier required.

PandaDoc

The client asked whether to replace PandaDoc with HubSpot Quotes. Our recommendation was to keep PandaDoc. Here is why.

HubSpot Quotes are functional but limited for complex B2B proposals. PandaDoc offers significantly richer template control, approval workflows, and document analytics. For a team whose proposals include equipment specifications, installation terms, and chemical pricing schedules, PandaDoc is the better tool. We configured the native HubSpot-PandaDoc integration so proposals are created, tracked, and linked to deals automatically — and deal stage advances on proposal acceptance.

Cin7 Omni and Xero

This is where most consultants either overcomplicate things with custom middleware or underdeliver with a manual handoff. Neither is acceptable.

The right approach for this client was a documented manual handoff with a single data-entry point, supported by a Cin7 order creation trigger from HubSpot won deals, using Make (formerly Integromat) as lightweight middleware. Here is why we chose this over a fully native or fully custom route.

The Dashboards That Feed the Weekly Scorecard

This client runs on EOS/Traction. That means every metric on a dashboard needs to trace back to a question someone is actually asking in a weekly L10 meeting. We do not build reports for the sake of reports. We build the three or four numbers that tell the leadership team whether the business is on track — and the deeper drill-downs that explain why when it is not.

We built two dashboards: one for the weekly sales review, one for the distributor channel.

Weekly Sales Dashboard

Distributor Channel Dashboard

Getting a Sceptical Team to Actually Use It

This is the part that sinks most CRM implementations. The build is the easy part. Getting four sales reps who have operated independently for years to follow a shared process, in a tool they have already decided is "just admin," is the real challenge.

Here is what we did, and why each element matters.

We did not hold one big training day

One four-hour training session is how you get a team that knows how to click around HubSpot for a week and then reverts to spreadsheets. We delivered training in three formats across two weeks:

Live management session (90 minutes): For the sales manager and operations lead. Walkthrough of the pipeline, the distributor model, and the reporting dashboards. Focus on how to read the data, identify problems, and coach reps using the tool. If management uses the reports, reps update their deals.

Role-specific rep sessions (60 minutes each): Individual walkthroughs for each rep. Not "here are all the features." Here is your territory view. Here is how you log a visit. Here is what "Qualified" means now and what you need to fill in before moving a deal. One rep at a time, their specific workflow, in their specific HubSpot view.

Written SOPs (not a knowledge base nobody reads): Two documents per role: a quick-reference card (one page, laminated in their heads by the third use) and a full SOP with screenshots. The quick-reference card covers the five things a rep does every day. The full SOP answers every question they will have after the training ends.

We connected the tool to the meeting rhythm they already trusted

This team ran weekly L10 meetings on EOS. They already trusted that process. We made HubSpot the source of truth for the sales section of every L10. The sales manager opens the pipeline dashboard, not a spreadsheet. If a deal has not moved in two weeks, it shows up on the dashboard, not in a retrospective conversation that could have been avoided. That single change — putting HubSpot on the screen at the one meeting they already attended — did more for adoption than any training session.

What We Would Tell the Next B2B Manufacturer Doing This

Three things come out of every engagement like this that we tell the next client before we start.

Do the discovery properly or do not do it at all. The paid audit phase is not bureaucracy. It is the thing that stops you spending three months building the wrong architecture. Every shortcut taken in Phase 1 becomes a rebuild in Phase 3.

The data model decision is the whole game. Custom Object versus parent-child versus flat structure with properties — this decision shapes everything that comes after: every report, every automation, every integration, every training conversation. Get it wrong and you are refactoring under live conditions with real data. Get it right and the rest of the build is straightforward.

Keep the stack smaller than you think you need to. This client had five tools. Every one of them was justifiable. The integration design was not about connecting everything — it was about identifying the two or three data flows that mattered most and making those bulletproof. The rest could wait. Complexity in a tech stack is not sophistication. It is debt.

If Your CRM Looks Like This Client's Did

Most B2B businesses in manufacturing, distribution, and professional services have the same problem. They have been paying for HubSpot for years. The tool is technically "set up." The team is technically "using it."

But the pipeline reports do not match what is actually in the field. Every rep works differently. The won deal sits in HubSpot and the order lives in a spreadsheet. And when someone asks "how are we performing against our distributor targets this quarter?" the answer involves pulling three different reports and doing manual arithmetic.

That is a systems problem, not a people problem. And systems problems have systems fixes.

I build HubSpot architectures for B2B businesses with complex sales motions — distributor channels, multi-state teams, recurring-revenue models, ERP integrations. The engagement starts with a fixed-price audit. You get a written diagnosis and a fixed-price build scope. No open-ended hours. No surprises.

In This Build What the Audit Found The Distributor Data Model One Pipeline, Three States Stack Integration EOS Scorecard Dashboards Getting Teams to Use It What We'd Do Differently Build Yours