How we operate

We run HubSpot the way a warehouse engineer runs a data pipeline: with governance, versioning, and a clear record of every change and why it was made.

The operating philosophy

Most RevOps practices are built on trust. They trust that the lifecycle stage a sales rep set last quarter still means what it meant when it was set. They trust that a dashboard built three integrations ago still reflects current logic. They trust that the workflow no one touched in eight months is still doing what the name says it does.

We do not operate on trust. We operate on inspection.

Every property, stage definition, association rule, and workflow dependency is treated as a claim that needs to be verified against the data. When a definition lives in a single governed location, every downstream report inherits the same answer. When a workflow is versioned, you can trace exactly what changed, when, and what broke. That discipline is not overhead. It is the only way reporting gets reliable and stays reliable.

The result is a HubSpot portal that behaves like a source of truth, not a filing system that happens to have dashboards on top.

How an engagement flows

Stage 1

Audit

Every engagement starts with an inspection of the data layer. We do not start by building. We start by finding out whether the foundation can support what you want to build on it.

The audit covers property hygiene, lifecycle stage integrity, association completeness, deduplication state, and workflow dependencies. The output is a defect register: each finding ranked by the severity of what it breaks, with a remediation estimate attached. That register turns “the numbers feel off” into a prioritized, fundable backlog.

Stage 2

Architecture roadmap

Before we write a single workflow or migration script, we produce an architecture decision. This document defines the object model, the association rules, the lifecycle stage taxonomy with a single agreed definition per stage, and the canonical property set that carries your reporting load. It specifies what integrates to what and who owns each data flow.

The roadmap is not a slide deck. It is a working reference that every subsequent build decision is checked against. If a requested change conflicts with the architecture, we surface that conflict before building.

Stage 3

Build

Build phase executes the roadmap in a defined sequence: data cleanup and dedup first, then property rationalization, then lifecycle stage restoration, then automations, then the reporting layer. The sequence matters. Automation built on uncleaned data inherits the mess. Reporting built before the definitions are locked will need to be rebuilt.

Changes are documented as they happen. Every workflow gets a clear name, a stated purpose, a write map of the properties it modifies, and a notation of what triggers it and why. You own that documentation when the build is done.

Stage 4

Embedded retainer

Build phase ends. Governance does not. Property rot, lifecycle drift, and workflow sprawl all return the moment no one is holding the line. The embedded retainer puts a senior operator inside your stack each month to work the backlog, extend the architecture as the business changes, and run a quarterly review of properties, stages, and workflows to prevent sprawl from compounding.

The same operator who understands your data model stays on it. There is no ramp-up. There is no translation between the consultant who designed the system and the team left to maintain it.

Working cadence and communication

We operate async-first. Synchronous calls are reserved for decisions that actually require them: scope changes, architecture reviews, handoffs.

The default communication rhythm is a weekly written update delivered at the start of each week. It states what was completed, what is in progress, what is blocked, and what decision or input we need from you before the next update. It is written to be read in three minutes.

For anything that benefits from a walkthrough, we record a Loom. A recorded walkthrough is more useful than a meeting: you can pause it, rewind it, share it with a new hire, and refer to it six months later when you need to remember how a workflow was designed and why.

Metric definitions live in a single governed document. When a number is referenced in a report, the definition behind it is one click away. If the definition changes, the document changes first, and every report that references it is updated. We do not allow the same metric to mean different things in different dashboards.

What makes Capstan Works different

Most HubSpot agencies are HubSpot-only. Their ceiling is what the HubSpot interface exposes. When the data problem requires a warehouse, they stop.

We are built at the intersection of modern data-stack engineering and HubSpot operations. We can run a dbt model against your Snowflake or BigQuery warehouse, push the clean output back to HubSpot via a reverse-ETL layer, and have that reflected in your reports, all governed, all versioned, all auditable. The number in your HubSpot dashboard traces back to inspectable logic in a version-controlled data model.

That capability matters because the most common RevOps problems are not HubSpot problems. They are data problems that surface through HubSpot. When the data problem lives upstream of the CRM, fixing it inside the CRM is the wrong place to fix it.

We also do not make the same operator hand you off to a junior executor after the sales call. The person who designed the architecture is the person doing the build.

How we work

Six principles govern every phase below. They are not aspirations. They are the rules the work is built to satisfy.

• Definitions before dashboards. A metric gets a single governed definition before it gets a chart.
• Baselines before optimizing. We measure the starting point before we move it, so improvement is provable.
• Revenue leaks are quantified in dollars. Every gap carries a number, not an adjective.
• The operating cadence is non-negotiable. Weekly, monthly, and quarterly reviews run on schedule, every cycle.
• Alerts and automation replace manual checking. The system watches the data so your team does not have to.
• Nothing ships without a measurable output. Every deliverable is something you can inspect and verify.

Deliverables

This is what ships, organized by the four engagement phases and the embedded retainer cadence. Scope is set per engagement, but the framework is fixed: every item here is a concrete artifact you can inspect.

Phase 1

Audit

We inspect the foundation and quantify what is broken before anyone touches a build.

• RevOps charter that fixes scope, owners, and success criteria up front.
• Full CRM property audit, with every property classified Required, Recommended, or Deprecated.
• Integration health map covering every connected system and the direction each data flow runs.
• Field-completeness baseline measured against a 95%+ target.
• Duplicate-rate assessment measured against an under-5% target.
• RevOps maturity scorecard that places your operation on a defined scale.
• Revenue-leak scorecard with every gap quantified in dollars.

Phase 2

Architecture

We define the system in writing so every later build decision is checked against one agreed reference.

• Written lifecycle-stage definitions, each with explicit exit criteria.
• One-sentence MQL, SQL, and SAL definitions paired with handoff SLAs.
• Lead-routing rules that send every record to the right owner without a manual step.
• A lead-scoring model built on Fit x Engagement, with a plain-language score-explanation doc reps can actually read.
• Reporting architecture with governed metric definitions, so a number means one thing everywhere.
• Change-control and data-governance plan that keeps the architecture from drifting after handoff.

Phase 3

Build

We execute the architecture: automation, dashboards, core reports, and the warehouse layer.

• Automated deduplication and merge plus email validation running on a schedule.
• Deal-hygiene guardrails: required fields, no blank next step, and stale-deal alerts.
• SLA-breach, churn-risk, renewal, and expansion automations that fire before a human would notice.
• Persona dashboards for the CEO, CRO, VP Marketing, VP Sales, VP Customer Success, and each rep.
• Core reports: MQL-to-Won waterfall, multi-model attribution, pipeline coverage, and forecast delta.
• Warehouse integration: ETL in, dbt models, and reverse-ETL writing scores back into HubSpot.

Phase 4

Embedded retainer cadence

The retainer runs a fixed operating cadence. Each cycle produces the same reviews so drift is caught early and the system stays honest.

Weekly

• Pipeline snapshot
• Forecast delta
• Deal-movement review
• Speed-to-lead check
• Zero unassigned leads, verified

Monthly

• Waterfall and stage conversions
• Attribution summary
• Rep productivity review
• Data-quality score
• Revenue-leak scorecard
• Experiment review

Quarterly

• QBR decks per GTM function
• Win/loss deep-dive
• NRR walkthrough
• Tech-stack consolidation
• Capacity and territory review

Take the framework with you

Download the capabilities one-pager (PDF) for the full engagement model, phases, deliverables, and cadence in a single printable page.

Where to go next

See the engagement tiers and fixed-scope audit on the plans page, start with a Data Foundation Audit, or read the field notes on the method.