Who Dropped the Ball? Your CRM Already Knows

Emily Goh ยท 2026-11-03

It's the Monday after quarter end. Say the forecast called $2.4M and the quarter closed at $1.9M. The CRO opens the meeting with one question: "Who dropped the ball?"

Sales says Marketing sent weak leads. Marketing says Sales sat on them. Finance says three of the deals were never real. Forty minutes later, nobody has changed their mind, and nobody has opened a single record.

Here's the thing. Most of the answer is already sitting in your CRM. To find accountability for a pipeline miss, stop asking who and start asking what changed. Pull the deals that slipped or died, read their history (every stage move, amount change, close date push and owner change, with who made it and when), and check each deal against the pipeline definition your team agreed to. That turns a blame meeting into a short list of facts, and facts point to owners without putting anyone on trial.

Why "who dropped the ball?" goes nowhere

The question assumes one person failed. Most misses don't work that way. A lead comes in, gets qualified, becomes a deal, moves through stages, gets a close date and lands in the forecast. Each step has a different person touching it.

When the number misses, each team defends its own step. Nobody has the whole chain in front of them, so everyone argues from memory. And memory always favours the person speaking.

That's why the same meeting happens every quarter. We wrote about this pattern in Your Pipeline Meeting Is a Blame Ritual. The fix isn't a better argument. It's better evidence.

What your CRM is already recording

Most CRMs can keep a history on key deal fields like stage, amount, close date and owner, as long as field history is switched on for them. Each time a rep moves a deal, someone edits an amount or a manager reassigns an account, the record can store the old value, the new value, who changed it and when.

That trail answers questions memory can't:

If you can walk a number back like this, you can defend it. If you can't, it's an opinion. (More on that in If You Can't Trace a Number, You Can't Defend It.)

One warning: if history isn't switched on for a field, turn it on today. You can't look back at changes that were never recorded.

Separate the record from the definition

Once you're reading deal histories, you'll find two very different kinds of misses.

Record problems. The data was wrong or stale. A close date sat in the past for six weeks. A late-stage deal had no amount. A stage was never updated after the buyer went silent. These belong to whoever owns that deal or that step of the process.

Definition problems. The data was accurate, but it was counted under a rule not everyone shared. Say Sales counted early discovery deals as pipeline and Finance didn't. Both reports were "right." The forecast still missed. This belongs to whoever owns the definition, and if nobody does, that's your real finding.

Mixing these up is how good reps get blamed for bad rules, and how bad rules survive another quarter. Keeping them apart is the heart of business data accountability: every number has a written definition, a named owner and a record of changes.

How to run a pipeline miss review in an hour

You don't need a new tool to start. You need a list and an hour.

  1. List the deals that made up the gap. Say 12 deals were in the forecast and didn't close. Start there, not with the whole pipeline.
  2. Pull the field history for each one. Stage, amount, close date, owner. Lay the changes out in date order.
  3. Tag each deal with one reason. Pushed (real timing change), lost (the buyer said no), never qualified under the definition, stale data, or definition mismatch.
  4. Count the tags. Patterns matter more than single deals. If 7 of the 12 were pushed more than twice, that's a forecast discipline issue across the team, not one rep's mistake.
  5. Name an owner for each pattern. The owner is the person who can change the process or the rule. Their job is the next step, not an apology.

That last point is the difference between accountability and blame. Blame asks who should feel bad. Accountability asks who owns what happens next.

What to do this week

  1. Check field history. Make sure it's switched on for stage, amount, close date and owner on deals.
  2. Pull last quarter's slipped deals. Every deal that was in the forecast and didn't close.
  3. Write your pipeline definition in one sentence, and put one person's name next to it.
  4. Tag your top ten misses using the five reasons above.
  5. Bring the tagged list to your next pipeline meeting instead of the question "who dropped the ball?"

You'll likely find the ball wasn't dropped by one person. It was dropped by a process nobody owned, or a definition nobody wrote down. Both can be fixed.

Where Gohvio fits

Gohvio helps with the definition and record checks above. You upload your own guardrails, the definitions your teams actually use, as a document. A person approves them, and each change is recorded with who changed it and when. Gohvio then checks your CRM data against those guardrails and shows what is broken, what it does to pipeline and forecast, and the rows behind every finding. It is read-only: it reads your CRM and does not write to it.

Stop debating your data. Start making evidence-based decisions.

Frequently asked questions

How do you find accountability for a pipeline miss?

Pull the deals that slipped or died, read their field history for stage, amount, close date and owner, and check each one against your written pipeline definition. Then tag each deal with a reason and name an owner for each pattern, not each deal.

What does a CRM record that helps explain a forecast miss?

When field history is switched on, most CRMs store the old value, new value, who changed it and when for fields like stage, amount, close date and owner. That shows how many times a deal was pushed and when its amount changed.

What is the difference between a record problem and a definition problem?

A record problem means the data was wrong or stale, like a past close date or a missing amount. A definition problem means the data was accurate but counted under a rule not every team shared. They have different fixes and different owners.

What is the difference between accountability and blame?

Blame asks who should feel bad about a miss. Accountability asks who owns the next step, such as changing a process or settling a definition, so the same miss does not happen next quarter.