The audit that starts every engagement

The fastest way to get a HubSpot programme wrong is to start with a plan. Plans built on assumption survive contact with the portal for about a week. We start with a structured technical audit so the plan that follows is grounded in what is actually there.

Six things we look at

The Project36 audit covers HubSpot architecture, data quality, reporting, workflows and automation, adoption, and governance. Each area is scored against how well it supports the current revenue model.

• Architecture, objects, associations, properties, lifecycle stages, pipelines.
• Data, completeness, duplicates, ownership, source integrity, decay.
• Reporting, dashboards used, dashboards abandoned, alignment with board metrics.
• Workflows and automation, what is running, what is orphaned, what is contradicting itself.
• Adoption, who actually uses which features, and where friction sits.
• Governance, permissions, change control, naming conventions, documentation.

Why we audit before we interpret

The commercial conversation is more useful once we can point at real behaviour in the system. It stops the audit becoming a therapy session about what people would like to be true, and turns it into a working document.

It also gives leadership something they rarely have: a defensible view of the state of the platform, independent of the team that runs it.

What the audit produces

• A written portal state document, function by function.
• A prioritised list of findings, split into fix now, fix soon, and monitor.
• A view of where the current system does and does not support the commercial plan.
• The input we use to run the CORE™ model and design the target architecture.

What we do not do

We do not run generic 100-point HubSpot checklists that never touch commercial reality. We do not present a pile of screenshots as an audit. We do not recommend rebuilds before we have looked at the workflows.

The audit is designed to be short, sharp and honest. Usually two to three weeks of focused work.