From the July 8th, 2026, edition of How Teams Work
We've been using HubSpot's new AEO tool lately to get a sense of how it works and what kind of insights it actually surfaces.
So we ran through the steps, picked some prompts, and let it generate suggestions on what to prioritize and what content to publish.
We chose one of the content recommendations and did a quick Google search to see what would come up. What we saw was a bit surprising, and honestly, kinda funny
Six agencies. Same topic. Same title. Same angle.
While nobody necessarily did anything wrong. They just saw the recommendation, generated a blog with Breeze, and hit go. They followed the recommendation exactly as it was given, without applying any of their own context. The result was six versions of the same content.
Same tool, same prompt, same output. Nobody configured it to think differently, so it didn't.
This exact situation reminds me of a problem that we see in a lot of portals we come across.
Teams that stick with HubSpot's defaults rather than configuring the platform for how their business actually operates.
HubSpot is built to be usable from day one. Once you get through onboarding and install your tracking code, you can start importing contacts, tracking web visitors, moving deals through pipeline stages, and building dashboards. It all works.
Until you need it to work for your business. HubSpot’s defaults don't know how your business actually functions.
This reminds me of a situation we had with a customer.
They wanted to track attribution data for contacts and deals being pulled in through an integrated CRM their sales team was using. HubSpot does track attribution by default. First touch, converting campaign, record source, original traffic source.
But when their marketing team went to prove that their campaigns were actually influencing revenue, the data was spread across multiple different properties, incomplete in others, and missing entirely in some cases because the sales team wasn't following a consistent process.
That's not a reporting problem. That's a setup problem. The system was never configured to capture attribution the way their business actually needed it.
This is a common thing we see when we get inside a portal that's been live for a year or more. The team was onboarded, but the system was never implemented.
HubSpot can work out of the box, but it will only be truly useful when it's set up to reflect how your team actually works.
Every business has a different sales process, different data requirements, and different lifecycle definitions.
HubSpot needs that context to be useful. Without it, the system will never fully reflect how your business operates.
When HubSpot gets deployed team-by-team
Here's a pattern we see often.
A company starts with one hub, usually Marketing Hub or Sales Hub.
The team that's going to use it gets involved in the setup, gets configured well enough to start, and gets to work. It's not perfect, but it functions.
Then the business grows. A new hub gets added. Maybe Sales Hub comes after Marketing Hub, or Service Hub gets bolted on when the customer success team needs a home.
But the teams that are now being brought into the system weren't part of the original conversation. What was set up for marketing doesn't necessarily reflect how sales works. What sales built doesn't account for what customer service needs. Each team inherits a system that was designed without them in mind.
Before anything got configured, there was a cross-department conversation that should have happened to align all teams around shared definitions and processes.
That important conversation keeps getting bumped. There's always a campaign to ship, a deal to close, something more immediate. It feels less urgent than the work right in front of you, so it waits.
Over time, the result tends to look something like this:
That last point matters more than it might seem. When team members change, new people have to reverse-engineer how the system works.
Without documented processes, they piece together what they can, add their own layer on top of something they don't fully understand, and move on. Every time that happens, the system gets a little harder to untangle and a little harder to trust.
One of the clearest signs an implementation went wrong is when someone asks for a report at the end of a project that nobody anticipated at the beginning.
You're deep into a build, in the final stages, and a stakeholder asks: can I get a report that shows X? And sometimes the answer is no. Not because HubSpot can't do it, but because the underlying data wasn't structured to support it.
To get that report now means going back to the beginning, redefining fields, rebuilding automation, and re-testing everything.
That's why reporting and data requirements should be one of the first questions you ask, not one of the last.
Get that list together at the start, because it tells you how everything underneath needs to be structured. The report is the output. The data design is what makes the output possible. You can't design the data without knowing what you're trying to produce.
The same is true for training, and for the same reason.
Training feels like the last step, something you do after the system is built and ready to go live. But understanding who's going to be in the system and what they need to do every day is a design input, not an afterthought.
If your BDRs are the primary users of a lead management process, the system needs to be built around how they work.
If there's a service or onboarding team downstream, their day-to-day needs have to be accounted for in the build.
Get that wrong, and you end up with a system that causes friction and pushback from the team from day one.
Getting it right comes down to asking the right questions at the start and making sure the right people are in the room when you do.
When you bring your car in and tell the mechanic you think it's the carburetor, a good mechanic doesn't just go replace it. They look at the whole car, run diagnostics, and check things you didn't think to mention. Their job is to figure out what's actually happening, not just take your word for it.
We approach portals the same way. When we get access to a client's CRM, we can see things that aren't always visible from the inside:
What a client describes about how their system works and what we actually find when we look are often two different things. Not because anyone is being dishonest, but because it's hard to see your own system clearly when you're inside it every day.
We also bring the actual end users into the discovery process. Not just the project lead or the executive sponsor, but the people who are going to be in the system every single day. They'll tell you things that don't make it up the chain. A sales rep can show you exactly where their process breaks down in HubSpot in a way their manager can't, because the manager isn't the one hitting the wall every time they try to update a deal.
We do reverse demos and process walkthroughs with the people who live in the system. Because what you're building has to work for them, not just for the person who signed off on it.
The alternative, taking requirements at face value and building exactly what someone describes, is a common way implementations go wrong. We've had clients come to us with detailed documentation on exactly what they need and tell us they don't need discovery, just build it. We don't do that. Not because we don't trust them, but because even the most detailed requirements document reflects what someone thinks they need. Our job is to also surface:
That work upfront is what keeps everything else from unraveling later.
If you're about to start a HubSpot implementation, or you're looking at an existing instance trying to figure out why it's not working, the instinct is usually to jump straight into the platform. Change some settings, add some properties, build a workflow. That's the wrong starting point.
Before you touch anything, you need to understand how your business actually operates.
Start by mapping your customer journey.
That map tells you what HubSpot needs to support. Without it, you're configuring features without knowing what problem they're solving.
From there, identify every team that's going to touch the system. Not just your main stakeholders, but every person who's going to log in, update a record, run a report, or depend on the data being accurate. Each team has different needs, and if the system isn't built with all of them in mind, the ones who weren't considered will find workarounds. Those workarounds become your data quality problem.
Once you know who's using the system and how, define what they need to see from it.
Get that list together before you build anything, because every item on it is a design requirement. It tells you what data you need to capture and how it needs to be structured. Try to figure it out after the fact, and you end up back at step one.
Here's a simple way to gut-check where you stand. Go into HubSpot right now and try to pull a list of your active customers. Can you do it cleanly, with results you trust?
If yes, your foundation is in decent shape. If you're fumbling with filters or getting inconsistent results, you just found your starting point.
Most teams that struggle with HubSpot adoption call it a people problem. The team isn't using it. They're not updating their deals. They keep going back to spreadsheets.
That's not a people problem. It's a design problem.
If the pipeline stages don't match how your sales team actually works deals, why would they update them?
If the system wasn't built around how your team actually operates, it's going to feel wrong to the people using it every day.
The question isn't, "How do we get our team to use HubSpot?" The question is, "Did we build something worth using?"
HubSpot is a powerful tool. But it doesn't know your business out of the box. It doesn't know your sales process, how your marketing team defines a qualified lead, or what your leadership needs to see every week. Your job, before you build anything, is to answer those questions clearly enough that what you end up with actually reflects the answers.
The companies that get the most out of HubSpot aren't the ones that onboarded the fastest. They're the ones who took the time to figure out how their team works before they started building anything.
Take the time upfront. Everything after that moves faster because of it.
Want to get the "How Teams Work" newsletter sent to your inbox? Subscribe Now.