CRM loss reasons and buyer feedback: compare them on the same deal, and keep both

Put the two accounts beside the same deal

Start with a permission-cleared CRM export for one closed period and the buyer records you already hold from interviews or surveys. From the CRM you need the source-system deal ID, the close date, the stage or outcome, the reason exactly as recorded, and the segment or product that defines the cohort. From the buyer side you need the respondent's role, a response ID with its date, the deal it concerns, the verbatim passage with its location, and any existing interpretation as a separate field. Record the snapshot date and the source filenames, and leave out contact details the comparison does not need.

Rep-entered categories are the thing under study, so hold off on judging them. Crayon's guidance on CRM fields for win-loss analysis notes that generic options such as "bad fit" tend to obscure what happened. A vague category is a reason to inspect its definition; it does not prove the rep was wrong. Clozd's win-loss guide recommends comparing sales and buyer feedback side by side without merging them. This lesson follows that advice and stops short of automatically preferring either side.

If you have no buyer feedback yet, collect it first. If you have transcripts but no traceable findings, code the interviews before comparing anything.

The worksheet has one summary row per in-scope deal, with the buyer evidence linked underneath it:

Check identity and coverage before the reasons

Before reading a single reason, inspect both files: the columns, the raw row count, the distinct deal IDs, the blank IDs and the repeated IDs. Compare the in-scope count against the CRM's own filtered view of the same period, so a filter that silently dropped a segment shows up here.

Match on the verified source-system deal ID, or on an explicit crosswalk when the CRM and the survey tool use different identifiers. When IDs are missing, similarities in company name, close date or product produce candidates for a reviewer to confirm, never automatic joins. Repeated deals with the same account, renamed accounts and changed close dates all create false joins that look tidy.

A deal and a respondent are different units. Three people from one account who answered a survey are three linked rows under one deal, and one deal in the count.

Ask Claude for a comparison you can audit

Claude can read both exports and build the worksheet when code execution and file creation are turned on. Anthropic's file creation page says the capability is available to all Claude users across Free, Pro, Max, Team and Enterprise, and that an organisation owner can disable it. The upload page says XLSX uploads need that setting enabled. The two pages give different size limits depending on where a file is added, so check the limit shown in your own workspace, keep exports small, and split at deal boundaries if a file is too large.

A plain chat is enough for a single run. For a recurring review, keep the schema, the inclusion rules and the reviewed crosswalk in a Claude Project. Projects are available on free accounts, and Anthropic's Project management page says context is shared across a Project's chats only through the knowledge you add, so save the crosswalk, the category definitions and each period's outputs as files.

1. Inspect both files before joining

   Ask for the columns, raw row counts, distinct deal IDs, blank IDs and duplicate IDs per file. Check: the reported in-scope count matches the CRM's filtered view.

2. Match on verified IDs only

   Give Claude the ID column or the crosswalk, and forbid inferred matches. Check: every record that is not a confirmed match appears in one exception list with a count.

3. Build the comparison without rewriting either source

   Ask for the CRM value, each linked passage with its source and date, and absent feedback left absent. Check: every input record is accounted for, and a deal with several respondents shows several linked rows.

4. Keep suggested interpretations separate

   Let Claude propose an interpretation per matched deal in its own column. Check: each suggestion points to a passage you can open, and no interpretation has replaced the source text.

One short prompt covers the two failures that ruin the worksheet, the inferred match and the lossy join:

Inspect both files before joining: report columns, row counts, missing IDs and duplicate IDs. Match only the verified deal ID or the supplied crosswalk. Do not infer a match from company name. Preserve both original reasons and every linked buyer source; keep multiple respondents identifiable. Return unmatched and ambiguous records separately, and reconcile distinct deal counts. Suggest interpretations separately from the source text. Do not update the CRM.

If file analysis is unavailable, the same worksheet and checks work in a spreadsheet. Missing IDs or missing consent are input problems; resolve them before the analysis rather than with a looser join.

Decide whether the explanations disagree

A different word does not make a different reason. A CRM value of "price" and a buyer saying "we could not justify the cost" may describe the same decision, with the buyer's version adding value and ROI context to the label. Use four review labels, and treat them as editorial shorthand rather than a validated taxonomy:

• Supports the recorded reason. The passage describes the same factor at the same scope.
• Adds detail or a different scope. The passage names a mechanism, a stage or a criterion the category could not hold.
• Apparent conflict to review. The two accounts point at different factors, and someone has to read the deal.
• Insufficient evidence. No passage, an unclear passage, or a respondent who was not part of the decision.

Claude may suggest a label; the accountable reviewer confirms it after opening the passage and checking its date and the respondent's part in the decision. Ask whether two factors can both be true, and whether one statement describes a symptom while the other describes a decision criterion. A single passage is one account rather than a verdict. Do not mark a seller wrong solely because a later buyer names a different factor.

An illustrative example, invented for this lesson: a deal recorded as "price" has a buyer passage saying implementation risk stopped internal approval. It stays linked to both accounts and gets "adds decision context; apparent conflict to review", never "price was a lie". On a second deal, a buyer says the price exceeded the approved budget, which supports the "price" label. A third deal with no passage stays at "insufficient evidence" and is counted for neither side.

Report the paired evidence and the missing feedback

Compare the CRM and buyer explanations within the same matched deals first. Then state, as a separate figure, how many in-scope deals had no confirmed buyer feedback. When both numerator and denominator count distinct deals, confirmed-feedback deals divided by all in-scope CRM deals is a valid feedback-coverage rate. Do not use a buyer-reason count over the full CRM cohort as an agreement, disagreement or prevalence rate. Count deals for deal-level findings, and count respondents only when the finding is explicitly about respondents.

There is no validated number of deals at which a tally becomes a pattern. A small matched set can support a specific follow-up without describing all losses, and more rows do not cure selective participation. Say which deals were observed, which segment they came from, and what the reviewed interpretations show in that set.

Each finding gets a proposed action and an owner: a clearer category definition, an evidence note on the deal, a targeted follow-up question, or a messaging hypothesis to test. A CRM administrator decides any change to a source field, and the previous value stays on record with the reason for revision. Keep the snapshots, schema, crosswalk, category definitions, exception log and reviewed worksheet, so the next period starts from a known state.

When buyer-side collection is hard to sustain

The comparison is a bounded piece of work. If your team misses buyer-side collection for deals that meet the configured criteria, use a reminder routine keyed to the CRM stage change and require every new interview or survey record to carry the CRM deal ID.

Steve covers part of that collection step. When a HubSpot deal or Salesforce opportunity closes, won or lost, it invites the buyer after the delay you choose. Collecting responses does not perform the comparison taught here. Steve generates the survey summary when someone requests it, and it reads the structured answers, and the reconciliation and interpretation stay with you. If buyer-side collection is the step your team cannot sustain, see Steve Win/Loss.