Revenue ontology

One set of definitions for your team, your CRM and your AI tools.

A revenue ontology writes down what counts as a lead, a qualified meeting and a customer, what moves each one to the next stage, and what your tools are allowed to do on their own. It is the first of the four documents in the blueprint.
Book a discovery call Buy the blueprint
The short version
  1. 01 Marketing and sales mean different things by qualified, and neither definition is written down anywhere.
  2. 02 Your people close that gap from memory. An AI agent cannot, so it picks one meaning and never tells you which.
  3. 03 Writing it down means five parts: objects, states, the evidence to move between them, links, and what software is allowed to do.
01

The problem

Ask why marketing's qualified count and sales' count differ, and somebody explains it on the spot. That explanation is the definition. Nobody wrote it down, because there was always somebody to ask.

Your reports and routing rules run on definitions that live in a few people's heads.

qualified One word. One CRM field.
Marketing reads it as

The lead cleared the score and fits the profile.

Last month: one count
Sales reads it as

A rep accepted it and booked time on the calendar.

Last month: a different count
Both queries are correct. Rebuilding the dashboard changes nothing, because the difference sits in the two definitions the dashboard reads.

What happens with an AI agent

An agent has nobody to ask. Tell it to work the accounts that are in play. Nothing in your systems says what in play means, so it picks one: an open opportunity, a running sequence, or any account past a certain stage.

Then it sticks with that meaning. Every account it touched this week was picked by a rule nobody chose, and nothing in your CRM says which one. Ask later and the answer is in a log, if it was logged at all.

A bone-white agent rests one fingertip on a single box in a long row of identical plain boxes while a revenue leader watches. Only that box carries a mark.
The agent can reach every account. Nothing tells it which ones it is allowed to work.
02

What is a revenue ontology?

It is the written model of how your pipeline works, in five parts. The objects your business deals in. The states each one can be in. The evidence to move between states. The links between objects. And the actions a person or an agent is allowed to take.

The first four describe the business. The fifth is the part software runs: an action writes to your CRM, your sequencer, your routing rules. Without the fifth part, it is only a document.

You may already have a data dictionary for your CRM. It records that a field exists and what type it holds. This records what the field means, what makes a value count, who can change it, and what software may do the moment it changes.

Every routing rule, report and agent you run already uses a version of this model. Most companies never wrote it down, so each tool wrote its own. The six pillars of the Tenbound Standard sit on top of it.

  1. 01 Objects The things the business actually deals in. Named once, in one place.
  2. 02 States Every object sits in exactly one state at a time, from a closed list.
  3. 03 Evidence What has to be true before an object moves. No evidence, no move.
  4. 04 Links How one object joins another, so a result can be traced to its cause.
  5. 05 Actions What a person or an agent is permitted to do, and what blocks it.
03

Where teams disagree

Most teams settle what an account and a buyer are in an hour. Three definitions cause most of the arguing, because each one decides where money or effort goes.

Each one below gets the same three lines: what it decides, its states, and the evidence needed to move between them. The move drawn here is the one your board number depends on.

One move: a booked meeting becomes a qualified one
The rule is written The gate asks for
  1. 01 The written criteria are met.
  2. 02 The evidence for each one is on the record.
  3. 03 The person grading did not book the meeting.
Nothing is written

The move still happens. It happens when whoever is looking at the record decides it did, and next month's number moves with them.

Every state in the model needs a rule of this shape. A state without one still gets set, and nothing on the record says who set it or on what.
01

Qualified

Marketing counts a lead as qualified when it clears a score and fits the profile. Sales counts one when a rep accepted it and booked time on the calendar. Two counts, both right, reconciled by hand every month.

Decides

Which meetings count toward the target, which ones pay commission, and what the board sees.

States, in order
BookedHeldQualifiedDisqualified
Evidence to move

Most teams have the criteria written down. Far fewer have written down who is allowed to grade, and that is where the number drifts.

02

A live reason to act

A rep calls on news from last quarter because it is the best thing in the account. An agent does the same at volume. Nothing tells either of them when a reason goes stale.

Decides

Which accounts get worked this week, and how long one piece of news justifies a touch.

States, in order
ObservedScoredActedExpired
Evidence to move

A source, the date it happened, and the date it expires. Then what it belongs to: a funding round belongs to the account, a job change belongs to one person. Store both the same way and an agent mails the whole buying group about one person's news.

03

In play

Ask two managers whether an account is being worked. One means there is an open opportunity. The other means a sequence is running. Both are normal, and they send the same account to different places.

Decides

Who can be contacted, who owns the account this week, and when outreach stops.

States, in order
In scopeWorkingHeldCustomerOut of scope
Evidence to move

A live reason still inside its window (one that has not expired), plus one reachable buyer, moves an account to working. It moves to held with a re-entry date: the day it is allowed back. Write the stop conditions before the play runs: a reply, a booked meeting, an opt out, the last step, the reason expiring.

The rest is quick. An account is a company you want pipeline in. A buyer is a named person there. A play is a run of touches with one stated reason. An opportunity is a deal with a stage, an owner and a written entry condition. Write those down and move on.

04

What your tools are allowed to do

Every action gets four lines before any tool runs it: what has to be true first, what blocks it, what it changes, and where a person decides.

Worked example

The agent proposes one touch to one buyer. Here is everything that has to be written down before it leaves the building.

Precondition All three true, or it never starts.
  • The buyer is reachable
  • Consent is valid for that channel
  • The cooldown since the last touch has passed

Any one missing: nothing starts.

Blocked by Any one true, and it stops here.
  • A per-buyer or per-account touch cap
  • A suppression list
  • An open reply thread
  • A channel the buyer has declined

Any one present: it stops.

Human decides Either case, and a person signs it off first.
  • First contact with a named executive
  • Anything outside the approved message set

Either case: it waits for a person.

Writes back to Only now does anything leave.

Send a touch

  • The step, to the sequencer
  • The activity, to the CRM
  • The touch count, against the buyer and the account
The same four lines as the cards below, in the order they get checked. Each of the other three actions is this drawing with different conditions in it.

Add an account to a play

Precondition
The account is one we decided to work, something happened there recently enough to still matter, and there is at least one buyer we can actually reach.
Blocked by
An open opportunity, an active play, a current customer, a do-not-contact flag, or an owner already at capacity.
Writes back to
Account state, play membership, and the reason it was added.
Human decides
Nothing, while the preconditions hold. Named strategic accounts go to their owner first.

Send a touch

Precondition
The buyer is reachable, consent is valid for that channel, and the cooldown since the last touch has passed.
Blocked by
Per-buyer and per-account touch caps, suppression lists, an open reply thread, and any channel the buyer has declined.
Writes back to
The step to the sequencer, the activity to the CRM, the touch count against the buyer and the account.
Human decides
First contact with a named executive, and anything outside the approved message set.

Stop a play

Precondition
A stop condition fired: a reply, a booked meeting, an opt out, the last step ran, or the reason expired.
Blocked by
Nothing. Caps and cooldowns do not apply to a stop.
Writes back to
Play state, account state to held with a re-entry date, and the stop reason.
Human decides
Nobody approves a stop. It runs the moment the condition fires.

Mark a meeting qualified

Precondition
The written criteria are met and the evidence for each one is on the record.
Blocked by
Grading by the person who booked it.
Writes back to
Meeting state, and the opportunity if the criteria include opening one.
Human decides
Always. The model names which role does it.

Your scoring, routing and capacity rules read the same objects and states. Configure them separately and each one is right on its own terms while the numbers disagree.

How much an agent can run comes down to how many actions you wrote out this way. The maturity model sets out the four levels, from manual to autonomous.

05

A test you can run this week

Ask an AE, a marketer and an ops lead the same three questions, separately and in writing, so nobody adjusts their answer to the room. It takes an afternoon and no software.

  • 01 What counts as a qualified meeting?
  • 02 Which signals justify action this week?
  • 03 When must a sequence stop?

If the answers differ, you have found the first thing to write down. Pick the answer that wins, record who decided, and date it.

Three people standing in a row in the same room, in identical poses, each holding an identical blank card. Only the person differs.
Three people, the same question. Ask them separately and you usually get three answers.

Bring the answers to a discovery call

Someone senior has to pick one answer and own the number. A graph8 account executive can go through your definitions and stop conditions with you in thirty minutes, free.

Book a discovery call Buy the blueprint
06

Why it is hard to write alone

Teams often book two hours for this and come out with a word list. Agreeing on the definitions is the easy part. Four things stop them sticking.

What comes out

A word list

Three words the room agreed on. Nothing a routing rule can read.

  • Qualified
  • In play
  • A live reason to act
States
Not listed
Evidence to move
Not written
Owner
Not named
What has to come out

The same word, with what decides it

Same word. Same meeting. This one a routing rule can read.

  • In play
States
In scope Working Held Customer Out of scope
Evidence to move
A live reason inside its window, and one reachable buyer. Held carries a re-entry date.
Owner
One named person in revenue operations, a version number, and the date it last changed.
  1. 01

    Nobody updates the tools

    Everyone agrees the new definition on Tuesday. Nobody opens the routing tool, so it keeps running the old rule. Two weeks later you are back where you started and nobody noticed it slip.

  2. 02

    The process doc is out of date

    The engineer gets the states and the evidence from watching your team work, in the tools they use. It almost never matches the process doc, so the ontology is written from the work.

  3. 03

    Someone senior has to decide

    Qualified means one thing to marketing and another to sales. Someone senior enough to own the number picks one, in writing, with their name and the date on it. Until that happens you have two definitions and a standing argument.

  4. 04

    Start with one slice

    Teams start with everything and ship nothing. Start with one slice: the objects an agent touches, the states it can set, what evidence each state needs, and what it is allowed to do.

Then it has to stay written. One named owner, usually in revenue operations. A version number, so changing what qualified means is a dated change everyone can see, not a message in a channel. Every action records the version it ran under.

In the review, an engineer spends 45 minutes with one person from each role, starting with your SDRs and AEs, watches how accounts move, and goes through every tool they use. The ontology is written from what the work shows, and it is the first of your four documents. How the review works.

07

Questions

What is a revenue ontology?

+

A revenue ontology is the written model of your pipeline, in five parts: the objects it deals in (account, buyer, buying group, signal, play, touch, meeting, opportunity, outcome), the states each one can be in, the evidence to move between states, the links, and the actions a person or an agent is allowed to take. The first four describe the business. The fifth is the part software runs: an action writes to your CRM, your sequencer or your routing rules.

Why should a revenue leader care about this?

+

Because it shows up as arguments you already have. Marketing and sales report different qualified counts and both are right. Two managers mean different things by an account being worked. An agent told to work the accounts in play either cannot act or picks a meaning nobody chose. The definitions were never written down in one place.

Is this the same as a data model or a CRM schema?

+

Related, not the same. A schema says a field exists and what type it holds. An ontology says what the field means, what makes a value legitimate, who can change it, and what the system may do once it changes. You can have a clean schema and four teams using stage three to mean four different things.

Why does a revenue ontology decide AI readiness?

+

A rep who sees a deal parked with no meeting booked knows what that means at your company. Nothing in the record says it. An agent has only the record. Every object you never defined, every state with no evidence rule and every action with no stop condition becomes a decision the software makes for you, the same way, every time.

How do I know if we are missing one?

+

Ask three people in different functions three questions. What counts as a qualified meeting. Which signals justify action this week. When must a sequence stop. If the answers differ, your team is running on several definitions at once, and any agent you deploy will pick one without telling you which.

Who owns the revenue ontology?

+

One named person, usually in revenue operations, because they hold the systems the actions write to. The model needs a version number, a review path for changes, and a record on every action of which version it ran under. Run it by committee and definitions change without anyone announcing it.

Do we have to finish the ontology before adopting AI?

+

No, and waiting for a complete one is its own failure. Take the slice of work you want an agent to run. Define the objects it touches, the states it may set, the evidence for each, and the actions it may take with their stop conditions. Skip that and you get the same manual work running faster, and a harder problem to debug.

08

Where this came from

A decade of CIENCE sales development work with these teams.

Next step

Talk to an account executive

Thirty minutes, free, with a graph8 account executive. Bring the three answers you collected, or the AI tool you are about to deploy. Sometimes the honest answer is that the review would not help you yet.

Book a discovery call Buy the blueprint