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

Match CRM loss reasons to buyer feedback by verified deal ID, keep both accounts intact, review each apparent conflict, and report the deals with no feedback.

URL: https://www.hiresteve.ai/blog/win-loss-vs-crm
Updated: 2026-10-12

Treat the CRM loss reason and the buyer's own account as two records of the same deal, and rewrite neither. Take one closed period, match the two records by a verified deal ID, and put them side by side with the passage the buyer's reason came from. You end with a reconciliation worksheet: one row per in-scope deal, its linked buyer evidence, a match status, a reviewed interpretation, the open question and who follows up.

## 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](https://www.crayon.co/blog/crm-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](https://images.g2crowd.com/uploads/attachment/file/1208689/The-Definitive-Guide-to-Win-Loss-Analysis-_1_.pdf) 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](/blog/win-loss-analysis-without-a-research-team). If you have transcripts but no traceable findings, [code the interviews](/blog/analyze-win-loss-interviews) before comparing anything.

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

| Field | Comes from | Rule |
| --- | --- | --- |
| Deal ID | CRM | Stored as text. The join key. |
| Close date, outcome, segment | CRM | Defines the cohort. Keep competitive losses, no decision and reopened deals distinguishable. |
| Recorded reason | CRM | The picklist value or free text exactly as exported. Never edited. |
| Linked buyer evidence | Interview or survey | One linked row per respondent: response ID, role, date, passage and where it sits. |
| Match status | You | Confirmed ID, candidate, CRM-only, feedback-only, missing ID or duplicate ID. |
| Reviewed interpretation | You | Neutral, and separate from the source text. |
| Open question and follow-up owner | You | Leave it empty rather than guess. |

## 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.

**Keep ambiguous matches out of the matched set**

Hold candidate matches, CRM-only deals, feedback-only records, missing IDs and duplicate IDs in their own lists, each with a count. The confirmed matched set may be smaller than either file; only confirmed matches belong in the paired-reason analysis. At deal level the check is that in-scope CRM deals equal deals with confirmed feedback plus deals without it. Respondents are a separate total.

## 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](https://support.claude.com/en/articles/12111783-create-and-edit-files-with-claude) 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](https://support.claude.com/en/articles/8241126-upload-files-to-claude) 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](/blog/claude-project-setup). [Projects are available on free accounts](https://support.claude.com/en/articles/9517075-what-are-projects), and Anthropic's [Project management page](https://support.claude.com/en/articles/9519177-how-can-i-create-and-manage-projects) 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.

**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.

**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.

**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.

**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:

```prompt
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](/blog/win-loss-to-messaging). 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](/products/win-loss).

## Frequently asked

### Which record is right when the CRM loss reason and the buyer disagree?

Neither, automatically. Keep the CRM value and the buyer's passage side by side, then read the passage with its date and the respondent's role. Two factors can both be true, and a different word does not make a different reason. Record a reviewed interpretation as a separate field and leave the originals unchanged.

### Can I match deals on company name and close date?

Only as candidates for a reviewer to confirm. Match on the verified source-system deal ID or an explicit crosswalk. Repeated deals with one account, renamed accounts and changed close dates create false joins, so keep every ambiguous match in its own list until someone checks it.

### How many lost deals do I need before the comparison means anything?

There is no validated threshold. Report what the observed set contains: how many in-scope deals had confirmed buyer feedback and how many did not. A small set can justify a specific follow-up without describing all losses, and more rows do not cure selective participation.

### Can Claude do the reconciliation on its own?

Claude can inspect both files, match on verified IDs, build the worksheet and return unmatched and ambiguous records separately. Deciding whether two explanations disagree needs a reviewer who opens the passage and the deal record. Claude's suggested interpretations stay separate from the source text.

### Should I change the CRM loss-reason field after the review?

Propose the change with the evidence, and let the CRM administrator decide. A disagreement does not authorise overwriting a historical record. Keep the previous value and the reason for any revision beside the new one.