The HubSpot RevOps architecture: Sales, Marketing and Service Hub working as one system

The four problems RevOps is meant to solve

Every RevOps engagement we run starts from one or more of four problems. Naming them up front keeps the build focused.

The first is the contradiction problem. Marketing reports show 1,200 leads last quarter. Sales reports show 480 opportunities. Finance reports show 180 customers. The numbers do not reconcile because the three teams are filtering on three different definitions of the same thing.

The second is the handoff problem. Marketing flips a Lead to MQL. Sales never sees it, or sees it three days late, or sees it but cannot tell why it was flipped. The handoff is broken at the property level, the routing level, or both.

The third is the attribution problem. A customer signed last month and the CRO cannot trace which campaign, channel or rep moved them through the funnel. Attribution lives in three different places and rolls up nowhere.

The fourth is the reporting problem. Each Hub produces its own dashboards: one for the CEO dashboard, one for the board pack, one for the weekly leadership review. The numbers are correct in each context and inconsistent across contexts.

A real RevOps build solves all four at once. Solving any one in isolation creates a new contradiction with the others.

The architecture in four layers

The architecture has four layers, each with a clear ownership rule. We build them bottom-up.

Layer one is the object model: Contacts, Companies, Deals, Tickets, plus the Custom Objectsthat map to the business. It is the foundation. Every property and every workflow assumes the object model is locked.

Layer two is the property layer. Each property has a single owner team, a single source of truth and a documented update path. Properties drive automation, segmentation and reporting.

Layer three is the automation layer: workflows that move properties forward, route contacts and deals, and trigger team actions. The automation layer reads from the property layer and writes back to it. Nothing else writes directly to a tracked property.

Layer four is the reporting layer: dashboards, reports and the metrics that drive leadership decisions. The reporting layer reads only. It never writes back into the system.

Inverting any of these layers breaks the system. Reporting that writes back into properties, a common temptation, destroys data integrity inside two quarters.

Layer one: the object model

The object model is fixed by the buying motion, not by HubSpot’s defaults. We start by mapping the customer journey on a whiteboard, then build the object model to match.

For most B2B SaaS clients we ship the standard four objects plus one or two Custom Objects. Companies are always parent. Contacts always link to a Company. Deals link to both a Company (primary) and Contacts (associated). Tickets link to a Company and an originating Contact.

The Custom Objects we add most often are Subscriptions for self-serve revenue, Projects for delivery-heavy clients, and Properties for clients in real estate or asset management. Custom Objects exist when the data has a lifecycle of its own that does not fit Deal or Contact.

Two rules sit on this layer. Companies are the unit of revenue: report revenue at the Company level, not the Deal level, because Deals are events and Companies are accounts. The Contact is the unit of relationship: track touch frequency, last activity and engagement at the Contact level.

Get the object model wrong and every layer above it has to compensate.

Layer two: the property model

Properties are where most HubSpot portals decay. The default set is reasonable on day one. By month twelve, every team has added its own properties, marketing has 60 fields nobody uses, and the deal record contradicts the contact record.

The property model is built from a single inventory document. It lists every property with its object, owner team, allowed values, and the workflows and reports that touch it. Properties without an entry in the inventory get archived.

Three property categories matter most for cross-Hub work.

Identity properties

These describe who the contact, company or deal is: owner, persona, industry, lifecycle stage, deal type. They change rarely and are the primary segmentation and routing inputs.

State properties

These describe what stage of a process the record is in: Lead Status, Deal Stage, Ticket Status, Subscription Status. They change often and are the primary automation triggers.

Outcome properties

These describe what happened: Closed Won Date, Customer Onboarded Date, First Renewal Date, Churned Date, Lost Reason. They are written once and read forever, and are the primary reporting inputs.

Each category follows the same rule: single owner team, single source of truth, documented update path. Two teams writing to the same property is the most common cause of cross-Hub contradiction.

We also lock the picklist properties. Lifecycle Stage, Deal Stage, Lead Status and Ticket Status all have fixed value sets. Adding a value requires a change request and a workflow review. Without that gate, the picklist sprawl returns inside two quarters.

If your property layer is already showing decay symptoms, speak to the team and we will tell you where to start.

Layer three: the automation model

Workflows in HubSpot are powerful. Power without architecture creates the workflow tangle: 200 active workflows writing to overlapping fields, and nobody on the team able to predict what happens when a contact fills in a form.

The automation model has three workflow categories. We build them in this order.

Routing workflows

Decide who owns a record. Lead routing assigns Owner based on territory, persona, segment or score. Deal routing assigns Owner based on deal type and value. Ticket routing assigns Owner based on issue type and customer tier. Routing workflows write the Owner property and stop.

Stage workflows

Move records forward: lifecycle stage promotion, deal stage advancement, ticket stage progression. Each stage transition is owned by one workflow, with a single trigger condition and a single property write.

Notification workflows

Tell humans something happened: a Slack notification on MQL creation, an email on deal stage advance, a task on ticket assignment. Notification workflows read from properties and never write to them.

The order matters. Build routing first because every other workflow assumes the Owner is set. Build stage second because reports filter on stage. Build notifications last, the lightest layer and the easiest to change.

We also enforce the one-property, one-workflow rule. Each tracked property has exactly one workflow that writes to it. If two business rules need to write the same property, they consolidate into a single workflow with branched logic. Multiple workflows writing the same field is the root cause of lifecycle thrashing.

Layer four: the reporting model

Reporting is the layer leadership sees, so it is the layer that gets debated. The rule is that reports do not write back into the system. Everything else is open.

Every RevOps build ships with three dashboards as the starting set.

The leadership dashboard

Five metrics, one screen: pipeline coverage, weighted forecast, customer count, churn rate, ARR or MRR. This is the only dashboard the CEO and the board look at. Everything else funnels into it.

The funnel dashboard

Volume and conversion rate at each stage from Lead through Customer, filterable by source, segment, owner and time period. It tells marketing and sales whether the engine is healthy.

The retention dashboard

Customer health, renewal pipeline, churn signals, expansion signals, NPS. Service-led businesses live or die by this dashboard, and sales-led businesses still need it to forecast renewals.

We do not start with twenty dashboards: three dashboards, eight or nine reports total, and we add the next report only when a real question cannot be answered with what is there. Dashboard sprawl is the second most common cause of leadership distrust in the data, after property thrashing.

How the three Hubs connect

Sales Hub, Marketing Hub and Service Hub each contribute to all four layers. They connect through three integration points.

The first is the Contact record. Marketing fills it with engagement data: page views, form fills, email opens. Sales fills it with relationship data: calls, meetings, notes. Service fills it with support data: tickets, NPS, feature requests. All three teams read all three streams. None of them owns the Contact outright: the Owner property assigns the relationship lead, but the data belongs to the system.

The second is the Lifecycle Stage. Marketing owns Lead and MQL. Sales owns SQL and Opportunity. Customer is set by deal automation. Service owns Evangelist, set after a referral or case study. The Lifecycle property is the cleanest cross-Hub handshake in the platform when these rules are enforced.

The third is the Company-level rollup. Companies are the unit of revenue, so Companies inherit signal from all three Hubs. Marketing pushes Engagement Score up to the company. Sales pushes Pipeline Value and Last Activity. Service pushes Tickets Open, Last Ticket Date and CSAT. The Company record is the cross-Hub view leadership wants.

These three integration points are why a unified system works. Skip any of them and you are back to three silos sharing a database.

What you ship to the team

A real RevOps build needs three artefacts the team can use after we leave.

The architecture document

One page per layer, covering the object model, the property categories, the workflow rules and the reporting principles. It lives in the company wiki and is reviewed at the quarterly business review.

The property inventory

A spreadsheet or HubSpot-native asset with one row per property: object, owner team, allowed values, writing workflow and reading reports. It is the source of truth for property changes. Adding a new property requires an inventory entry.

The workflow runbook

One row per workflow: trigger, action, the property it writes, and the report it feeds. Workflows without a runbook entry get archived. The runbook is reviewed monthly for the first six months and quarterly afterwards.

These three artefacts are how the build survives. Without them, decay is inevitable.

How long this takes

A full RevOps architecture build for a portal with existing data takes two to three weeks of focused work. Week one is the audit and the architecture document. Week two is the property cleanup and the workflow consolidation. Week three is the dashboard rebuild and the team training.

A greenfield build for a new portal takes one to two weeks. There is no legacy decay to unwind, but the same four layers still have to be built in order.

We ship it as a fixed-scope engagement. The deliverables are the architecture document, the property inventory, the workflow runbook, the three dashboards, and a recorded handover walkthrough.

What changes after the build

Three things change for the team in the first quarter after the build.

Reports stop contradicting each other. The leadership dashboard, the funnel dashboard and the retention dashboard show the same numbers as the underlying reports, because they read from the same property layer with the same definitions. Cross-team meetings stop ending with "well, my number says".

The MQL handoff stops being a complaint. Sales sees MQLs in real time, with the criteria that triggered the flag visible on the contact record. Marketing knows which MQLs converted and which did not, by month, by source and by score band.

Attribution becomes traceable. Every closed-won deal can be walked backwards from Customer through Opportunity, SQL, MQL and Lead. The original source, the campaigns that touched the contact, and the rep who progressed the deal are all on one record.

The team does not get faster overnight. The system gets honest overnight. Speed follows once people trust the data.

Common questions