The Reason Was Never Price

The proposal goes out on a Thursday. Six weeks later a procurement officer emails to say the client has decided to go another way, thanks the firm for its time, and wishes them well on future opportunities.

Priya, who runs business development, opens the opportunity record in the CRM and marks it Closed Lost. The next field is mandatory: Reason. The dropdown offers six options. Price, Timing, Capability, Incumbent, No Decision, Other.

The procurement email did not give a reason. It never does. So Priya thinks about what she knows. The firm's day rate is above two of the three competitors it usually meets. The client asked twice about fee structure. She selects Price, because it is the most plausible thing on a list of six, and because Other is what people select when they have not thought about it.

She does this eighty-two times a year.

At the annual partner retreat, the business development pack shows that 62% of losses were on price. Nobody built that number dishonestly. It came out of a mandatory field, filled in by a diligent person, aggregated by a spreadsheet that did exactly what it was asked.

The partners discussed it for forty minutes and agreed to sharpen pricing on competitive pursuits. Over the following two quarters the average fee on won work fell about 8%.

The win rate went from 32% to 32%.

The following year a new partner, who had run win/loss reviews at a larger firm, asked whether anyone had actually spoken to the clients who said no. Eleven had been asked, all on losses above AUD $500,000, usually about two months after the decision when the partner remembered.

She read the eleven debriefs. Two mentioned price. Four said the proposal named a delivery team the client never met, and they had no confidence the senior people would still be on the job in month three. Three said the firm showed no evidence of work in their sector. Two said the timeline was longer than a competitor's.

This is, when stated precisely, a business intelligence system whose primary input is one person's guess, whose validation step is a spreadsheet counting the guesses, and whose output was a decision to give away AUD $544,000. Priya did not invent the reasons. She was asked a mandatory question that nobody had given her a way to answer.

Management consultancy in Sydney, New South Wales. Forty-five people: 6 partners, 12 senior consultants, 18 consultants, 5 analysts, 4 business services. AUD $14.2M annual revenue. Work is split between operational improvement, technology advisory and post-merger integration, weighted toward mid-market clients in financial services, healthcare and public sector.

Proposals submitted last year: 120. Average proposed value AUD $186,000. Won: 38. Win rate 31.7%, which has been between 30% and 34% for four years.

Debriefs conducted: 11 of 82 losses, all above AUD $500,000, at a median of 58 days after the decision. Every one was arranged by a partner who remembered to ask, in a conversation that was not recorded and produced notes in three cases out of eleven.

Time spent on the annual win/loss review: two analysts for roughly three weeks pulling records together, then a 40-minute discussion at the retreat. At a loaded analyst cost of AUD $62 per hour, that is about AUD $14,880 a year spent aggregating a field nobody trusts.

The 8% fee reduction applied to AUD $6.8M of won work over two quarters: AUD $544,000. The win rate did not move, which is the part worth sitting with. The firm paid half a million dollars to test a hypothesis it could have tested by making eleven phone calls.

One further number surfaced when the new partner counted manually. Across two years, 14 losses went to the same competitor, concentrated in healthcare. Nothing in the CRM would have shown that, because the competitor field was free text and had been filled in on 31% of records.

The pattern behind all of it: a system that records outcomes faithfully and captures reasons by inference.

Four stages. The core insight: the firm has never had a data problem. It has an asking problem. Every proposal, every RFP, every pricing sheet and every named delivery team is already stored. The only missing input is what the client actually thought, and nobody has been given a repeatable way to collect it.

Stage 1: Assemble the pursuit file

Triggered the moment an opportunity is marked Won or Lost. The agent gathers the proposal document, the original RFP or brief, the pricing sheet, the named delivery team, the proposed timeline, the pursuit duration, and who from the firm was involved at each stage.

This runs on every outcome, not just large ones. A pattern that only shows up in deals above AUD $500,000 is a pattern about large deals, and the firm submits 82 proposals a year below that threshold.

Stage 2: Ask, within two weeks

For a loss, the agent drafts a short debrief request for the lead partner to send. Three questions, no scoring matrix: what mattered most in the decision, what the winning firm offered that the consultancy did not, and what would have changed the outcome.

The partner sends it. Not the agent, and not business development. A request from the partner who pitched carries a different weight from an automated survey, and the response rate reflects that.

The timing is the other half. Two weeks after the decision the client still remembers the detail and has not yet started work with the winner. At two months they are being polite about a decision they have stopped thinking about.

No response after ten days triggers one further request. Silence after that closes the record as unverified, and unverified records are excluded from pattern analysis rather than counted as price.

For a win, a three-question internal capture to the lead partner: what the client said drove the decision, who they were competing against, what nearly went wrong. Wins go unexamined in most firms, which means the reasons a proposal works never get written down.

Stage 3: Separate stated from evidenced

Claude Sonnet reads the debrief response alongside the proposal and the RFP, and produces two fields rather than one.

The stated reason is what the client said. The evidenced reason is what the documents support: whether the proposal named the delivery team, whether it carried sector-specific proof, how the timeline compared to the brief, where pricing sat against the firm's own range.

These are recorded separately and never merged. A client saying price while the proposal contained no sector evidence is a data point about both, and collapsing it into one field is how the firm arrived at 62% in the first place.

Where the debrief is thin or ambiguous, the agent marks confidence low rather than inferring. The agent flags rather than guesses.

Stage 4: Surface the pattern

Win rate by sector, by lead partner, by competitor, by proposal shape. Competitor names normalised rather than free text, so fourteen losses to the same firm are visible in the first quarter rather than the third year.

The dashboard flags recurring patterns above a threshold and takes them to the quarterly partner meeting: three patterns, each with the evidence attached and a named action. Not a forty-minute discussion of an aggregate percentage.

Every won proposal also writes to a library indexed by sector and work type, so the next healthcare pursuit starts from the two that won rather than from the last one filed.

Two fields, not one. This is the whole intervention. A single reason field forces whoever fills it to reconcile what the client said with what they suspect, and the reconciliation happens invisibly inside one person's head. Recording both separately means the gap between them becomes the finding. In this firm the gap was worth AUD $544,000.

The partner sends the request, not the system. An automated survey from a consultancy that just lost gets a response rate around 15%. A short personal note from the partner who ran the pitch gets substantially more, because the client is answering a person rather than a process. The agent removes the remembering, not the relationship.

Unverified is a category, not a default. When a client does not respond, the honest record is that the firm does not know. Filing it as price to satisfy a mandatory field is what produced the original problem. Any dashboard built on this needs to show the unverified proportion alongside every other number, so nobody reads 40% as more certain than it is.

The Dave pattern recurs. Dave in Chicago tracked 340 HVAC units in a spreadsheet and paid AUD equivalent thousands for a compressor under warranty. Same structure: the record existed, the record was consulted, and the record was wrong in a way nobody had reason to check.

Recommended stack: n8n for orchestration. HubSpot, Salesforce or Pipedrive for opportunity records and the outcome trigger. Claude Sonnet for debrief classification and proposal analysis, Haiku for routing and normalising competitor names. Microsoft Graph or Gmail API for sending debrief requests from the partner's mailbox. Postgres for the pursuit file, the two-field reason record and the pattern store.

Step 1: Build the taxonomy and the pursuit schema (Days 1-3). Deploy n8n, configure CRM credentials, set up Postgres. Agree the reason taxonomy with the partner group: price, delivery team, sector proof, timeline, incumbent relationship, scope fit, no decision. Six or seven categories, not fifteen. Build the pursuit file schema. This is the answer key and the partners have to own it, because they will be the ones acting on the output.

Step 2: Build the trigger and file assembly (Days 3-5). Fire on opportunity stage change to Won or Lost. Pull the proposal, RFP, pricing sheet, named team, timeline and pursuit history. Store as a single record. Test against 30 historical opportunities and check nothing important is missing from the CRM, because in most firms something is.

Step 3: Build the debrief flow (Days 5-8). Draft the three-question request, personalised to the pursuit and signed by the lead partner, queued for their approval rather than sent automatically. Schedule at 10 to 14 days post-decision. One follow-up at day 10, then close as unverified. Build the internal three-question capture for wins.

Step 4: Build classification (Days 8-12). Claude Sonnet reads the debrief text, the proposal and the RFP. Returns stated reason, evidenced reason, confidence score, and normalised competitor name. Low confidence routes to a human read. This is the component to spend extra time on, because a misclassification here recreates the original problem in a more convincing format.

Step 5: Build the dashboard and the library (Days 12-14). Win rate by sector, partner, competitor and proposal shape, with the unverified proportion always visible. Pattern detection above a threshold. Quarterly pack generation: three patterns, evidence, suggested action. Won-proposal library indexed by sector and work type.

Step 6: Run alongside (Days 15-45). The CRM dropdown continues. The agent collects independently. Compare after six weeks: how many debriefs came back, how often the stated reason matched the dropdown, and what the evidenced field showed. Target: 55% or better debrief response, and a demonstrable gap between dropdown and debrief.

Estimated build time: 14 to 16 days for a competent n8n developer. Five weeks if learning alongside. Add time if the CRM's historical data needs cleaning before the pursuit files will assemble.

Monthly running costs:

Claude API detail: classification across roughly 10 outcomes a month, each involving a debrief response plus a 20-page proposal, costs about AUD $18. Competitor normalisation via Haiku, under AUD $1. The volume is low because a consultancy closes ten opportunities a month, not a thousand.

Build costs if hiring: 14 to 16 days at AUD $700 to $1,000 per day = AUD $9,800 to $16,000. Self-built: AUD $0 plus two days agreeing the taxonomy with the partners.

Year-one total: AUD $10,652 to $17,740 with a developer, or AUD $852 to $1,740 self-built. Compared against AUD $544,000 given away on a fee cut that did not move the win rate, and AUD $14,880 a year aggregating a field nobody trusts.

Clients do not respond, and the sample skews. Response rates are higher on losses where the relationship stayed warm, which are systematically different from the losses that went badly. Track response rate by loss type and treat any category below 40% as a gap rather than a finding.

Partners do not send the requests. The whole flow depends on a queued draft being approved and sent, which is a task with no deadline. Agree at the outset that debrief requests are approved weekly, and put the unsent count on the dashboard where the partner group sees it.

The taxonomy becomes a new dropdown. Six categories applied by a model produce the same false precision as six categories applied by a person, if nobody reads the free text underneath. Keep the client's own words attached to every classified record and show them in the quarterly pack.

Evidenced reason gets treated as the truth. It is not. It is what the documents support, which is a different thing from why the client decided. Both fields are evidence and neither is a verdict.

The firm acts on a pattern with n=4. Ten outcomes a month means patterns take two or three quarters to become real. Set a minimum count before anything reaches the quarterly pack, and say what the count is next to every pattern.

Debriefs surface something about a named partner. Eventually one will, because delivery team confidence is one of the categories. Decide before go-live who sees partner-level breakdowns and how that conversation happens, because discovering it in a quarterly pack in front of six people is the wrong way.

If your business records why it loses by asking somebody to choose from a list, you know what that person guessed, and you have been managing on it.

Priya is careful and the CRM field was mandatory. She had no debrief to read, no notes from the pitch team, and a dropdown that offered six options for a decision the client had explained to nobody. Selecting Price was the most defensible thing available to her. The failure was upstream: nothing in the firm's process had ever asked the client.

The agent does not decide why the firm lost. Partners still have the conversations, still read the client's own words, still judge which patterns are worth acting on. The agent assembles the file, drafts the request, keeps the stated and evidenced reasons apart, and counts.

Eleven debriefs, or eighty-two. Same proposals. Same clients. Different conclusion entirely.

This is Blueprint #56 in the AdAI series. Every week we publish the full architecture of a real AI agent design: the bottleneck, the build guide, and the costs. Free to read. Free to build from.

Want the next one? Subscribe to AdAI News. New blueprint every week.

by DL
for the AdAI Ed. Team