Skip to content
Governing agentic GTM
DoLesson 7 of 7Prove it

Measuring backlog rather than breach count

Set up a measurement that tells you whether governance is working, rather than one that tells you how much it is finding.

25 minAdvanced
Part 1 of 3

Why breach count is the wrong headline

Total breaches is the number everyone reaches for and it is close to uninterpretable, because it moves with things that have nothing to do with data quality. Add three rules and it rises. Disable one and it falls. Tighten a scope and it falls again. All three are changes to your measuring instrument, and none of them tells you whether the underlying process improved.

It is also perverse as an incentive. If breach count is the reported metric, the fastest way to improve it is to enforce less, which is exactly backwards, and it happens quietly because disabling a noisy rule always has a defensible justification at the time.

Part 2 of 3

Three numbers, weekly, at a fixed time

Record three figures at the same point every week: open breaches, new breaches arriving, and breaches resolved. Consistency of timing matters more than which day you choose, a Monday count and a Friday count differ systematically, and mixing them creates a trend that is an artefact of when you looked.

The diagnostic sits in the relationship between the second and third. When resolution outpaces arrival the backlog falls and the process is genuinely improving. When arrival outpaces resolution the backlog grows, and it does so regardless of how hard the team is working, which is the useful thing to be able to demonstrate, because it distinguishes a capacity problem from an effort problem.

  • Open breaches, at the same hour each week
  • New breaches arriving per week
  • Breaches resolved per week
  • Note any rule change on the same line — it explains discontinuities later
The RevTech rule library: every CRM data standard with its severity and status.
The rule library the CRM Agent inspects against, listing each standard with its severity, scope and active status. Screenshot of the RevTech application; sample data.
Standards at a glance: how many rules are active and how many are critical. This view is the total. Arrival and resolution are what you track against it over time, and they are not on this screen.
Part 3 of 3

Read the age distribution too

One more reading turns this from a trend into a diagnosis. A backlog that is stable in size can be composed of a fast-moving population that is being worked properly, or of a stuck segment quietly ageing while newer items are cleared around it. The total is identical in both cases and the situations are entirely different.

So look at the age of what is open, not just the count. A growing tail of old breaches means a specific category is not being worked, usually because it routes to an owner without capacity, or because a rule is producing exceptions nobody can actually resolve. Both are fixable, and neither is visible in a headline number.

Keep the record from the first week, including the rule changes. Six weeks of this is a far better argument about whether governance is working than any single snapshot, and it is the evidence you will want the first time someone asks whether the rules are worth the effort.

Do this in the product

Set up the measurement

  1. Pick a fixed weekly time to take the reading, and put it in the calendar.
  2. Record three figures each week: open breaches, new breaches arriving, breaches resolved.
  3. On the same line, note any rule added, disabled or rescoped that week.
  4. Also record the age of the oldest open breach and the count older than thirty days.
  5. After three weeks, compare arrival against resolution and state which is larger.
  6. If the old-breach count is growing, identify which rule or owner it concentrates on and fix that specifically.
  7. Report the trend and the arrival-versus-resolution comparison — never the raw breach count on its own.

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.

Why is total breach count close to uninterpretable?

It moves with changes to your measuring instrument. Add rules and it rises; disable one or tighten a scope and it falls. None of those say anything about whether the underlying process improved.

Which relationship is the actual diagnostic?

Arrival versus resolution. When resolution outpaces arrival the backlog falls and the process is improving; when arrival outpaces resolution it grows regardless of how hard the team works, which distinguishes a capacity problem from an effort problem.

A backlog is stable in size. What might it still be hiding?

A stuck segment aging quietly while newer items are cleared around it. Look at the age of what is open, not just the count.

What to take away

  • A rising breach count usually means a new rule found real debt. It is not the headline.
  • Track three numbers weekly at a fixed time: arrived, resolved, open.
  • Read the age distribution. An old backlog and a new one of the same size are different problems.

Teach this lesson

The argument in 4 slides, for presenting it to your team
Slide 1 of 4

Breach count measures the rules, not the process

It rises when you add rules and falls when you disable them. Both moves are under your control and neither says anything about hygiene.

Slide 2 of 4

Track the backlog and its direction

  • Open breaches at a fixed point each week
  • New breaches arriving per week
  • Breaches resolved per week
Slide 3 of 4

The diagnostic is arrival versus resolution

Backlog falling means resolution outpaces arrival — the process is improving. Rising means the opposite, whatever the raw count does.

Slide 4 of 4

Watch the age, not just the size

A stable backlog made of steadily older items is a queue with a stuck segment, and the total conceals it completely.

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