Review lost sales with evidence rather than guesses

Separate a lost opportunity from an unanswered one

An unanswered message is not the same as an explicit rejection. Separate a declined proposal, another supplier chosen, a postponed project, no response and an unknown outcome. Decide internally when active follow-up stops, but do not invent a customer reason to fill a required field. This distinction matters when you later compare proposals: a confirmed pricing objection and an unreachable contact do not support the same conclusion or the same response.

Store customer evidence separately from interpretation

Keep the case ID, proposal version, outcome date, customer-stated reason, internal interpretation, evidence and any unresolved question. Summarise only what is needed and preserve uncertainty. “Outside this quarter’s budget” may differ from “not worth the price,” even if both sit under a broad price category. A brief detail field prevents the category from becoming a misleading conclusion. Keep the original message available through an authorised reference rather than copying sensitive correspondence everywhere.

Use a small set of actionable categories

Start with a short set such as price, scope, timing, delivery capacity, existing relationship, other and unknown. Too many choices reduce consistency between reviewers. If one primary category is required, allow a short secondary explanation rather than forcing a complex decision into one label. Categories should help improve your proposal or qualification process. They should not become a score for blaming customers or ranking salespeople without considering the different work each person handles.

Review outcomes with the proposal context

Compare lost cases with the number and type of proposals made, including product, size, version and customer segment. A small ratio is not a sound basis for changing every price. Timing or scope may sit behind a stated price concern. Distinguish missing entries from explicitly unknown reasons before aggregating. Cases where someone explained the decision are not automatically representative of all opportunities, so show how many outcomes actually have usable evidence.

Turn a review into one measurable change

Choose a specific improvement, such as explaining an exclusion earlier, clarifying the intake criteria or stating delivery options more clearly. Record an owner, date and the next cases in which it will be checked. Preserve earlier entries if categories change so a reporting change is not mistaken for a business improvement. If AI summarises the review, verify that it has not merged customer statements with internal guesses or presented an uncertain cause as a proven one.

Make honest unknowns acceptable

Check explicit rejection, no explanation, postponement, multiple reasons and a case reopened later. Allow an honest unknown even if the field is mandatory. Otherwise the register rewards invented explanations. Preserve the earlier outcome when a new opportunity starts and link the two records instead of rewriting history. Limit the audience for customer-level reviews; broader reporting often needs the category and context, not names or detailed personal correspondence.

Separate declined and postponed cases in a review

Consider three cases where another supplier was chosen, two postponed projects and four unanswered proposals. Classifying all nine as price losses would manufacture a reason for a pricing change. Show how many customers supplied a reason and how many outcomes remain uncertain. A postponed case can receive an agreed future review date; an unanswered customer should not receive repeated surveys merely to fill the report. At the next review, compare actual proposal changes as well as category counts so improved record keeping is not mistaken for an improved sales result.

Choose a tool and budget around the actual workload

A monthly review of a shared register can be enough at low volume. Agree the categories and evidence rules before adding dashboards. If you introduce automatic aggregation or AI summaries, include input review, case volume and access control in the budget. Do not send repeated surveys merely to improve the completeness of your statistics. Use what the existing conversation supports, acknowledge unknowns and assess whether a specific change improves the next set of proposals.

• Build an Airtable enquiry tracker: intake, owners and follow-up states
• Collect actionable service feedback with Tally
• Find unfinished work in Airtable views: filters, sorting and sharing checks