The GTM Data Model in Your CRM

In a pipeline review last year a VP asked what should have been a lookup: which products are attached to the deals in the open forecast. There is a field for exactly that, All Products, sitting right on the opportunity. I did not trust it, so before the meeting I checked it against its own inputs. It was correct on 742 of 23,148 opportunities. Three point two percent. The field built to answer the question was wrong ninety-seven times out of a hundred, and every report that grouped pipeline by product had been quietly lying for as long as anyone could remember.

It was not really a broken flow. It was a broken data model. All Products was supposed to be the deduplicated union of two other product fields. An after-save flow was meant to keep it current, but its entry condition checked whether the source fields had changed, and a field does not “change” on the insert that creates a record, so the automation never ran when a deal was born. Zero of the 742 correct records were unedited after creation. The field was right only by the accident of a later manual save.

In the Bowtie chapter we drew the whole customer lifecycle as one tool-agnostic shape. In the last chapter we ran the right side of it, customer success as retention and expansion, on health scores, renewal dates, and expansion signals. Every one of those is a field on an object, and it is only worth trusting if the model underneath holds. This module is where the Bowtie stops being a diagram and becomes objects, fields, matching rules, and a contract. This chapter builds the model in the CRM.

From a shape to an object graph

The Bowtie is tool-agnostic on purpose. Your CRM is not. Salesforce, or whatever you run, ships an opinionated object graph: Lead, Contact, Account, Opportunity, and usually a separate world for everything post-sale. The job here is to map the eight Bowtie sub-systems onto those objects without losing the property that made the Bowtie valuable, which is that it treats the entire lifecycle as one connected customer.

Read the map and one object does the connecting: the Account. The left side lands leads and opportunities. The knot converts a win count into ARR, VM6 = VM5 × ACV, the seam we drew in the Bowtie chapter. The right side hangs onboarding, renewal, and expansion off the same account the deal closed against. Marketing’s lead, the AE’s opportunity, the CSM’s renewal, and finance’s ARR rollup are the same real-world company, or they are not one customer at all. That is why the least glamorous object in the graph, the Account, is the spine of the whole model, and why account identity is the first thing that has to be right.

Field standards: one field, one definition, one write path

Every field on the model needs four things: an owner, a definition, a source of truth, and, where its values are finite, a governed picklist. Skip any one of them and the field drifts.

All Products is the cautionary tale, and its fix is the standard. We rebuilt it as a before-save flow that recomputes from scratch on every create and every update, so a removed product propagates and a blank record heals itself on the next edit. It could not be a formula, because Salesforce refuses picklist fields in flow formulas and will not concatenate a multi-select at all, so the dedup compares semicolon-wrapped tokens (;VALUE; inside ;LIST;) instead of a naive contains that would match Anaconda v4 inside Anaconda v4/v5. A guard leaves 1,378 records holding retired picklist values untouched, because a live recompute would otherwise make those records unsaveable on any edit. The result: 21,061 opportunities corrected, the rest deliberately left alone, and a field that now stays right because it is derived live from its sources rather than stamped once and abandoned.

Matching: you cannot model a customer you cannot identify

If the Account is the spine, matching is what keeps the spine from splitting. Matching rules are how you decide that two rows describe the same real-world entity, and getting them wrong is expensive in three directions at once. A duplicate account routes the inbound lead to the wrong owner, splits one customer’s ARR across two rollups, and hands the CSM half a history.

We put this to the test on the full book: roughly 160,000 accounts, scored 0 to 100 with a rubric that weights Validity 35, Engagement 25, Completeness 20, Uniqueness 10, and Freshness 10, each score carrying an action from keep to enrich to merge to archive. The validity checks alone (is the domain live, is it a parked page, does the company name match the website) catch most of the junk before a human ever looks. The rubric is worth internalizing even if you never run the audit, because it names the four questions any match key has to answer before it can trust that two rows are, or are not, the same customer.

Identity does not stop at the account. It runs down to the contact, because routing a person and matching a buyer both need a real name. One pass over the corporate book found that 75% of contacts had a junk or missing last name. Recovering real first and last names for 329,276 of them dropped junk surnames in production from 361,733 to 85,914. A contact whose last name is a slice of their email address cannot be matched to a person, deduplicated, or routed to the right rep. Name completeness is not cosmetic, it is a precondition for every automation that keys off a human being.

The data contract

Here is the idea the whole module turns on. Three systems touch the same fields: enrichment fills them, routing keys off them, and reporting sums them. They only agree if they share one definition of each field. When enrichment writes employee count to one field, routing segments off a second, and a board report bands a third, you do not have a data-quality problem. You have three truths, and every meeting spends its first ten minutes arguing about whose number is right.

A data contract fixes that by naming, for every shared field, a single source of truth (who is allowed to write it), the consumers (who reads it), and the standard (what the value means). One field, one owner, one definition, one write path.

The contract is not paperwork. It is the thing that lets a marketing lead, a routing rule, and a board report roll up to the same number, and it is the reference the next chapter’s automation checks itself against.

What you can do now

You can take the Bowtie from the data model chapter and turn it into a real object-and-field model: the Account as the identity spine, the knot at Closed Won, field standards that keep derived values honest, matching rules that keep one customer as one record, and a data contract that gives enrichment, routing, and reporting a single truth to share. The engineering build of these objects, keys, and match rules lives at the engineering academy’s CRM data-modeling track. This chapter is the operator’s model it implements.

What the model does not do is maintain itself. A contract says what each field should mean. It does not stop two automations from writing the same field in the wrong order, or a flow from firing before enrichment has landed, or a backfill from tipping a trigger over its governor limit. Keeping the data model true on every write is a question of sequence, and sequence is design. That is Automation Architecture, the order of operations that keeps this model honest, and it is next.