A Metric Conflicts With What the Team Is Telling You: Decision Tree

Why this matters

Your report says close rate is steady. Your dispatcher swears estimates are getting harder to win. One of these is wrong, or they are both right about different things and you have not sorted out which. Owners who default to trusting the number dismiss a frontline signal that often catches a problem before it shows up in the data. Owners who default to trusting the anecdote throw out a measurement built from every job, not just the loud ones. Neither default is correct on its own. The number and the person are measuring different things at different speeds, and the skill is figuring out which one is actually wrong, or whether both are right.

Start here: do not pick a side yet

The instinct is to decide who is "right" immediately. Resist it. A metric and a team member's read can conflict for several distinct reasons, and each one points to a different fix. Work through the checks below in order before you conclude anything.

Step 1: Check whether they are actually measuring the same thing

The most common cause of an apparent conflict is not a wrong number or a wrong impression, it is two different definitions of the same word.

• If the team member means "harder to win" as in "customers push back on price more," but your close rate counts only whether the estimate eventually closed, you are looking at two different measurements. Price pushback can rise while close rate holds steady, if you are still winning the job after the pushback.
• If "close rate" in your report is calculated over a longer window than the team member's recent memory (a quarterly rate versus the last two weeks), a real short-term dip can be invisible in the aggregate number while being very real to the person living it day to day.

Before anything else, restate both claims in plain, specific terms and check they describe the same event over the same period. Half of these conflicts dissolve right here.

Step 2: Check the data for a collection or timing gap

If the definitions genuinely match but the numbers still disagree, look for a gap in how the data gets in.

• Is every job actually being logged, or do some get worked off-book (a favor job, a same-day add-on) and never enter the system? A metric built on incomplete data will look calmer than reality.
• Is there a lag between when something happens and when it is recorded? A close that has not been entered yet is invisible to the report even though the crew already knows about it.
• Did a recent change (a new form, a new field, a process tweak) quietly break how this metric gets captured? Check the raw entries, not just the summary number, for anything obviously missing or mis-tagged.

A metric fed by incomplete or lagged data is not lying to you exactly, but it is answering last week's question, not this week's.

Step 3: Check whether the team member is seeing a real but narrow slice

If the data collection checks out, consider that the anecdote may be true and the aggregate number may also be true, because they are describing different slices of the same business.

• One technician or one job type can genuinely be struggling while the company-wide average stays flat, if that slice is a small share of total volume. Break the metric down by the same slice the team member is describing (their jobs specifically, that job type specifically, that neighborhood specifically) before assuming the aggregate overrules them.
• A frontline person often sees the worst cases first and loudest, because those are the ones that generate a conversation. The aggregate includes the quiet wins that never get mentioned. Both are real; the aggregate is simply diluted by cases the anecdote does not include.

This is usually where a genuine conflict resolves: not "who is right" but "what is each of you actually looking at."

Step 4: Check whether the metric itself has a blind spot

If the slice-level number confirms the team member's read even after breaking it down, the aggregate metric has a real blind spot. This is the case to take seriously, not explain away.

• A metric can be technically accurate and still miss the thing that matters. Close rate does not capture how much harder each close was to get, how much discounting it took, or how much longer the sales cycle stretched. A flat close rate sitting on top of rising effort-per-close is a real signal the topline number cannot show.
• When this happens, do not just override the metric with the anecdote. Add or adjust what you are measuring so the real signal shows up in the data next time, and treat the frontline observation as the thing that told you where to look.

Step 5: If you genuinely cannot resolve it, treat it as an open question, not a stalemate

Occasionally the checks above do not settle it cleanly. When that happens, the wrong move is silently trusting whichever source you personally find more comfortable. Name it out loud: "the number says X, you're seeing Y, I don't yet know why, here's what I'm going to check before our next review." Then actually check it. An open, named disagreement that gets resolved next cycle is far healthier than a quiet decision to ignore one side.

The recap

Match the definitions first. Check the data for gaps second. Break the metric down to the same slice the person is describing third. If the anecdote still holds up at that slice, trust it and fix what you measure. Treat the frontline read as an early warning system for exactly the things your metrics were not built to catch, not as noise to out-vote with a chart.

References

• SBA guidance on data quality and operational decision-making for small businesses
• General practice on triangulating quantitative and qualitative signals in operations management
• See related: Too Many Metrics and Nobody Looks at Any of Them; The Difference Between a Vanity Metric and an Operating Metric