Systems · 9 min read
The GTM data model every revenue team needs
Your CRM is not a spreadsheet with more fields. It is the shared model that decides who gets contacted, what gets attributed, and whether the team trusts the numbers.
Start with the decisions the business needs to make. Then create the smallest set of records and rules that can support them reliably.
Why most GTM data becomes hard to use
Teams usually add fields in response to a request: a new campaign, a new dashboard, a new enrichment provider. Over time, definitions drift. “Qualified” means one thing to sales and another to marketing. A company is duplicated under three domains. An opportunity has activity but no accountable owner.
A data model is how you prevent that drift. It defines the important objects, their relationships, and the rules for changing them.
The five records to get right
| Record | What it represents | Non-negotiable fields |
|---|---|---|
| Account | The company or buying entity. | Canonical domain, segment, lifecycle stage, owner, fit status. |
| Person | A contact who can influence or make a decision. | Account link, role, seniority, email status, consent or suppression status. |
| Opportunity | A commercial process with a defined potential outcome. | Account, amount, stage, close date, owner, source. |
| Activity | A meaningful interaction or execution event. | Timestamp, actor, channel, account/person link, outcome. |
| Signal | Evidence that changes priority or relevance. | Type, source, date, confidence, relevance reason, review state. |
Design around decisions, not dashboards
Before creating a field, write the decision it will support. If no one can name the decision, the field is probably noise.
| Decision | Data required | Rule to document |
|---|---|---|
| Should this account enter outbound? | Fit, suppression state, signal, owner. | Eligibility and exclusion logic. |
| Who should receive this inbound lead? | Territory, segment, product interest, capacity. | Routing precedence and fallback owner. |
| Did marketing create pipeline? | Campaign touchpoints, opportunity dates, source model. | Attribution window and model. |
| Can we trust this forecast? | Stage, amount, close date, next step, activity. | Stage-entry and exit criteria. |
Use a field contract
Every important field needs an owner and a contract. This is unglamorous work, but it saves more time than another dashboard ever will.
- Definition: What exactly does this field mean?
- System of record: Where is it created and corrected?
- Allowed values: What can be written here?
- Update rule: Who or what may change it?
- Downstream use: Which routing, reporting, or automation relies on it?
Four implementation rules
- Make the company domain canonical.
Use a normalised domain as the primary identity key wherever possible. Names change; domains are usually a more stable join point.
- Keep lifecycle stages separate from sales stages.
Lifecycle describes the relationship with the business. Sales stage describes the progress of an opportunity. Mixing them makes both reporting and routing unreliable.
- Store evidence beside derived values.
If a model says an account is high intent, retain the source, date, and reason. A score without evidence is hard to trust and impossible to debug.
- Record changes that affect the business.
Owner changes, stage changes, suppression updates, and qualification decisions should leave an audit trail.
Start smaller than you think
You do not need a perfect enterprise schema before you can improve the system. Start with one motion—such as routing inbound demos or prioritising outbound accounts—and define the records, fields, and rules it requires. Once the team can trust that motion, extend the model deliberately.