Your CRM records the past. It could be answering what's next.

I once sat in client meeting where a someone asked a straightforward question: based on how fast deals are moving right now, which of our services will run out of delivery capacity first? Nobody in the room could answer it. Someone had to pull raw deal data out of HubSpot and cross-reference it against team availability in a custom spreadsheet, which was the same workaround they ran every quarter. Nobody had ever configured the CRM to tie deal speed to real operational capacity.

That's the pattern. It isn't a HubSpot failure; it's a build failure. Most instances are set up to manage a basic process: log the contact, track the deal, note the call. That's a fair description of what a CRM is for, which is why nobody thinks to question it until someone senior needs an insight the system was never configured to produce.

Set up correctly, HubSpot answers commercial questions directly. Set up around data entry alone, it only tells you what already happened. We see this often enough across client projects - different sectors, same root cause - that it's worth writing down.

It's also the focus of my session with Chris Grant at HubSpot UNBOUND 2026: "The Decision Engine: How to Build a CRM That Drives Action", a Deep Dive running Wednesday 16 September in Boston. Their point is simple: a HubSpot instance should drive action, not just store history.

What does building a CRM around decisions look like?

It requires reversing the usual build order.

The typical approach starts with default objects - contacts, deals, tickets - and populates them as activity happens. A decision-led approach starts somewhere else entirely: with the specific questions the business needs answered, and the calls someone in the room has to make. Everything else - properties, pipeline stages, dashboards - is built to serve those questions directly.

In practice, that means:

• Naming the decision before touching the platform
• Working backwards to the exact data that decision requires
• Building the pipeline, property, or association needed to produce it without manual workarounds
• Treating every dashboard as the answer to a specific question, not a general-purpose report

What decisions should a HubSpot instance answer?

Lead volume, MQL conversion, win rate, and top channels are already handled by standard HubSpot reporting. That's fine, but it isn't where the real value sits.

The harder, more useful target sits a layer above the funnel - questions that shape commercial strategy rather than pipeline hygiene:

• Do we have enough pipeline once territory or rep coverage is properly factored in?
• Is there enough market penetration in segment A to justify launching product B?
• What proportion of the customer base holds product A but not product B, and is closing that gap a sales motion or a marketing one?
• Should we stop marketing a course, service line, or SKU because it will sell out anyway, and move that budget to one that won't?
• Which accounts deserve a rep's time based on stage velocity rather than deal size alone?

Each of these is a real commercial call. None of them come out of a standard lead-to-close report. Answering them requires the CRM to be built with that specific decision in mind from day one, rather than retrofitted after someone asks for it in a meeting.

We built exactly this kind of instance for a higher education client, where the core question had nothing to do with lead volume. It was capacity: is this course going to fill on its own, and if so, where should the marketing budget be redirected? That isn't an out-of-the-box HubSpot report. You have to design for it deliberately.

Read the Case Study: See how we re-engineered the University of Leeds’ HubSpot architecture to turn their CRM into a commercial decision engine.

Where does AI fit into this?

It makes structural design far more critical. Tools like Breeze are only as reliable as the data model underneath them. Feed an AI layer clean data that's already organised around real business decisions, and it returns useful answers. Feed it a database built purely for data entry, and it will still give you an answer - just a fluent, confident, and entirely wrong one. Based on the instances we've audited, most weren't built with a single named business decision in mind. That is precisely the gap an AI layer exposes rather than fixes.

Decision-led CRM design isn't a nice-to-have step on the way to AI adoption. It's what makes AI adoption work.

What stops companies from building around decisions?

Not the schema. Building the right property or pipeline stage is the easy part.

The real obstacle is ownership. Adding a field often reveals who owns a number, whose process gets questioned, and whose reporting looks worse once real data becomes visible. The technical execution is straightforward, which is precisely why it gets avoided: it forces conversations about accountability that a standard data-entry CRM allows people to skip.

A HubSpot instance that only records what happened will keep sending teams back to Excel to figure out what to do next. Built around decisions first, it answers those questions directly and gives any AI layer on top of it a solid foundation to work from. Anyone who says the schema is the hard part hasn't tried changing who owns a number.

If you're at UNBOUND this September, Chris Grant and I are hosting a session that goes deeper into this argument, backed by real-world case studies.

FAQs

How long does it take to rebuild a HubSpot instance around decisions rather than data entry?

It depends on how many decisions you're designing for and how much of the existing setup can be adapted versus rebuilt. A single high-priority decision, such as pipeline coverage reporting, can often be built into an existing instance in a matter of weeks. A full re-architecture across marketing, sales, and service typically takes a few months.

Do we need to rebuild HubSpot from scratch to do this?

No. Most of the work is additive: new properties, updated associations, a few reworked pipeline stages, and dashboards rebuilt around specific questions. Existing data can stay, provided it's audited against the decisions you've prioritized.

Where should we start if we only have time to fix one thing?

Pick the single decision that currently causes the most manual rework—usually the one someone rebuilds in a spreadsheet every reporting cycle—and design the CRM to answer that one first. It's far more effective than trying to fix the entire instance at once.