Your win rate is wrong, and here is the stage that fixes it

Ask a sales team for their win rate and you get one number. Ask how it was computed and you get a link to a report. The report is usually counting the wrong things, in three specific ways, and each one moves the answer further than anything being argued about in the pipeline meeting.

We audited the quotation book on a Salesforce org at SMT Research. An open book of 750 quotes, against those won across the life of the system. The org reported a close ratio of 37.2%. The same book closed at 15.0% by dollar. Both are correct. Only one of them describes the business.

A count ratio and a dollar ratio answer different questions

A count ratio answers how often you get picked. A dollar ratio answers how much of the money you chase you actually get. When the count figure is much higher than the dollar figure, it always means the same thing: you win the small ones.

That gap is a segmentation finding, not a rounding difference. It says the qualification rule that works on small jobs is not working on large ones. Publishing a single blended number hides the only interesting thing in the data.

So publish both, side by side, each labelled with what it counts. It costs one extra column.

Defect one: the denominator is full of things that were never bids

In that org, 869 quotes were stale drafts. Priced, saved, never sent. If those sit in the denominator the win rate collapses and nobody believes it. If an analyst quietly removes them with a report filter, the number stops being reproducible by anyone else.

The usual fix is to filter on quote status. That failed here for an honest reason: status was barely maintained, so it did not distinguish a sent bid from an abandoned draft. The reliable signal was the quoted date. A quote with a date went out. A quote without one did not.

That is worth generalising. When a status field is not maintained, stop treating it as data. Find the field the process cannot avoid writing.

Defect two: the same job counted several times

This client sells through general contractors, so one building gets quoted to several of them. Every bid is a real quote. Only one of them can be won, and losing the others is not a loss.

The raw open book was 750 quotes. Deduplicated to unique work by location, it was 394 sites. Roughly half the book was the same jobs seen from different angles.

A win rate computed on the raw book records a loss for every bidder who did not win a job that you, in fact, won. That single defect is enough to halve a reported dollar win rate on its own.

Defect three: open work counted as lost

Any quote still live is neither a win nor a loss. Leaving it in the denominator makes a strong quarter look weak, because the fastest-growing pipeline carries the most undecided work.

The stage that fixes all three

One stage. Call it Bid Submitted. Entry is dated and mandatory, and entering it is the only way a quote joins the denominator.

win rate, by dollar =

    sum of unique work won and decided
  -----------------------------------------------------
    sum of unique work that entered Bid Submitted
    and is now decided

Three properties follow from that one stage. Drafts cannot enter the denominator, because they never received a submitted date. Multi-bid work collapses to one row, because the sum is over unique work keyed on the site rather than the account. And undecided quotes are excluded by the decided filter instead of silently counting as losses.

What it costs to add

• One picklist value and one required date field on the quote.
• A location key, so multi-bid work can be collapsed to unique jobs.
• Two reports rather than one: by count and by dollar, each labelled.
• A backfill of historical quotes, using the existing quoted date as the submitted date.

The backfill is the real work. Where a historical quote has no quoted date, it stays out of the denominator, and the report says how many rows were excluded on that basis. An excluded row that is counted is a lie. An excluded row that is named is a footnote.