Write a metric definition your team can check
Sales says there are 4,180 active customers. Finance says 3,790. Both pulled from the same warehouse, and the meeting has spent twenty minutes on arithmetic nobody will win. The number isn't the problem. The missing document is.
What you'll make
a one-page definition of one contested metric: what it counts, what it excludes, which date it uses, who owns it, and which old figures it replaces.
What you'll need
ChatGPT, Claude, Gemini or Copilot in your work account, a sentence from each team on how their figure is built, the person who can decide what the metric means, and about an hour. You don’t need to upload the data: the disagreement lives in the rules, not the rows.
Example result.
Metric name: Active customers
One sentence: External billing entities with a live contract, or a completed order placed in the trailing 12 months, as at the last day of the month.
Excluded: internal and test accounts
Owner: Commercial director
Known limitation: groups are counted once per billing entity (no parent-company field yet)
In force from: 1 November 2026. Supersedes: sales "active accounts" and finance "contracted customers"1. Collect the rules behind each number
Ask each team for one or two sentences on how they produce their figure. Not the SQL; the rule, in English. “Anyone who placed an order in the last twelve months.” “Anyone with a live contract at month end.” Ask for the date basis and when the data was last refreshed too.
Different totals can come from different rules, stale data, access, missing data or a bug. Don’t decide the cause from the totals alone. Often, writing the two rules side by side settles the argument without any further help.
For a regulatory, accounting or contractual metric, stop here: find the authoritative definition and reference it rather than writing a competing one.
Why this works: everyone is defending a reasonable position. Nobody has written down which one the company means.
What you should see: two short rules, one per team, with their date basis.
2. Ask for the fork points, not the definition
A definition written by something that doesn’t know your business will be plausible, generic and quietly wrong where it matters. Ask instead for every decision the rules disagree on.
Two teams report different figures for [metric]. Rule A: [rule A]. Rule B: [rule B]. Figures: [figures].
List every decision the two rules must differ on. For each, state the decision as a question, give the answer each rule implies (or "not specified"), and describe the kind of customer that falls between them. List separately any other possible causes of the gap to check, such as refresh dates. Don't recommend which rule is right, and don't attribute any part of the gap to a cause.[metric] is the label in dispute; [rule A] and [rule B] are the teams’ sentences; [figures] are the two totals.
Why this works: “the kind of customer that falls between them” turns an abstract rule into a case a person can picture and decide. Forbidding attribution stops the model cheerfully assigning 120 of a 390 gap to one cause.
What you should see: five to a dozen fork points. Most are trivial; two or three are the real argument.
3. Settle each fork point, then draft
Go down the list with whoever can decide. Write the decision beside each, or “unresolved”. An honest gap tells the next person where to be careful. Then ask for the draft.
Draft a one-page metric definition using only these decisions. Use these headings: Metric name; One sentence; Measure and aggregation; Included; Excluded; Date field; Period and comparison; Owner; Source; Known limitations; In force from; Supersedes. Mark any heading my decisions don't cover NOT AGREED. Put unresolved points under Known limitations. Don't add scope, exclusions or dates I haven't given.
My decisions:
[decisions][decisions] is the fork-point list with each answer and who decided it.
Why this works: the headings match what a BI tool will need to implement it, and NOT AGREED keeps gaps visible instead of filled.
What you should see: a one-page draft where every line traces to a decision, and NOT AGREED wherever one is missing.
4. Try to break it before you publish
A definition nobody has attacked is a draft.
Give me five specific customer situations where this definition produces an answer a reasonable colleague would call wrong. For each, say which line of the definition causes it. Be concrete. Don't rewrite the definition.
[definition][definition] is the draft from step 3.
Why this works: the model is systematic in a way a room of people who already know what they think isn’t. Some of the five will be nonsense; one or two will be the case that would otherwise surface in a board meeting.
What you should see: five situations, each tied to a line. Fix what you can, note the rest under Known limitations, and get the owner’s sign-off.
Check the result
Decide the expected results for a few boundary cases yourself, then check the definition gives them: an active contract with no recent order, an ended contract with a recent order, an internal account, a contract that starts next month, and a record with missing contract history.
- Every line traces to a decision the owner made.
- Every case gets the result you expected, from a line you can point to.
- A case with missing facts comes out “unresolved”, not included or excluded.
- Known limitations and NOT AGREED fields are still visible.
The usual failure: a missing fact gets treated as a “no”. A record with no contract history is quietly counted as having no contract, so it’s excluded with confidence. That’s a guess dressed as a rule. Check every case where a fact is missing.
Apply this definition to these cases. For each, return included, excluded or unresolved, quoting the line that decides it. Where a fact needed by the definition is missing, return unresolved and say what's missing. Don't change the definition.
[definition and cases][definition and cases] is your draft definition followed by the boundary cases, one per line.
Worked example: two meanings of active
Fictional example. A B2B services company. Sales reports 4,180 active customers (ordered in the last twelve months); finance reports 3,790 (live contract at month end). The fork-point prompt returned, trimmed:
1. Live contract, no order in 12 months? A: no. B: yes. Between: dormant retainers.
2. Ordered, contract lapsed? A: yes. B: no. Between: lapsed accounts still buying ad hoc.
3. A group of companies: one customer or several? Neither rule says.
4. Internal and test accounts? Neither rule excludes them.
5. As at month end, or across the period? A: across. B: as at.Point 4 was the embarrassing one: the warehouse held eleven internal accounts that had been inflating both figures for two years. The commercial director decided: dormant retainers count; lapsed-but-buying counts; groups counted per billing entity (unresolved until a parent-company field exists); internal and test accounts excluded; measured at month end.
- The break-it finding. The first draft used “order paid date”. The break-it prompt found that a customer paying an eighteen-month-old invoice would count as active. The definition now uses the order placed date, for completed orders.
- The failure. In the case check, a record with no contract history and no recent order came back “excluded”. The repair prompt returned it as unresolved, with “contract history missing” as the reason.
- The payoff. Neither 4,180 nor 3,790 survived. The fictional new figure, 3,655, was the first one both teams trusted.
Task kit for this job: Download (ZIP) · Reusable instructions
Go deeper
Optional training: Put the definition next to the data
Tableau Pulse separates definition filters, which apply to every metric on the definition and viewers can’t change, from adjustable metric filters, which let viewers pick their slice. Borrow the test even if you never use Tableau: a filter that changes what the metric means belongs in the definition; a filter that only chooses whose slice you’re looking at doesn’t. In Power BI, build the correct measure in the semantic model first. Prep data for AI adds AI instructions, AI data schemas and verified answers to help Copilot, and you can mark the model Approved for Copilot. Neither replaces the calculation. Link the written definition to its implementation, and back.
Optional training: Retire the old numbers
Two figures that have circulated for years live in saved reports, board packs and slide templates. Three things make retirement stick. Name the superseded figures explicitly, as the example result does. Set a date, not “going forward”. And restate the previous twelve months on the new basis before launch, because the first question will be whether the number went down or the definition did. If you can’t restate history, label the break in basis and keep the old reports as historical records. Expect the old figure to reappear at least once from someone’s saved view.
Optional training: When it's really two metrics, or really about incentives
Sometimes the fork points show the teams need different things: finance needs customers it can invoice; sales needs accounts worth a visit. If the two rules feed different decisions, keep two metrics with distinct names, and never call either plain “customers”. Don’t keep one name with two rules; that’s where you started. And if one team’s bonus depends on the number being bigger, a definition won’t settle it. That’s a decision for whoever owns both teams, made in the open.