Build the Osmosis Protocol in HubSpot: The Ops Guide
The RevOps build guide for the Osmosis Protocol — property specs, validation rules, workflow logic, and Breeze AI prompts that make market intelligence self-maintaining.
The Build Guide: How to Make the Osmosis Protocol Self-Maintaining in HubSpot
You didn't design the CRM architecture that's currently running. You inherited it — the fields added by a previous admin solving a problem that no longer exists, the workflow that fires on a condition nobody can trace back to a decision, the reports that leadership reads every Monday built on a Lead Source field that hasn't been populated correctly in eight months.
The Osmosis Protocol is a market intelligence framework. Your job is to make it run as a governed CRM system — not as a set of good intentions that depends on rep compliance to function. This is the build guide.
Every phase of the Osmosis Protocol has a CRM configuration requirement. Some of those requirements are property builds. Some are validation rules. Some are automation logic. Some are Breeze AI prompts that replace what would have been a manual intelligence cycle. None of them are optional if the system is going to self-maintain past the first quarter.
To be fair: the case for building the minimum viable version first is real. Getting something deployed and iterating is better than designing the perfect system that never ships. A required field and a pinned note template can carry the first quarter. That's true. But a system built on required fields and manual effort has a ceiling — and that ceiling is exactly the point where your busiest quarter coincides with the highest rep turnover you've had in two years. Build the governance layer now, before the first exception becomes the standard.
Build Component | Object | Priority | Estimated Build Time |
|---|---|---|---|
ICP Fit Score property + portfolio segment property | Company | P1 — Phase 1 foundation | 30 min |
Intelligence Variable properties (4-6 custom fields) | Company + Contact | P1 — Phase 2 foundation | 45 min |
Talk track pinned note template | Deal | P1 — Phase 3 foundation | 20 min |
Success Brief required property + Closed-Won validation | Deal | P1 — Phase 4 handoff gate | 60 min |
Breeze AI prompt library (3 prompts) | Deal + Company | P2 — Phase 4 intelligence layer | 90 min |
Portfolio view (Active Customers by Segment) | Company | P2 — ongoing governance | 20 min |
Renewal risk workflow (adverse variable trigger) | Company + Contact | P3 — Phase 2 automation | 60 min |
1. Phase 1 Build: Portfolio Cartography Properties
The Segmented Risk Portfolio cannot exist as a governance document if the underlying data doesn't live in structured CRM properties. A pinned note is not a queryable field. A rep's mental model of account risk is not a reportable segment. If the portfolio classification doesn't exist as a Company property with a defined value set, it cannot drive a view, trigger a workflow, or feed a Breeze AI prompt.
Two properties power the Portfolio Cartography phase. Both belong on the Company object. Both require a defined value set — not a free text field, a defined picklist that enforces classification rather than describing it.
Property | Object | Field Type | Value Set | Governance Rule |
|---|---|---|---|---|
ICP Fit Score | Company | Dropdown select | 1 — Low fit / 2 — Moderate fit / 3 — High fit | Required field for all Company records in target verticals — validated quarterly |
Portfolio Segment | Company | Dropdown select | Defended / Concentration Risk / Commodity Exposure / Expansion Candidate | Populated after ICP Fit Score and ARR are both confirmed — not before |
The Portfolio Segment property is a derived classification, not a rep-entered field. The rule: if ARR is above the concentration threshold AND ICP Fit Score is 3, the segment is Defended. If ARR is high AND ICP Fit Score is 1 or 2, the segment is Concentration Risk. Build this as an if/then workflow that populates Portfolio Segment automatically when both source properties are set.
In HubSpot: Properties → Company → Create property → Dropdown select. Workflow: Company-based → Enrollment trigger: ICP Fit Score is known AND ARR is known → Set Portfolio Segment per the decision logic above.
2. Phase 2 Build: Intelligence Variable Properties
The Intelligence Variable Registry defines which external market signals matter for the ICP. The CRM build makes those signals persistent, queryable, and actionable. A signal that lives in a rep's call notes is not governed intelligence — it's institutional knowledge that leaves the building on the rep's last day.
Four to six custom properties on the Company object. Field type depends on the variable: numeric for quantitative signals, date for timing data, single-line text for qualitative observations. Every property needs a defined update cadence — quarterly at minimum, triggered by material market events when they occur.
Property Name | Object | Field Type | Example Value | Update Cadence |
|---|---|---|---|---|
Primary Market Variable 1 | Company | Single-line text or Numeric | "Port clearance lead time: 18 days" | Quarterly + event-triggered |
Primary Market Variable 2 | Company | Single-line text or Numeric | "Commodity price index: +12% QoQ" | Quarterly + event-triggered |
Variable Last Updated | Company | Date | [date of last variable review] | Auto-populated by workflow on any variable property change |
Variable Registry Status | Company | Dropdown select | Current / Needs Review / Stale | Workflow: set to Stale if Variable Last Updated > 90 days |
The Variable Registry Status property is your governance lever. A workflow fires every 90 days to check Variable Last Updated against the current date. Any Company where the gap exceeds 90 days gets Variable Registry Status set to Stale and a task created for the account owner to update. In HubSpot: Company-based workflow → Enrollment: Variable Last Updated is more than 90 days ago → Set Variable Registry Status to Stale → Create task: "Intelligence variable review required."
RED FLAG |
|---|
If your Intelligence Variable properties are free text fields without a defined update workflow, you haven't built a registry — you've built a notes field with a better label. Free text fields cannot trigger workflows, cannot be filtered in views, and cannot feed Breeze AI prompts with structured inputs. Build the field types correctly before populating them. |
3. Phase 3 Build: Talk Track Template and Messaging Governance
The Cross-Departmental Messaging Matrix produces the language layer. The CRM build makes that language layer persistent and accessible at the moment it's needed — when a rep is about to open a call, when a CS manager is preparing for a renewal conversation, when a Marketing ops manager is building a campaign audience.
Two build components for Phase 3. First: a standardized pinned note template on the Deal record that carries the market-aware talk track for each active opportunity. Second: a required property on the Deal record that confirms a talk track exists before the Deal advances past a defined stage.
Build Component | Object | What It Does | HubSpot Configuration |
|---|---|---|---|
Talk Track pinned note template | Deal | Carries the market-aware opening, key variable observations, and objection handling language for this specific account | Create a Note template in HubSpot: Settings → CRM → Templates → Note. Structure: Market Context / Talk Track Opening / Key Variables / Objection Handling |
Talk Track Populated property | Deal | Required boolean confirming a talk track exists before Deal advances past Stage 2 | Deal property: Talk Track Populated (checkbox). Validation rule: Deal cannot advance from Stage 2 without Talk Track Populated = true |
The validation rule is the governance layer. Without it, the talk track is optional. With it, the talk track is a stage gate — which is exactly what it needs to be if the messaging matrix is going to function as an operational standard rather than a recommendation.
In HubSpot: Deal properties → Create property → Checkbox → "Talk Track Populated." Pipeline editor → Stage 2 → Deal requirements → Required properties before advancing: Talk Track Populated.
4. Phase 4 Build: Enrichment Engine and Breeze AI Prompt Library
The Enrichment Engine is the build that makes the entire system self-maintaining. Without it, the Intelligence Variable Registry requires manual quarterly updates, the talk tracks require manual refreshes, and the portfolio classification requires a human to run the cartography exercise each time. With it, the system maintains itself — Breeze AI interprets enriched property data and writes plain-language intelligence summaries to Deal records without requiring a manual analysis cycle.
Two implementation paths. Build both if your org has the infrastructure for Scenario A. Build Scenario B regardless — Breeze credits are already purchased and the three prompts below require no integration.
Scenario A — External enrichment integration:
If your org uses Freckle.io for physical goods market data, or Clay for larger audience enrichment and sequencing, the integration path is: external tool → CRM property update via native integration or Zapier → Breeze AI interprets updated properties → Breeze writes intelligence summary to Deal record.
Integration Step | Tool | Action | Output |
|---|---|---|---|
External data ingestion | Freckle.io or Clay | Configure data feed to push variable updates to mapped Company properties | Company properties updated with current market variable state |
Property mapping | HubSpot integration settings | Map external data fields to Intelligence Variable properties built in Phase 2 | Variable properties current without manual update |
Breeze AI interpretation | HubSpot Breeze | Prompt fires against updated Company properties → writes to Deal record | Plain-language intelligence summary on Deal record |
Governance review | Operator | Quarterly review of Breeze output accuracy against known account context | Prompt updated when variable set changes or output accuracy degrades |
Scenario B — Breeze AI prompt library (no external integration required):
These three prompts run against existing CRM data. Adapt field names to match your specific property schema before deploying at scale. Run each prompt against your three highest-priority accounts before deploying across the full base — validate that the output surfaces something the account owner didn't already know.
IMPLEMENTATION |
|---|
Breeze Prompt 1 — Deal Intelligence Summary "Review the activity timeline, contact properties, and Intelligence Variable properties for this deal. Identify the last meaningful buyer signal, note any Intelligence Variable that has moved adversely in the last 90 days, and write a three-sentence summary of the most important considerations for the next conversation." Breeze Prompt 2 — Account Segment Validation "Based on the ICP Fit Score, ARR, and Portfolio Segment properties for this company, validate whether the current segment classification is accurate given the current Intelligence Variable state. Flag any discrepancy and recommend a segment update if warranted." Breeze Prompt 3 — Renewal Risk Assessment "Review this account's Case history, Activity frequency, Variable Registry Status, and last engagement date. Identify the three signals most predictive of renewal risk and recommend the specific proactive outreach trigger for the CS team to use before the renewal window opens." Deploy these against your highest-priority accounts first. Validate output quality before scaling. Update field references to match your specific property names. |
PRO TIP |
|---|
The fastest governance validation for any Breeze prompt is to run it against an account you know well — one where you already have a clear picture of the renewal risk or deal status. If the output matches what you know, the prompt is structurally sound. If it misses something obvious, the prompt is missing a field reference. Fix the field reference before deploying at scale. |
Your Monthly Build Cadence — Q[X] Ops Playbook
Run this cadence monthly. Each row closes before the next month opens.
Month | Focus | One Build to Complete |
|---|---|---|
Month 1 | Phase 1 and Phase 2 property builds — ICP Fit Score, Portfolio Segment, Intelligence Variables | All Company properties live, Portfolio Segment workflow active, Variable Registry Status workflow active |
Month 2 | Phase 3 governance builds — Talk Track template, Talk Track Populated validation rule | Note template created, Deal stage validation rule enforced, first talk tracks populated on active Deals |
Month 3 | Phase 4 Enrichment Engine — Breeze prompt library deployed and validated | All three Breeze prompts tested against priority accounts, output quality confirmed, scaling approved |
Month 4 | System governance audit — Variable Registry Status review, Breeze output accuracy check, portfolio segment recalibration | Stale variable flags resolved, Breeze prompts updated if variable set has changed, Portfolio Segment classifications reviewed |
A CRM that enforces the Osmosis Protocol through validation rules, workflow automation, and governed Breeze AI prompts is not a database that depends on rep compliance — it is a self-maintaining revenue intelligence system. Every field that stays clean, every talk track that travels with the Deal record, every Breeze summary that reaches the account owner before the call compounds into a forecasting layer that the organization can actually trust. Build the governance layer before the first exception gets logged as a workaround.
The full CRM configuration spec and build checklist for the Osmosis Protocol are in The Intel Operator™ newsletter. Subscribe at theinteloperator.com/subscribe
