The four problems RevOps in HubSpot is meant to solve.
Every RevOps engagement we run starts from one or more of these four problems. Naming them up front keeps the build focused.
The first problem 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 problem 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 MQL handoff is broken at the property level, the routing level, or both.
The third problem is the attribution problem. A customer signed last month. 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 problem is the reporting problem. Each Hub produces its own dashboards. The CEO dashboard pulls from one, the board pack pulls from another, the weekly leadership review pulls from a third. 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 layer has a clear ownership rule. We build them bottom-up.
Layer one is the object model. Contacts, Companies, Deals, Tickets, plus the Custom Objects that map to your business. The object model 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.
Reporting that writes back into properties destroys data integrity inside two quarters.
One workflow owns each tracked property. Build routing first, then stage, then notifications.
Two teams writing the same field is the most common cause of cross-Hub contradiction.
Companies are the unit of revenue. Contacts are the unit of relationship.
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 with 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 architectural rules sit on this layer. The first is that Companies are the unit of revenue. We report revenue at the Company level, not the Deal level. Deals are events. Companies are accounts. The second is that the Contact is the unit of relationship. We 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 property set is reasonable on day one. By month twelve, every team has added their own properties, the marketing team has 60 fields nobody uses, and the deal record has fields that contradict the contact record.
The property model is built from a single inventory document. The inventory 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. They 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. They 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. They are the primary reporting inputs.
For each category we apply 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, 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, a portfolio audit is the right first step.
- Owner, persona, industry, lifecycle stage, deal type
- Primary segmentation and routing inputs
- Single owner team per property
- Lead Status, Deal Stage, Ticket Status, Subscription Status
- Primary automation triggers
- Picklist values locked, changes require a workflow review
- Closed Won Date, Customer Onboarded Date, Churned Date, Lost Reason
- Primary reporting inputs
- Never overwritten after the first write
Layer three: the automation model.
Workflows in HubSpot are powerful. Power without architecture creates the workflow tangle, the state where 200 active workflows write to overlapping fields, and nobody on the team can predict what will happen when a contact fills 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. The workflow has a single trigger condition and a single property write.
Notification workflows
Tell humans something happened. Slack notification on MQL creation, email notification on deal stage advance, task notification on ticket assignment. Notification workflows read from properties, 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 because they are the lightest layer and 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 the lifecycle thrashing problem.
- 1Routing workflowsDecide who owns a record. Assign Owner by territory, persona, segment or score. Write the Owner property and stop. Build first because every other workflow assumes Owner is set.
- 2Stage workflowsMove records forward. One workflow per stage transition, one trigger condition, one property write. Build second because reports filter on stage.
- 3Notification workflowsTell humans something happened. Read from properties, never write to them. Build last, the lightest layer and easiest to change.
Layer four: the reporting model.
Reporting is the layer leadership sees, so it is the layer that gets debated. The architecture rule is that reports do not write back into the system. Anything else is open.
We ship every RevOps build 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. The leadership dashboard is the only one the CEO and the board look at. Everything else funnels into this view.
The funnel dashboard
Volume and conversion rate at each stage from Lead through Customer. Filterable by source, segment, owner and time period. The funnel dashboard 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. 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. Architecture-wise, they connect through three integration points.
The first integration point 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 integration point 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 the rules above are enforced.
The third integration point 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 up to the company. Service pushes Tickets Open, Last Ticket Date, and CSAT up to the company. 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. Explains the object model, the property categories, the workflow rules, and the reporting principles. Lives in the company wiki. Reviewed at the quarterly business review.
The property inventory
A spreadsheet or HubSpot-native asset. One row per property, with object, owner team, allowed values, writing workflow, and reading reports. The inventory is the source of truth for property changes. Adding a new property requires an inventory entry.
The workflow runbook
One row per workflow, with 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. No legacy decay to unwind, but the same four layers still need to be built in order.
We ship 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 post-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 are reading from the same property layer with the same definitions. Cross-team meetings stop with the words "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.
Internal links.
Coming soon
HubSpot deal pipeline best practices
Coming soon
HubSpot lifecycle stages best practices
Coming soon
HubSpot reporting that holds up under leadership scrutiny
We ship a property inventory and workflow runbook template with every engagement.
Design your RevOps architecture
If your portal has been live for more than six months and reports are starting to contradict each other, book a discovery call. We run a free thirty-minute architecture audit and tell you which of the four problems above is hiding in your data, and which layer the fix has to start at.
Book a free consultCommon questions.
What is HubSpot RevOps architecture?
HubSpot RevOps architecture is a four-layer system that unifies Sales Hub, Marketing Hub and Service Hub. The four layers are a shared object model, a single-owner property layer, structured workflow categories, and read-only reporting dashboards. The result is one source of truth across all three Hubs, with no cross-team reporting contradictions.
How long does a HubSpot RevOps architecture build take?
A full build on a portal with existing data takes two to three weeks. Week one covers the audit and the architecture document. Week two covers property cleanup and workflow consolidation. Week three covers the dashboard rebuild and team training. A greenfield portal with no legacy data takes one to two weeks.
Why do HubSpot reports contradict each other across teams?
The most common cause is three teams using three different property definitions for the same concept: Lead, Customer, or MQL. Each Hub produces correct numbers inside its own context, but the definitions do not align at the system level. The fix is a single property layer with one owner team per property and one workflow that writes to each tracked field.