The records the go-to-market runs on, how they relate, and which system owns each one. Every metric on the Metrics page is a query over these objects.

GTM Operating Model › Revenue Operations › Data model
Data model
The records the go-to-market runs on and how they relate. Every report on this site is a query over these objects; the color says which system is the system of record (the one place a record is created and edited).
SYSTEM OF RECORD
CRM
Billing · mirrored to the CRM
Warehouse · assembled from other systems
↗ opens a page
Campaign
a program the company spends on: event, ad, webinar, partner program
Campaign member
one touch: a person's response to a campaign, with date and status
Lead
a person not yet tied to an account; becomes a Contact at match or gate
↗
Partner account
an account of type partner; tier and agreement terms
Account
the company; parent-child hierarchy; owner, segment, lifecycle state
Contact
a person at an account; role in the buying group; added by research or converted from a lead
Deal registration
the partner's claim on a deal: status, date, protection window
↗
Opportunity
created at the SQL gate. Type: new business, expansion or renewal. Amount, close date, owner, stage, forecast category, sourced channel
↗
Quote
priced offer and terms; one marked primary; becomes the contract
Subscription
products, term and ARR (annual recurring revenue) on the account
↗
Opportunity line
product, quantity, price and discount from the price book
User
role, manager, segment; owns territories, accounts and opportunities
Territory
the accounts one AE owns, by segment, region or named list
↗
Stage history
system-written; one row per stage change, never overwritten
↗
Touchpoint
assembled from campaign members and activity; one row per credited touch
↗
owner · RevOps owns the object model, field rules and required fields; each system's administrator maintains its own objects; Finance owns billing data.
FIELD OWNERSHIP
Lifecycle state
marketing automation writes it until the gate, the CRM after; held on the Account as well as the Contact for account-based reporting
Amount and close date
set by the rep and validated at each stage exit; changes are kept in history, never overwritten
ARR
written only by billing and mirrored to the Account and Subscription in the CRM; no one edits it in the CRM
Health score and usage
from the CS platform and product data, synced to the Account; read by Customer Success and the renewal forecast
Sourced channel
stamped on the opportunity at the gate and locked; influence is measured separately through touchpoints
Rules: accounts are loaded from the target-account list, created when a lead, signup or deal registration matches no existing account, or set up when a partner signs; reps do not create them freely. One system owns each field and every other system reads it. History tables (stage history, field history, ARR snapshots) are append-only. Nothing is deleted: duplicates are merged and the merge is logged. Where companies differ: some skip the Lead object and keep lifecycle state on Contact and Account from the first touch; the gate and the definitions stay the same.
has many
has many
has many
converts to
no match:
created at
the gate
has many
has many
has many
approved: links to one
has many; one primary
closed-won:
creates, updates
renewal opens at
term minus 120 days
has many
has many
has many
has many
owns

Boxes marked ↗ open the page for that part of the model.

How to read this

  • The account is the spine. Contacts, opportunities and territory ownership all hang off it, which is why ownership and lifecycle state are held at the account level.
  • Accounts come from two places: the target-account list RevOps loads so territories can be carved, and the match check every lead, signup and deal registration runs. A new company gets an account only when nothing matches, which is what keeps duplicates out.
  • The opportunity is the only object that crosses from acquire to revenue: it is created at the gate, closed-won creates or updates the subscription, and the subscription opens the next renewal opportunity.
  • Two objects are never edited by hand. Stage history is written by the system on every change, and touchpoints are assembled in the warehouse; that is what makes conversion, cycle time and attribution reproducible.
  • One system owns each field and everything else reads it. Most data-quality problems are two systems writing the same field.

Where it connects

Diagram source: 17-data-model.drawio 17-data-model.svg