How to Align Website Copy with CRM Schema
The Sentence in the Buyer's Head
On why your website copy and your CRM schema have to share a grammar, and why both sides of the building fall over when they do not.
1. What buyers actually do on your site
Nobody reads your website. This is the single most uncomfortable fact in B2B marketing and everyone who builds a site for a living learns it the hard way, usually after the launch, usually while watching a heatmap. The buyer opens five tabs from a Google search, scans the H1 of each, scans a couple of H2s if the H1 was promising, clicks through to pricing somewhere between the second and fourth tab, and has already closed three of the five before a paragraph has been read in full. They are not evaluating your prose. They are looking for permission to leave.
There is a tidy term for this in marketing circles called selective demarketing, but selective demarketing is something marketers do on purpose, and what is actually happening on the page is something the buyer is doing to themselves, at speed, before you get a say. Self-qualification is the better word, or self-disqualification since disqualifying is the faster and more common outcome. The buyer is trying to rule you out. That is the behaviour. The small, attentive minority who do scrutinise every word tend not to be buyers at all. They are competitors, analysts, C-level people nitpicking a positioning they feel territorial about, and in the rare cases where they are real prospects they are usually the ones you do not want as customers because they will bring the same nitpicking energy to the renewal conversation and to every quarterly business review for the rest of time.
So the page has roughly fifteen seconds to say something, and a Google ad has thirty characters and a hundred and fifty more if the prospect is willing to read a line of body text, which they are not. No amount of copywriting cleverness will shove the scope of an enterprise offering through that gap. Something structural has to carry the load the words cannot.
2. The buyer is writing a sentence
Here is the shift that changes how the problem looks. The buyer on your page is not evaluating the page. The buyer is composing a sentence in their head about their own situation and your page is either a word in that sentence or it is not. The sentence runs something like this. I need a [product] with a [feature] that does [solution] for my [use case]. That is the shape. Every buyer who ever bought anything ran some version of that sentence before signing, even if they never articulated it, because the sentence is just what it feels like from the inside to need a thing and identify the thing and hand the thing to someone in finance.
The words in the slots matter. A product is the container the buyer hands to finance. A feature is the object in the system that has to exist for the buyer's situation to apply. A solution is whatever gets done to that object. A use case is not a story about how the product might be used in general terms, it is a specific slice of the buyer's reality, an industry, a department, a geography, a stack, a band of headcount, something the buyer recognises as describing their own circumstances specifically rather than describing a generalised plausible customer. The buyer is filling the slots in the sentence using the words your site gives them, and if your site gives them the wrong words, or worse, gives them the same slot named three different ways on three different pages, the sentence stops assembling and the tab closes.
This is where the grammar comes from. It is not imposed on the buyer from above. It is reverse-engineered from the thing the buyer was already doing before they arrived.
3. Why the slots are shaped the way they are
Product is a noun because the buyer needs a container with a name. Not a promise, not a verb, not a tagline. Revenue Platform is a product. Helps Teams Grow is not a product, it is a thing a product does or claims to do, and the buyer cannot hand Helps Teams Grow to the finance team because nobody can invoice a slogan. A product name has to be the kind of noun that survives a purchase order.
Feature is an object noun because the buyer is naming the thing in the system that their situation runs on. Leads. Contacts. Accounts. Opportunities. Calls. Those are features. Lead Scoring is not a feature, it is a Lead plus a Scoring, two different things fused into one display phrase, and if the ontology treats the phrase as atomic you lose the ability to talk about Leads and Scoring separately ever again. You end up with forty features that are really eight objects and five operators, which is fine for the printed brochure but catastrophic for everything downstream of the brochure.
Solution is the operator that gets done to the object, and it is the same operator whether the object is Leads or Accounts or Opportunities, which is precisely what makes it a Solution rather than a feature descriptor. Scoring is Scoring everywhere. Routing is Routing everywhere. The reusability is the whole point. If what you are calling a Solution only applies to one Feature, it is not a Solution, it is a Feature with a modifier attached.
Use Case is where most CRM documentation goes wrong and it is worth being careful here because depends on getting it right. A Use Case is not the name of a field in the data model. The field itself is the category, and its name might be Sector, Department, Seniority, Company Size, Location, or some other dimension the business targets by. A Use Case is the specific value the buyer selects from that field when it is their turn to describe themselves. Agriculture is a Use Case. Marketing is a Use Case. Philadelphia is a Use Case. The field these values come from is the thing that lets the buyer's reality sort itself against the vendor's model. The value is what actually completes the buyer's sentence.
All of that falls out of the sentence the buyer is writing. Every term in the grammar corresponds to a slot the buyer is already trying to fill. That is the whole reason the grammar is the grammar.
4. The buyer is also submitting evidence
There is a second turn in the loop that most marketing writing skips, and it matters enough to name now because the whole structural case rests on it.
The buyer is writing a sentence about themselves. Your site and your CRM, whether anyone realised they were doing this or not, are a written-down hypothesis about who your buyers are. Every page is a claim. Every Persona in the database is a claim. Every edge in the relational model that says this Feature tends to pair with that Solution for this kind of customer is a claim. The grammar is not neutral scaffolding. It is the shape of the vendor's model of commercial reality.
So when the buyer scans your pages and either stays or leaves, they are not just self-qualifying in the convenience sense. They are submitting themselves as evidence for or against the model. The buyer who finishes the sentence on your site confirms the claim the site was making. The buyer who bounces falsifies it. Over time, the behaviour of thousands of buyers against a shared site and schema either validates the model or reveals the places where it does not match the world. That validation or invalidation is the asset. It is also the reason the grammar has to be clean in the first place, because if Feature and Solution are fused into one phrase or Use Case is a field name instead of a value, the feedback from buyer behaviour comes back as noise rather than as signal and the model cannot learn anything from what the buyers actually did.
The site is testing the buyer and the buyer is testing the site, simultaneously. Both halves work only when the grammar is clean enough to carry the signal in both directions.
5. The relational model does work the copy cannot
A product page has roughly one headline and one subheadline and maybe three further paragraphs before the buyer bounces, and none of those are long enough to carry the full case for anything. What carries the full case is the structure the page sits inside. Each page is a front door. The product page is a front door for people who already know roughly what shape of product they need. The feature page is a front door for people who know they need the object but do not yet know which product to put it in. The solution page is a front door for people who know what operation they want done but do not yet know on which object. The use case page is a front door for people who know their slice of the world and want to know what of yours applies to it.
Some of the buyers will come in the wrong door. That is fine, in fact it is expected, because the buyers who come in the wrong door and find their way to the right one through two clicks of lateral navigation are the ones who now believe the site understood them better than they understood themselves. The feature page lists every product the feature shows up in. The solution page lists every feature the solution applies to. The use case page cross-references everything that touches the selected value. None of that is possible with a content management system where the pages are hand-written blobs of HTML. All of it is possible, and in fact becomes automatic, the moment the content layer is typed and the relationships between types are preserved as data rather than as editorial convention.
The side effect happens to be good SEO, since wide shallow architectures with meaningful internal linking are exactly what search engines reward, and time on site and pages per visit both rise when the visitor has somewhere to go next that is obviously for them. But the SEO is a side effect. The structural argument is the main event.
6. What a clean data layer buys you
This is the part that matters most and is talked about least. Everything above is the buyer's side of the story. There is an operator's side of the same story, and it runs on the same grammar for a completely different reason.
A clean grammar is the precondition for measurement, not a product of it. If Feature and Solution cannot be separated in the data layer then nothing you do to either one can be measured cleanly, because every experiment is really six experiments happening simultaneously to terms the model does not know are different. You change a page and three metrics move and you have no way of knowing which change caused which movement, so you change something else, and now five metrics are moving, and by the third iteration you are reading tea leaves. Marketing teams in that situation end up changing six variables at once because the data model gives them no other option, and then spend the next quarter arguing about attribution, which is what arguing about a broken data model always sounds like from the outside.
Once the grammar is clean the dashboards build themselves out of it rather than around it. Every click on a feature page is typed as a feature interaction. Every click on a solution page is typed as a solution interaction. Every page carrying a Use Case value adds that value to the prospect's implicit record before they have filled in a single form. The scoring model rides on top of typed coordinates that already exist in the schema rather than on fields someone has to invent and backfill every quarter. The rep opens the lead record and sees, at a glance, which features the prospect navigated, which solutions they matched on, which Use Cases they selected themselves by clicking through, and does not need a BI project to find out. The admin overhead that normally swallows a third of a sales rep's week stops existing because the data is already in the shape the CRM expects.
Forms get shorter, which is the bit most teams underestimate until they try it. If the behaviour on the site has already told you the feature, the solution, and the Use Case values, the form does not need to ask. Three fields instead of twelve. Friction collapses. Conversion rises. The fields that do stay on the form become diagnostic rather than redundant, because now you can see the disconnect between what the prospect ticks in the form and what they actually clicked through to read, and when those two disagree the disagreement is itself the most valuable piece of information in the record. The prospect who ticks Marketing Operations on the form but spends the entire session on Revenue Operations pages is telling you something the form alone would never have told you, and now you can act on it, and now the rep walks into the call already knowing what the call is actually about.
Experiments become possible in a way they were not before. You can change one variable because the model supports isolation. You can compare cohorts because the cohorts are typed. You can run a scoring change on one Feature and leave the others alone and see the effect in a week instead of a quarter. Marketing gets to do something closer to science and a little further from interpretive dance. Sales gets to spend time selling rather than chasing down questions the site already answered. The grammar is doing operational work every day, at every stage of the funnel, for every role that touches the record.
And all of it compounds, because every new page built on the same grammar adds to the same dataset, every new feature added to the product fits the existing slots, every new solution added to the platform reuses the existing operators, and the catalogue grows without fragmenting. That is what a coherent model actually buys you over time. Not a prettier schema. A compounding asset.
7. Conclusion
The grammar is not a branding exercise and it is not a style guide and it is not an opinion about how feature names should be capitalised. It is the shape the buyer's sentence has to fit into on one side, and the shape the measurement apparatus has to stand on on the other side, and those two shapes have to be the same shape or the site and the CRM spend their lives talking past each other with the prospect caught in the middle. Copy is the surface. The grammar is the floor. The floor has to hold weight from above, because buyers lean on it when they are writing the sentence, and from below, because operators stand on it when they are trying to measure whether the buyers ever showed up. When it holds, the sentence finishes, and the signal reaches the record, and both sides of the building stay standing. When it does not, everyone keeps writing copy, and the numbers keep not moving, and nobody quite agrees why.
Writing the Grammar Down
The content layer and the relational graph. First of two reference sections for the series.
Orientation
I’ve argued that the buyer on your site is composing one continuous typed sentence about their own situation, and that the site and the CRM have to share the grammar that sentence runs on or the sentence stops assembling. This guide is the working reference. It comes in two halves because the system it documents has two distinct jobs to do and running them together in one pass would fail both.
The system has three layers. The first is the content layer, where Products, Features, Solutions, and the values that make up Personas live. Names in this layer can be almost anything. The grammar rules constrain the shape of the names, not their content, which means the space of possible names is large and essentially open. The second layer is the relational graph, where the content nodes join to each other through many-to-many edges that close into a loop. Product to Feature to Solution to Use Case to Persona to Product. The graph is the organisation's model of what tends to go with what in its commercial reality. The third layer, is the type hierarchy where the content and the graph get composed into deployable execution objects. Pipeline, Campaign, Asset Group, Asset, Activity.
The practical reason all three layers are necessary is worth naming once and then leaving alone. The content layer is set-like, which is to say you draw elements from an open space. The type hierarchy is type-like, which is to say slots are rigidly typed and elements have to fit their slots. The grammar rules are what make an open-space element well-typed on arrival in a slot, and the relational graph is where the open content gets organised into a predictive model before it meets the hierarchy. Following Norman Wildberger's preference for the language of type over the language of set, this whole thing is a bridge that keeps the expressiveness of the first with the discipline of the second. Readers who do not care about the foundations can ignore that paragraph. The rest of the guide is plain English.
The content layer
Six kinds of thing live in the content layer. Products, Features, Solutions, the values that populate Persona Fields, Subjects, and Headlines. Subjects and Headlines belong to the Asset Group and Asset levels respectively and get their full treatment in 2b, so this half of the guide concentrates on the first four. Every entry below gives you a definition, a grammar rule, and a table of what to use and what to avoid. The rule is the load-bearing part. The examples exist to make the rule easy to apply without having to think about it every time.
Product
A Product is the offering, the platform, or the system being sold, adopted, licensed, or deployed. It is the thing the buyer hands to finance when the deal closes. It also functions as a configuration root, which is a slightly technical way of saying that creating a Product sets defaults for a pile of downstream commercial properties like pricing, contract duration, billing frequency, and which pipeline the opportunity runs through.
Rule: stable noun or noun phrase. Never a verb, never a claim, never a tagline.
| Use this | Not this |
|---|---|
| Revenue Platform | Helps Teams Grow |
| CRM | Automates Your Pipeline |
| Customer Data Platform | Routes Leads Faster |
A Product name has to survive a purchase order. Nobody invoices a slogan. Products are also many-to-many with Brands, which means the same Product can appear under more than one Brand and the same Brand can carry more than one Product, and that flexibility is lost the moment the Product name drifts into copy.
Feature
A Feature is a native object the Product supports. A thing inside the system that can be named and pointed at. Leads, Contacts, Accounts, Opportunities, Calls. Not a behaviour. Not an outcome. Not a marketing phrase. An object.
Rule: object noun, two words maximum, thirty characters maximum. Singular or plural is a convention call. Pick one and hold it everywhere.
| Use this | Not this |
|---|---|
| Leads | Lead Scoring |
| Contacts | Contact Enrichment |
| Accounts | Account Intelligence |
| Opportunities | Opportunity Routing |
| Calls | Call Observation |
The right column contains four compositions, not four Features. Each one is a Feature and a Solution fused into one display phrase, which is fine for the surface of a page and catastrophic for the underlying record. If the model cannot tell the difference between the atom and the composition you lose the ability to talk about Leads and Scoring separately, which means three quarters later you cannot answer the question of whether Lead Scoring and Opportunity Scoring are related and if so how, because the word Scoring is no longer a thing in your database, it is just a substring in forty different feature names that were invented page by page by whichever copywriter was awake that afternoon.
Solution
A Solution is an operator, a process, or a transformation applied to a Feature. It answers the question of what gets done to the object. Reusability across Features is the test. If the thing you are calling a Solution only applies to one Feature and cannot be meaningfully lifted to another, it is probably a Feature with a descriptor attached rather than a real Solution.
Rule: nominalised operator. Noun form, never a conjugated verb. Two words maximum, thirty characters maximum.
| Use this | Not this |
|---|---|
| Scoring | Scores |
| Routing | Routes |
| Enrichment | Enriches |
| Automation | Automates |
| Attribution | Attributes |
| Observation | Observes |
The noun form is not an aesthetic preference. Scoring has to apply to Leads and Accounts and Opportunities without being renamed each time, and conjugated verbs cannot hold that job because their tense and pluralisation shift the moment the Feature changes. The operator has to be stable the way nouns are stable, which is why the rule looks like grammar advice and actually is structural engineering.
Persona Fields, Use Cases, and Segments
This is the section that needs room to land correctly, because the three terms here are easy to run together and each one does distinct work.
A Persona Field is a parent-level dimension in the data model. Sector. Industry. Department. Seniority. Job Title. Company Size. Location. These are the categories under which actual targeting values live. Persona Fields have many-to-many relationships with each other, which is how the model expresses the fact that one Department can hold many Seniorities and one Seniority can appear in many Departments without forcing either dimension to swallow the other.
A Use Case is a specific value selected from a Persona Field when a Persona or a Campaign is being built. If the Persona Field is Department, the Use Case might be Marketing or Sales or Operations. If the Persona Field is Sector, the Use Case might be Agriculture or Financial Services. The Use Case is not the name of the field. It is one of the values that field can take, chosen deliberately because the organisation targets that slice of the field specifically.
A Segment is a Persona property used at the Asset Group level in the type hierarchy to slice an audience further within a Campaign. Director. VP. SMB. Philadelphia. The distinction between a Use Case and a Segment is positional rather than intrinsic. The same token (say, Agriculture) can appear as a Use Case in one Campaign and as a Segment in another Asset Group, depending on which level of the hierarchy is doing the slicing and what it is slicing against. This is the first place in the guide where role depends on position in a typed hierarchy, and it is worth noting because the same pattern shows up repeatedly in 2b.
| Persona Field | Example Use Case values | Related Persona Fields |
|---|---|---|
| Sector | Agriculture, Consumer Goods, Financial Services | Industry |
| Industry | Healthcare, Information Technology, Manufacturing | Sector |
| Department | Marketing, Sales, Engineering, Operations | Seniority, Job Title |
| Seniority | C-Level, VP, Director, Manager, Junior | Department, Job Title |
| Company Size | SMB, Mid-Market, Enterprise | (independent) |
| Location | UK, North America, EMEA, Philadelphia | (independent) |
The rule for populating a Persona Field's value list is that the list has to be bounded, the values have to be mutually exclusive within the field, and the list has to be exhaustive enough to cover your real commercial reality with an honest Other or All at the end rather than every edge case enumerated on the assumption you will one day sell there. Adding a value to a Persona Field is a decision, not a default. That discipline is what keeps the finite list finite across three years of product growth.
Persona
A Persona is primarily a Type. Three values, exhaustive: Decision Maker, End User, Influencer. The Type is what makes a Persona a Persona. It is the headline. Everything else the Persona carries is in service to telling you which of these three roles a contact occupies for a given Product, and therefore what tone the copy should take, what call to action belongs on the page, and which other roles in the prospect's organisation need to be in the room before a deal actually closes.
Persona is also product-relative. Each Product defines its own Decision Maker, its own End User, and its own Influencer. The Persona carries selected values from Persona Fields that are specifically relevant to that Product through the relational chain. A Decision Maker for a revenue platform is not the same Persona as a Decision Maker for a call intelligence tool, even if both are Directors of Revenue Operations in SaaS companies between fifty and two hundred people in the UK running HubSpot.
The part that most CRM documentation gets wrong, and that this guide is fixing is that a Persona is not a fixed match. It is a space of possible identifiers. Any single identifier landing against a contact is evidence, not proof. The more identifiers that match, the higher the probability the contact belongs to this Persona for this Product. Behaviour feeds the probability. Form fills feed the probability. Pages viewed feed the probability. Until the contact tells you explicitly what they want, through qualification, the Persona assignment is a hypothesis the data is incrementally confirming or falsifying. That framing becomes important again in 2b when the qualification loop closes.
| Use this | Not this |
|---|---|
| Decision Maker + {Industry: SaaS, Geography: UK, Company Size: 201–1000, CRM: Salesforce, Department: RevOps, Seniority: Director} | "Sarah is a busy RevOps leader who cares about efficiency and wants to modernise her stack." |
The right column is a character sketch. The left is a query. The character sketch cannot be matched against a contact record, cannot be scored, cannot be segmented, cannot be reported against. The query can be matched against every Contact and Account record in the database, ranked by match probability, and surfaced to a sales rep with context that actually helps the call. One of them can do work. The other is decoration.
Persona Type is also the mechanism that lets copy tighten on an identifier without having to spell everything out, which is a point that becomes load-bearing in 2b.
Contact and Account
A Contact is a person record, keyed by a unique email. An Account is an organisation record, keyed by a unique URL or canonical domain. Neither is keyed by a display name because display names are not unique and change.
The reason Contacts and Accounts get a short entry here rather than a long one is that they do not sit in the content layer the way Products and Features do. They are identity-bearing records of actual people and actual organisations, and their job is to be matched against Personas so the system can assign them the right hypothesis. The matching is probabilistic, refined over time, and explicitly confirmed through the qualification process covered in 2b.
The relational graph
Everything in the content layer joins up. The shape of the joins matters because the shape is what makes the system predictive rather than descriptive.
Products have Features. Features have Solutions. Solutions have Use Cases. Use Cases have Personas. Personas have Products. The loop closes. Every edge is many-to-many. A Product supports many Features, a Feature appears in many Products. A Feature carries many Solutions, a Solution applies to many Features. A Solution serves many Use Cases, a Use Case is served by many Solutions. A Use Case is associated with many Personas, a Persona carries many Use Cases across its Persona Fields. A Persona is associated with many Products, and each Product has one Persona per Persona Type, three Personas in total. The graph is a closed relational loop and any node in it is a valid entry point.
This is what makes the site architecture possible. Every node has a view that surfaces its edges. The Feature page lists every Product the Feature appears in. The Solution page lists every Feature the Solution applies to. The Use Case page cross-references the Solutions and Personas attached to it. The Persona page surfaces the Products configured for that Type. A buyer who lands on the wrong node finds the right one in two clicks because the graph routes them. A buyer who lands on the right node finds the adjacent context they need in one.
The graph is also, and this is the more important claim, a predictive model of your commercial reality rather than a descriptive catalogue of it. Every edge in the graph is an assertion the organisation is making. Contacts who match this Persona tend to want this Product. Prospects interested in this Feature also care about this Solution. This Use Case tends to accompany that Persona Type. These are claims. They are testable. When a contact's behaviour tracks the graph, the claims are confirmed. When behaviour diverges from the graph, something is wrong, either in the model or in the way the sales team has read the prospect. The whole point of the system is that both failure modes are visible in the data rather than being lost in the noise.
In schema terms the graph resolves to a small number of joins that are worth writing down as facts so whoever builds the database does not have to infer them. Product to Feature is many-to-many. Feature to Solution is many-to-many. Persona Field to Use Case value is one-to-many. Persona is typed by one of three Persona Types and carries many selected Use Case values, which is a many-to-many between Persona and value scoped by Persona Type. Persona to Product is many-to-one per Persona Type, with three Personas defined per Product. Contact belongs to Account one-to-many with historical joins preserved for job changes. Everything else is downstream of these.
Writing the Grammar Down
The type hierarchy and the qualification loop. Second of two reference sections for the series.
Orientation
Products, Features, Solutions, Persona Fields, Use Cases, Segments, Personas, Contacts, Accounts, and the closed many-to-many loop that joins them all together into a predictive model of your commercial reality. That was the vocabulary and the relational shape. This half is the execution spine. Five levels, each one a compound type, each one inheriting from its parent and adding typed slots of its own, and each one named in a way that reads out its typed composition as a string you can say out loud in a meeting without having to explain what any of it means.
The five levels are Pipeline, Campaign, Asset Group, Asset, and Activity. Every object in your commercial motion lives somewhere in this hierarchy. Every contact touchpoint, every campaign line item, every asset your team produces, every click and open and demo request the CRM records, all of it lands on one of these five levels at a typed coordinate. That coordinate is the object's name, and the name is the type.
The type hierarchy
Pipeline
A Pipeline is the highest-level commercial process container. It groups Products and Opportunities by type for forecasting and reporting, and it determines the structural question of whether the commercial process anchors to an Account plus a Contact, as in a typical B2B motion, or to a Contact alone, as in a typical B2C motion.
The Pipeline name is composed of two typed fields: productType and opportunityType. The naming formula is:
productType • opportunityType
Which produces names like B2B • MQL or B2C • FTP or Reseller • RTP. The productType field values are a short list, usually between two and six for most organisations: B2B, B2C, Reseller, Partnership, Investment. The opportunityType values are the lifecycle stages configured per Product: MQL, SQL, FTP for First Time Purchase, RTP for Retention Purchase. Pipelines are generated automatically when a Product is created with a type, which means the Pipeline layer self-populates as Products come online and does not require separate administration.
Campaign
A Campaign is where the audience meets the offering in a specific context. It inherits both typed fields from the Pipeline (productType and opportunityType) and adds two more: personaType and Use Case. The naming formula is:
productType • opportunityType • personaType • Use Case
Which produces names like B2B • MQL • Decision Maker • Marketing or B2C • SQL • End User • UK or Reseller • FTP • Influencer • Agriculture.
Campaigns are generated combinatorially. Every Product crossed with every Persona Type crossed with every Opportunity Type crossed with every Use Case produces a Campaign. That combinatorial generation is the mechanism by which the system guarantees coverage with no holes. There is no slice of your commercial reality that does not have a Campaign to land in, which matters because a prospect whose data does not match any Campaign is a prospect the CRM cannot attribute, and unattributed prospects are how reporting quietly breaks over a quarter.
Asset Group
An Asset Group is the semantic bridge between Campaign strategy and Asset execution. It inherits all four typed fields from the Campaign and adds three more: subjectType, subject, and Segment. The naming formula is:
productType • opportunityType • personaType • Use Case • Segment • subjectType • subject
Which produces seven-slot names like B2B • MQL • Decision Maker • Marketing • Director • Brand • Oblio or B2B • MQL • End User • Operations • SMB • Feature • Automation.
The seven slots are worth walking through, because this is where the same token you saw as a Use Case in one Campaign can show up as a Segment in another Asset Group, playing a different role at a different position in the hierarchy.
| # | Identifier | Source | Example |
|---|---|---|---|
| 1 | productType | Inherited from Pipeline | B2B |
| 2 | opportunityType | Inherited from Pipeline | MQL |
| 3 | personaType | Inherited from Campaign | Decision Maker |
| 4 | Use Case | Inherited from Campaign | Marketing |
| 5 | Segment | Set at Asset Group level | Director |
| 6 | subjectType | Set at Asset Group level | Feature |
| 7 | subject | Set at Asset Group level | Automation |
The subjectType field takes one of a small set of values: Brand, Product, Feature, Solution, Use Case. It names what kind of thing the Asset Group is about. The subject field takes the specific named instance: Oblio for a Brand subjectType, Automation for a Feature subjectType, Agriculture for a Use Case subjectType. Those two slots together carry the Asset Group's focus, and they exist as separate typed fields rather than one free-text field because the focus has to be machine-readable for the attribution and reporting to work.
Asset
An Asset is the atomic unit of execution. A deployable media or content object. An ad. A landing page. An email. A document. A presentation slide. Whatever the actual artifact is, its job is to catalyse a state change in a prospect, which in practice means moving them from one opportunity stage toward the next.
The Asset inherits all seven Asset Group identifiers and adds six more: a unique headline, a version, a source, a referral type, a medium, and a channel. The primary identifier for an Asset is its headline plus a numerical ID, which is the true coordinate. The naming formula at the Asset level is kept shorter than at the Asset Group level because the full lineage is recoverable from the parent:
Unique Headline • Version
Which produces names like AutomateYourPipeline • V.01. The attribution fields (source, referral type, medium, channel) live on the Asset record and are where values like google.com, Paid, Dynamic Ad, and Search enter the system. This is the layer where the Brand and Domain and Website identifiers you may have seen elsewhere in older documentation do their actual work, as attribution metadata on Assets rather than as first-class ontology entities.
Asset, one rule
Every Asset has one subject. The subject is carried by the subjectType and subject slots inherited from the Asset Group. An Asset about Feature Automation is about Feature Automation. It is not also about Solution Scoring and also about Use Case Agriculture and also about Persona Decision Maker. The single-subject rule is compositional, not stylistic, and it is the rule that makes the "All" classifier meaningful at every other slot.
The "All" classifier and the horoscope principle
This is the section that does the most work in 2b, because it is where the type hierarchy stops being an administrative schema and starts being a tool for writing copy that actually converts.
The compositional rule
Every Asset has one subject. Good persuasive writing has one subject. An article that is about ten things is about nothing, which is why the Asset Group exposes subjectType and subject as typed fields and why those fields take the Asset's focus. The writer's job is to decide what the Asset is about and set those two slots. Everything else serves the focus.
But most Assets do not need every other slot specified to serve the focus. In fact, specifying every slot usually hurts the copy, because the moment you frame a piece as being for Decision Makers specifically, End Users and Influencers read the copy, notice it is not for them, and leave. Sometimes that is exactly what you want. More often it is not. A homepage, a top-level Feature page, a Brand awareness article, all of these have to admit more than one kind of reader simultaneously or they cannot do their job.
"All" is the reserved value that lets you say, at any typed slot, that the Asset is deliberately not specifying at that position. personaType = All means the Asset is not framed for DM, EU, or IN specifically. Use Case = All means the Asset does not anchor to a particular selected value from a Persona Field. Segment = All means the Asset is not sliced to a specific firmographic or demographic cut. What the writer then does is tighten the specified slots, typically subjectType and subject, so the Asset has focus without being narrow, and lets the unspecified slots carry the openness.
The horoscope principle
Great copy, like a good horoscope, feels written for the reader while being written for many readers at once. The writer manages that illusion through two moves that have to happen simultaneously. First, establish a clear identifier that lets the wrong audience disqualify themselves and move on. Second, leave enough room around that identifier for the right reader to complete the sentence in their head and feel addressed. The disqualifier does the exclusion. The room does the inclusion. Both are necessary. Copy that is all disqualifier reads as niche and cold. Copy that is all room reads as vague and means nothing to anybody.
The type hierarchy enables the horoscope principle by giving the writer typed slots to fill when the copy has specificity to carry, and "All" to use when the copy has to leave room. An Asset with personaType = Decision Maker and Segment = Director and subject = Automation can carry heavy specificity in its copy because it is writing to one slice. The copy can name the reader's department. It can name the reader's seniority. It can name what they care about. That is the disqualifier. Everyone not in that slice has permission to leave. Everyone in that slice gets the full treatment.
An Asset with personaType = All and Use Case = All and subject = Revenue Platform is a different animal. It is probably a homepage or a top-level Product page. The copy cannot name a seniority because the audience spans seniorities. It cannot name a Use Case because the Product spans them. What the copy can do is lean hard on the subject (Revenue Platform) and use language open enough that DMs, EUs, and INs all find themselves plausibly addressed, and then route them onward to the specific pages built for each. The "All" values on the open slots are not data gaps. They are structural restraint. They tell the writer explicitly what not to say, so the writer does not accidentally frame the page for one audience and disqualify the other two.
Attribution as consequence
Because every Asset is typed, including the ones that deliberately leave slots open, every contact who touches an Asset lands somewhere in the graph. The specified buckets catch the specialists. The "All" buckets catch the generalists. No behaviour is lost to the void. That attribution completeness is what most documentation of the "All" classifier leads with, but it is a consequence of the compositional discipline rather than the reason for it. The reason is that good writing has one subject and needs room to breathe around that subject, and the data model has to make both possible without fighting.
Activity
An Activity is an event or change record. It is the atomic unit where qualification happens, which is to say it is where the hypothesis represented by the typed hierarchy meets the actual behaviour of an actual Contact and either gets confirmed or falsified.
Activities come in four archetypes. Data Activities create, update, or enrich Contact and Account records, and they qualify as Won when a target field changes from null to non-null. Asset Activities create, version, and publish media, and they qualify as Won when all required creative fields are populated and admin approval is granted. Engagement Activities transfer an Asset to a Contact or record a Contact's interaction with an Asset, and they are the primary source of what the v2 data model calls Activation Energy, which is the measurable transfer of attention and intent from content to prospect. Admin Activities handle governance and validation, approving the work of other users.
Every Activity has Qualifiers. A Qualifier is a boolean gate that evaluates some condition on the Activity or its associated Opportunity as TRUE or FALSE. Budget greater than £10K, Decision Maker present, Contract signed, GDPR opt-in received. When all Qualifiers for an Activity evaluate TRUE within the set duration, the Activity is Won. When a threshold of Qualifiers evaluates FALSE, or the health score decays below the floor, or the qualification expiry window elapses, the Activity is Lost.
The qualification loop
This is the epistemic payoff of the entire system.
The relational graph form is the model. Every edge is a claim. Contacts matching Persona Y tend to want Product X. Features of this shape tend to pair with Solutions of that shape. Use Cases in Sector A tend to accompany personaType DM. These are assertions about commercial reality that the organisation is making when it builds the graph. Until a real prospect tells you explicitly what they want, every edge is a hypothesis.
Activities are where the hypotheses get tested. A Won Activity confirms the typed lineage that produced it. The Contact touched an Asset in an Asset Group in a Campaign in a Pipeline that matched a Persona for a Product, and the Contact's behaviour against that lineage crossed the Qualifier thresholds. The model's prediction at that coordinate is confirmed. A Lost Activity falsifies something upstream. The prediction was wrong. The question is what.
There are two failure modes the loop catches, and both are only visible if the type hierarchy is clean enough to isolate them. The first is that the model is wrong. The graph's edges do not match commercial reality and need revising. Maybe leads consistently show up asking about Feature X paired with Use Case Y that the graph does not connect, and the edge needs to be added. Maybe the Persona for Product Z is being defined against fields that turn out not to predict anything, and the fields need to be retired. These are corrections to the graph itself. The second is that the read is wrong. The graph is right but the sales team is assigning contacts to Personas their behaviour does not support, or assuming interests the data does not confirm. These are corrections to process rather than to structure. Both matter. Both become actionable only when the data is typed cleanly enough to tell them apart.
This is where the clean data layer argument meets the predictive graph argument. Neither works in isolation. A clean data layer without a predictive graph produces tidy reports about nothing in particular. A predictive graph without a clean data layer produces plausible hypotheses that cannot be tested because the variables cannot be isolated. Together, they produce a commercial motion that gets more accurate over time rather than drifting further from reality.
Worked example end to end
One complete typed expression, from Product through Activity.
The Product is Revenue Platform. It sits in productType B2B and supports opportunityTypes MQL, SQL, FTP, RTP. The Pipeline at the moment the prospect enters is B2B • MQL.
The Product carries three Personas, one per Persona Type. The relevant one here is the Decision Maker Persona, which is typed as Decision Maker + {Department: Marketing, Seniority: Director, Company Size: 201–1000, Geography: UK, CRM: HubSpot}. The Campaign that matches is B2B • MQL • Decision Maker • Marketing.
The Asset Group inside that Campaign focuses on Feature Automation. Its seven-slot name is B2B • MQL • Decision Maker • Marketing • Director • Feature • Automation. The Segment Director tightens the audience from all Marketing Decision Makers to specifically Directors within that Persona.
The Asset is a landing page. Its headline is AutomateYourPipeline, version V.01. Source is google.com, referral type is Paid, medium is Page, channel is Search. The full Asset coordinate is AutomateYourPipeline • V.01, with the seven Asset Group identifiers recoverable from the parent.
The Contact is sarah.jones@acme.com, Account acme.com. Sarah's Activities against this lineage include a Data Activity that enriched her record with Department and Seniority, and an Engagement Activity where she visited the landing page, watched the demo, and submitted a form. The Engagement Activity's Qualifiers included GDPR opt-in and demo request. Both evaluated TRUE. The Activity was Won. The Opportunity moved from null to MQL Won, which triggered the automatic creation of the next Opportunity Type, SQL Open, and the Pipeline became B2B • SQL for Sarah from that moment forward.
Every slot is filled. Every coordinate is recoverable. Every Activity is attributable. The model's prediction about Marketing Directors at SaaS companies between 201 and 1000 people in the UK running HubSpot was tested against Sarah specifically and confirmed. Next quarter's report will tell the team how often that prediction holds across every Sarah who walks in through the same Campaign, and the graph's edges will be adjusted for the ones where it does not.
What Changes On The Other Side
The results, the effects, and the asset that compounds once the grammar, the graph, and the hierarchy are in place.
Orientation
The question that matters most to anyone weighing whether to do the work, which is what they can expect to see change in their own organisation once the system is in place. There is no recap below. The reader who needs the structural arguments has them. The reader who skipped to here will get the effects directly and can work backwards into the structure if the effects are interesting enough to merit it.
What changes on the site
The first effect is that self-qualification stops being a thing you hope for and becomes the architecture you ship. Buyers were always going to scan, disqualify, and route themselves through your site at speed. The difference is that with the relational graph in place, the routing they want to do is the routing the site offers. The Feature page lists the Products that carry the Feature. The Solution page lists the Features the Solution applies to. The Use Case page cross-references everything that touches the selected value. A buyer who lands on the wrong front door finds the right one in two clicks, because the doors are connected the way the buyer's sentence is connected.
The second effect is that pages get shorter and there are more of them. The temptation to cram every feature, every solution, and every use case onto a single product page disappears once the model gives each of those nodes its own page. Copy on any one page does the job of one page, which is to validate one identifier strongly enough that the right reader stays and the wrong reader leaves. The buyer's sentence completes in the navigation rather than in any individual paragraph, which is the only way it could ever have completed at the speed real buyers actually read.
The third effect is that cross-linking stops being a manual editorial decision and becomes a direct expression of the relational graph. Every node knows its edges. The site builds its own related-content blocks because the database can answer the question of what relates to what without anyone writing the answer down by hand. Editorial time stops being spent on link maintenance and starts being spent on the copy itself, where it actually matters.
The discerning-nitpicker problem from mostly solves itself. The readers who scrutinise every word for inconsistency tend to leave the homepage when the homepage admits, through structural restraint at the personaType and Use Case slots, that it is not trying to be everything to everyone. Those readers were never converting anyway. The buyers who stay are the ones who saw a slot framed for them and clicked through, which is the population the site was always trying to reach.
The SEO benefits arrive as a side effect rather than as the goal. Search engines reward sites with internal linking density and meaningful page hierarchies, and this architecture produces both without requiring anyone to think about SEO directly. Time on site rises. Pages per visit rise. Bounce on landing pages falls. The forms that remain on the site convert at higher rates because the visitors filling them in have already done most of the qualifying work themselves on the way to the form. None of this requires an SEO project. It falls out of building the site the way the buyer's sentence is shaped.
What changes in the pipeline
Forms shrink. This is the change sales teams notice first and underestimate hardest. Most of the fields a form was asking for were already implicit in the visitor's behaviour by the time they got to the form, and once the type hierarchy is capturing that behaviour as it happens, the form does not need to ask. Three fields instead of twelve. Friction drops. Conversion rises. The fields that remain become diagnostic rather than redundant, because the disconnect between what a prospect ticks in the form and what their behaviour actually showed is now visible, and the disconnect itself is some of the most useful information in the record.
Sales reps walk into calls with context that the system populated rather than context they had to assemble. The Persona match is already there. The Use Cases the prospect navigated through are already there. The Features and Solutions they spent time on are already there. The opening question of the call stops being "so tell me about your situation" and starts being "I see you've been looking at automation for your lead workflow, walk me through what made you start," which is a different conversation. It is shorter, it is more useful, and it lands better.
Qualification becomes hypothesis-testing rather than guesswork. The graph is making claims about what the prospect probably wants, and the prospect's behaviour either confirms or falsifies those claims. The sales call is no longer the first contact between vendor assumptions and prospect reality. It is the place where assumptions that have already been tested against behaviour get tested explicitly through conversation. Reps stop asking questions the system has already answered, which means they spend their time on the questions the system cannot answer, which is the conversation that actually moves a deal.
Two failure modes have become visible. The model-wrong failure shows up as a pattern where prospects consistently behave in ways the graph did not predict, which tells the team an edge needs adding, removing, or revising. The read-wrong failure shows up as deals that match the graph cleanly on paper but go quiet in the conversation, which tells the team that someone has been assigning Personas the data does not actually support. Both used to be invisible. Now they are reportable. The pipeline starts behaving like a system that learns rather than one that drifts.
Cycle times shorten. Some of this is the form-shrinkage effect compounding through the funnel. Some of it is the cleaner sales conversation. Some of it is the reduction in the amount of time a deal spends sitting in pipeline waiting for a rep to figure out what stage it is actually at, because the qualification loop is automating the stage transitions based on Activity outcomes rather than waiting for someone to drag a card across a board. The time a rep used to spend on pipeline hygiene becomes time spent on pipeline conversion.
What changes for marketing
Experiments isolate one variable instead of six. The single biggest reason marketing teams cannot run cleanly attributable experiments is that the data layer underneath them does not support isolation, which means every change is really six changes happening simultaneously and every result is really six results entangled in ways nobody can disentangle after the fact. Once Feature and Solution are separately typed, once Persona Type is a typed axis, once Use Case is a value drawn from a Persona Field, the team can change one thing, leave the others fixed, and read the result. Marketing starts behaving like something closer to a science and something further from interpretive dance.
Attribution stops being an argument and becomes a query. Every Asset is typed. Every Activity is attributed to its lineage. Every Won and Lost outcome traces back through Asset Group, Campaign, and Pipeline to a specific typed coordinate. The quarterly attribution conversation stops being a debate between marketing and sales about which channel deserves credit and starts being a report that names the coordinates that produced the wins and the coordinates that did not. Reasonable people can still disagree about what to do with the information, but the information itself stops being contested.
Dashboards build out of the model rather than around it. The team stops building custom reports because the typed coordinates are themselves the report dimensions. Every cut anyone needs is a slice of an existing typed field. The BI overhead that normally swallows a quarter of the analytics team's time disappears, because the analytics is structurally available rather than perpetually being constructed.
The catalogue stays finite. This is the slow effect, the one that pays off in year two and beyond. Most marketing organisations watch their feature list, their use case list, their persona inventory, and their tag taxonomy double in size every eighteen months, not because the product doubled in scope but because nobody enforced the discipline of treating the lists as bounded sets with admission rules. Once the grammar is in place and the rule is that adding a value is a decision rather than a default, the lists stop sprawling. Campaigns get planned from a stable vocabulary rather than from whatever vocabulary survived the last reorg. Scoring and qualification models become assets that compound rather than spreadsheets that get rebuilt.
What changes in how the team thinks
The cultural effect is the one most reports skip and is also the one that produces the longest tail of returns. When marketing, sales, product, and ops are all naming the same things the same way, conversations get shorter because nobody is translating between vocabularies on the fly. A product manager talking to a sales engineer talking to a marketing operations lead can use the words Feature and Solution and Use Case and Persona and have all three of them mean the same thing across the table. Disagreements become substantive disagreements about the work rather than terminological disagreements that masquerade as substantive ones.
New hires onboard against the schema. They learn the grammar in a week and from that point can read any campaign name, any asset, any activity record, and understand what it is and where it sits. The institutional knowledge that used to live in Slack threads and tribal memory becomes legible in the data itself. Departures stop creating knowledge gaps because the knowledge was structural rather than personal.
Decisions about what to build and what to retire get easier. The relational graph makes the consequences of changes visible. Retiring a Feature surfaces every Asset, every Campaign, every Use Case touching it. Adding a Use Case shows what would have to be built to support it. The conversation about roadmap stops being a debate about competing intuitions and starts being a debate about visible consequences, which is a much shorter conversation.
What compounds
Most of the effects above are static gains. They happen once and then stay better. There is one effect that is not static, and it is the one that earns the whole project its place on the balance sheet.
Every new page added on the same grammar adds to the same dataset rather than fragmenting it. Every new Feature added to the product fits the existing slots. Every new Solution reuses the existing operators. Every new Campaign extends the combinatorial matrix without breaking it. Every Won and Lost Activity refines the graph. The model becomes more accurate over time because the qualification loop is feeding it more evidence, and the evidence is typed cleanly enough to update specific edges rather than just accumulate as noise.
The competitive position this produces is not the system itself, which any sufficiently disciplined team could build given the same blueprint. It is the data that accumulates inside the system, which only your organisation has and which only continues to compound for as long as the discipline holds. A team running this for two years has a model of its own commercial reality that a team starting from scratch today cannot buy and cannot shortcut to. The model knows which Personas convert at which Pipeline stages for which Products against which Use Cases, and it knows it because it has watched thousands of Sarahs walk through the funnel and recorded which assumptions held and which did not.
That is the asset. Not the schema, not the dashboards, not the shortened forms, not even the cleaner attribution. The asset is the accumulating, refining, falsifiable model of how your buyers actually behave, and it is an asset because it grows in value faster than the cost of maintaining it.
The honest costs
Anyone who tells you a structural overhaul like this is free is selling something. The costs are real and worth naming so the work can be planned around them rather than discovered halfway through.
Existing content has to be retagged. Some of it has to be rewritten, because pages that were trying to be three things at once cannot be split cleanly along typed lines without editorial work. Sales teams have to learn a new vocabulary, and the learning takes a quarter of awkwardness before the new words feel natural. Some marketing campaigns that were producing numbers without producing meaning will look worse before they look better, because the cleaner attribution will reveal that some pipeline was being claimed by activity that was not actually causing it. That revelation is uncomfortable in the quarter it lands, even though it is the necessary precondition for the gains that follow.
There is a transition period, usually one quarter and sometimes two, in which the team is paying the cost of the change before the benefits clear. The piece would be less credible if it pretended otherwise. The argument is not that the cost is small. The argument is that the cost is one-time and the gains are recurring, and that the recurring gains compound in a way the transition cost does not.
The reframe
The point of the system is not the system. Buyers were always going to compose the sentence in their heads about their own situation. The only question was ever whether your site and your CRM would let them finish it on you or on someone else. The grammar, the graph, the hierarchy, the qualification loop, all of it exists in service of that single decision. When the system is in place, the buyer finishes the sentence on you, and every completed sentence teaches the team something about how to make the next one easier to finish.
That is the work. The schema is mechanism. The dashboards are mechanism. The shortened forms and the cleaner attribution and the faster cycle times are mechanism. The asset is the relationship between your model of your buyers and the buyers themselves, and the system is what keeps the two in sync as both keep changing. Nothing else in a commercial operation appreciates the way that does. Most things depreciate. This one does not, and that is the entire reason to build it.