Slide 1 of 4
Five, not fifty
A large rule set launched at once produces a backlog nobody can work and a team that concludes the whole thing is noise.
Governing agentic GTM
DoLesson 2 of 7Set the standard
Authoring your first five rules
Write five real, evaluable rules against your own process, sized so the team can absorb what they surface.
25 minAdvanced
Part 1 of 3
Start with five, and choose them for leverage
The instinct with a rules engine is to encode the handbook. Resist it. A large rule set enabled at once generates an exception backlog nobody can work through, and the reliable outcome is that the team stops treating exceptions as meaningful, at which point the rules that genuinely mattered are buried with the rest.
Five is enough to establish the practice and small enough to tune. Choose them where the cost of the gap is already being paid: the field your forecast depends on and nobody maintains, the stage transition that happens without the evidence that is supposed to accompany it, the hygiene problem someone chases by hand every week. Each of those has a demonstrable cost, which also makes the rules easy to defend when someone objects to them.
Part 2 of 3
Write each rule in four parts
A rule that only states a condition is half a rule. Write all four parts explicitly, because the missing ones are where rules fail in practice.
The scope is the part most often left implicit, and it is usually why a rule misfires: a condition sensible for enterprise opportunities applied to every opportunity in the system will generate exceptions on records where it was never meant to apply. The exception clause is the second most-skipped, and leaving it out does not mean there are no exceptions, it means the exceptions are handled informally, by people ignoring the rule, which is the worst of both worlds.
- Condition — what the record must show for the rule to be satisfied
- Scope — which records this applies to, stated rather than assumed
- Consequence — what happens when it is breached, and who is told
- Exception — where it deliberately does not apply, written into the rule
Part 3 of 3
Size it before you enable it
Before switching any rule on, estimate how many existing records would fail it. This is the same arithmetic as sizing a play, and it exists for the same reason: the number of records currently in breach is the queue you are about to create, arriving at once.
If a rule would flag hundreds of records on day one, you have a decision to make deliberately rather than by accident. Either the rule is too broad and needs its scope tightened, or it is correct and you are looking at a genuine backlog that needs a remediation plan, a one-off cleanup separate from ongoing enforcement. Both are reasonable. Discovering it after enabling is not.
Do this in the product
Author five rules
- List the five process gaps that currently cost you the most — measured by manual chasing or by decisions made on bad data.
- For each, write the condition: what a compliant record must actually show.
- Write the scope explicitly. Do not let it default to every record in the system.
- Write the consequence — what happens on breach, and who is notified.
- Write the exceptions into the rule rather than leaving them to informal tolerance.
- For each rule, estimate how many existing records would fail it today.
- Where that count is large, decide before enabling: tighten the scope, or plan a separate remediation pass.
Key questions
You should be able to answer each of these from memory before opening it. Recalling the answer is what makes it stick; recognizing it when you read it does not.
What are the four parts of a rule, and which two get skipped?
Condition, scope, consequence, exception. Scope and exception are the ones people leave implicit, and they are why rules misfire and why exceptions end up handled informally by people ignoring the rule.
Why estimate how many existing records would fail a rule before enabling it?
Records currently in breach are the queue you are about to create, arriving at once. If it is hundreds, you need to either tighten the scope or plan a separate remediation pass, and finding that out afterward costs the rule set its credibility.
What to take away
- Five rules, chosen for leverage rather than for coverage.
- Write each in four parts: object, condition, severity, owner.
- Size the breach volume before you enable anything.
Teach this lesson
The argument in 4 slides, for presenting it to your team
Slide 2 of 4
Choose rules that pay for themselves
- The field a forecast actually depends on
- The stage transition that keeps happening without evidence
- The hygiene gap somebody chases manually every week
Slide 3 of 4
Write each in four parts
- Condition — what the record must show
- Scope — which records it applies to
- Consequence — what happens, and who hears
- Exception — where it deliberately does not apply
Slide 4 of 4
Estimate the volume before you enable
Count roughly how many records fail each rule today. That number is the queue you are about to create.
Demo
Try the demo.
See agents carry the repeatable work of GTM across sales, marketing, customer success, and RevOps. Every action prepared, reviewed, and recorded. Fictional data, real product.
Explore the demo