---
title: "What if a Customer Says a Feature Was Promised in Sales?"
description: "When a customer says a feature was promised, take it seriously, verify in the recording and order form, then offer a workaround, roadmap date or concession."
topic: "Onboarding & Adoption"
author: "Raj Bheda, Co-founder, GainTrace"
audience: "Implementation Specialist, Customer Success Manager"
published: 2026-09-04
modified: 2026-09-04
source: https://gaintrace.com/explore/onboarding/customer-says-a-feature-was-promised
---

# What Do I Do When a Customer Says a Feature Was Promised?

*Verify, then choose one of three outcomes*

**Short answer:** When a customer says a feature was promised, do three things in order. On the first call, take the claim seriously and write down exactly what they expected. Then verify it against the demo recording, proposal and order form without asking anyone "did you promise this". Within five working days, offer one of three outcomes: a workaround for the underlying need, a roadmap item with a date, or a concession.

**Key takeaways**

- The first call is for the specifics, not the verdict. Get the feature, the outcome they expected from it, and the moment they believe it was said. Commit to a date for your answer and end the call.
- Verify from artefacts, not from memory. Demo recordings, the proposal, the order form and the email thread settle most cases; the salesperson's recollection settles none.
- Pick the outcome by what the customer needs. A workaround when the outcome is reachable another way, a roadmap date only when the item is committed, a concession when neither is true and the account is worth keeping.
- Put the answer in writing with a limit stated plainly. A feature built to placate an angry customer, with no agreed definition of done, produces a second complaint about the feature.
- Fix the gap upstream. A handoff note that lists what was promised beyond the order form, with the recording attached, removes most of these calls before they happen.

A newly onboarded customer says a feature was promised, and you know it does not exist. They are high value, they are certain, and they are not calm about it. You have already done the sensible thing: pulled the demo recordings, watched them, and found nothing that was not on the platform. You shared the recordings. They are still adamant. Your founder wants a solutions mindset, so the team built a version of what was asked for, and the customer is now unhappy with that too, because the thing they want cannot reach 100% with the inputs they have. The meetings have turned unpleasant.
This page is for the implementation specialist or CSM in that seat. It gives the script for the first call, a way to verify that does not put a colleague on trial, the three outcomes and when each is the right one, a worked version of the case above, and the handoff fix that stops the next one. The customer may be wrong about what was said. That does not make the situation their fault, and it does not make it yours.

## Why does a customer say a feature was promised when the recording says otherwise?

The r/CustomerSuccess thread this page answers is unusual because the CSM had already done the verification most people skip.

> "I investigated and went through the recordings of the demo, and nothing there was discussed that was not on our platform. I shared these recordings with the client but he is still adamant that we have missold him."
>
> — r/CustomerSuccess, 2026

Sharing the recording did not end the dispute, and it rarely does, because "promised" covers four different things. Sales said it explicitly, and the recording will show that. Sales answered a question with "yes, we can handle that" about a capability that exists in a narrower form than the customer heard. A demo showed a workflow on clean sample data that the customer's messy real data cannot reproduce. Or the customer arrived with a need, saw a product that seemed to address it, and remembered the conversation the way the need required. Only the first is a broken promise. The other three are gaps in expectation, and a recording that proves nobody said the words does not close them.

The gap has a known cause. In the [sales to customer success handoff](https://gaintrace.com/explore/onboarding/sales-to-customer-success-handoff-checklist), what moves is usually the company details, the contract and the main contact. What does not move is what the customer believes they bought. A CSM in another r/CustomerSuccess thread describes the result: "you still have to spend a few conversations finding out why they bought, what problem they were trying to solve, who else was involved, and what they expect from the product." When the first of those conversations is a complaint, the CSM is discovering the expectation and disputing it at the same time.

It is also a first-90-days problem. In our reading of 3,628 public G2 reviews of the three most-reviewed customer success platforms, the reviewers' own complaints about being sold something that arrived later or narrower than described attach to implementation timelines and integrations, the same window in which your customer is deciding whether the purchase was a mistake. One mid-market reviewer put it as integrations that "took a lot more time to get running than it was promised". The feeling is the same on both sides of the vendor line, and it hardens fast if the first response is a recording.

## A customer says a feature was promised: what do I say on the first call?

The instinct on the first call is to settle it. Resist that. The first call has one job: leave with a precise description of what the customer expected, and a date by which you will come back with an answer. Everything else, including whether they are right, waits.

1. **Open by taking the claim seriously, in one sentence.** "You bought this expecting X, and X is not there. I want to understand exactly what you expected so I can get you a proper answer rather than a quick one." No apology for something you have not verified, no defence of the salesperson, no "I've checked the recording". Those all end the conversation before the specifics arrive.
2. **Get the feature as an outcome, not a name.** "When you say automated document matching, what would that do for your team on a Tuesday?" The outcome is what you will have to deliver, and most feature disputes are resolvable at the outcome level and unresolvable at the feature level.
3. **Get the moment.** "Do you remember where in the process it came up? A demo, a proposal, an email, a call with someone else?" Asked as a request for help, not as a challenge. The answer points you at the right artefact and tells you which of the four kinds of "promised" you are dealing with.
4. **Get the stakes.** "What is it costing you not to have it this week?" This is the number you will need to size the outcome. A feature that blocks go-live is a different case from a feature that was nice to have.
5. **Commit to a date, and mean it.** "I will come back to you by Thursday with what we found and what we can do. Whatever the answer is, you'll have it in writing." Five working days at the outside. Then end the call. Do not offer to build anything yet.
6. **Write it up the same hour.** Feature, outcome, moment, stakes, date. Send it to the customer as "here is what I understood" and to the salesperson as "here is what the customer believes". The write-up is the one document both sides will later agree on.

If the customer is shouting or abusive, the script changes in one respect: name it and end the call. "I want to get this right for you and I can't do that in this tone. I'll send the summary and we'll pick up Thursday." Then tell your manager the same day. Taking a claim seriously does not require absorbing abuse, and a CSM who does absorb it makes the eventual answer harder to deliver, not easier.

## How do I verify the claim without putting anyone on trial?

Verification is a search for the customer's expectation, not for a culprit. The question to the salesperson is never "did you promise this". It is "what did we discuss around X, and what did they seem to take from it". The first question produces a defensive no. The second produces the sentence you need.

| Artefact | What it settles | What it cannot settle | Look for |
| --- | --- | --- | --- |
| Order form and contract | What was sold, legally | What was implied in conversation | Any line item, SOW clause or custom term that names the feature or the outcome |
| Proposal and any slides sent | Written claims made before signature | Verbal answers to questions | Feature lists, "supports", "can", roadmap slides shown as present tense |
| Demo recording | What was shown and what was said about it | What the customer heard, or what the data in the demo hid | The customer's questions and the answers, not the presenter's script; note any "yes, we can do that" |
| Email and chat threads before signature | Specific answers given in writing | Tone and confidence of verbal follow-ups | The customer asking about the feature and any reply |
| The salesperson's account | Context: what the customer was worried about, what they compared you to | Whether a promise was made; memory does not settle disputes | Ask what was discussed, what the customer took from it, and what they were comparing you against |
| The customer's own write-up | The exact expectation, in their words | Whether it was reasonable | Where their description of the feature and your product's description diverge |

Write the finding in three lines: what was said, what was shown, what the customer expected. In most cases one of the four kinds of "promised" from the first section becomes obvious. In the thread's case the recording showed nothing outside the product, which points at the third or fourth kind: a demo on clean data, or a need that shaped the memory. Either way, the finding is that the customer's expectation was real and the words were not said, and both halves of that go in the answer.

One rule on the recording: it is evidence for you, not a weapon for the call. Sending it to a customer who is already certain reads as "prove it" and produces exactly what the thread describes, a customer who is still adamant and now also insulted. Use it to decide the outcome. Mention it only if the customer asks what you checked.

## What are the three outcomes, and when is each one right?

By the date you promised, you offer one of three things. Only one. Offering all three as a menu invites the customer to take the concession and keep the complaint.

| Outcome | What it is | Right when | Must include | Fails when |
| --- | --- | --- | --- | --- |
| Workaround | A different route to the outcome the customer named on the first call, using what exists today | The outcome is reachable, even if the exact feature is not; the customer's stakes were about the outcome | A walkthrough on their data, the effort on their side stated honestly, and a check-in two weeks later | It is a feature request in disguise, or it costs the customer more work than the feature would have saved |
| Roadmap item with a date | A commitment that the feature, or the part of it that matters, ships by a named quarter | Product has already committed it and would ship it regardless; the customer can wait with a bridge | The date, the scope in one sentence, what they get in the meantime, and who tells them if the date moves | The date is invented to end the call. A missed roadmap date turns a disappointed customer into a former one |
| Concession | Credit, a term extension, a discount on the next renewal, or a no-penalty exit | Neither of the above is true, the account is worth keeping, and the expectation was reasonable given what they were shown | A single agreed amount tied to the gap, in writing, with the account otherwise treated as normal from then on | It becomes a pattern. A concession given twice teaches the customer that anger is a pricing lever |

Two things are missing from the table on purpose. The first is "build it for them", which is not an outcome, it is a project, and it belongs under roadmap with a date or it does not exist. The second is "tell them they are wrong", which is never the offer even when they are; the finding can be stated in the write-up, and the offer stands on its own.

The hardest case is the one in the thread: the feature they want is not possible with the inputs they have. Here the right outcome is a workaround with a stated limit. "On documents in these formats we match 70% to 80% automatically. The remaining 20% to 30% will always need a person. Here is the fastest way to handle those, and here is what changes if you can standardise the inputs." A ceiling stated plainly, in writing, before the next build, is what the founder's improve-and-see approach was missing. Without it, every improvement is measured against 100% and every one fails.

## What does handling one of these look like end to end?

> **High-value customer, onboarded, wants document automation at 100%:** Day 1, first call. The CSM does not mention the recordings. They ask what the automation would do on a Tuesday: the customer's team keys 400 documents a week by hand and expected that to stop. They ask where it came up: "the demo, when we asked if it handled our formats". Stakes: two people's time and a go-live the VP has promised internally. The CSM commits to Thursday. Day 2, verification. The recording shows the customer asking "does it handle our formats?" and the presenter saying "yes" while showing clean PDFs. The order form lists document matching with no accuracy figure. Finding: the words were said, about a narrower thing, and the demo data hid the gap. Kind two and three at once. Day 4, the answer, in writing. Workaround with a limit: 75% of their volume matched automatically on a sample of 200 real documents, the remaining 25% routed to a review queue that takes one person 40 minutes a day instead of two people all week; a standardised template for their two largest senders would move the figure to 90%. No roadmap promise, because engineering has not committed one. One concession: a one-quarter credit, in recognition that the demo did not show their data, on the condition that success is now measured as the 75% figure and the review queue, not 100%. Day 5, the call. The customer is not delighted. They accept, because for the first time the number they are being asked to accept is a real one.

The CSM in the thread had been asked to keep improving the feature and see. The example gives the founder what they wanted, a solutions mindset, but attaches the two things the original approach lacked: a stated ceiling and a definition of done that the customer agreed to before the next build.

## What if the customer will not accept any answer?

Escalate it, with numbers, once a customer has rejected the workaround, dismissed the roadmap date and pocketed the concession while keeping the complaint. The question has changed from "what do we offer" to "is this account worth what it costs", and that is a decision for someone above the CSM.

**Before escalating the account rather than the feature**
- [ ] Has the customer received one written outcome with a stated limit, and rejected it in writing? If it was only verbal, put it in writing first.
- [ ] Has your sponsor spoken to their sponsor? A dispute that lives between a CSM and a frustrated user rarely resolves; one between two executives with the write-up in front of them usually does.
- [ ] Have you costed the account: hours spent in the last 30 days, engineering time on the custom build, and the ARR? If the hours exceed what three healthy accounts of the same ARR would cost, say so.
- [ ] Is the behaviour abusive? If yes, that is a separate conversation with the customer's sponsor, and it happens before any further feature work.
- [ ] Would a no-penalty exit now cost less than a churn with a public complaint in nine months? If the answer is yes, the concession is the exit.

Letting an account go is covered in the [save playbook](https://gaintrace.com/explore/retention/stop-customers-from-canceling-save-playbook), including how to do it without a scene. The relevant point here is that the CSM should not be the one deciding it, and should not be left improving a feature indefinitely because nobody else will.

## How do I fix the sales-to-CS gap so this stops happening?

> **The promise ledger:** The promise ledger is a single line on the account recording what was committed in the sale, by whom, and where it is written down. When a customer says a feature was promised, the ledger turns a memory argument into a lookup, and it is the artefact that decides which of the three outcomes you owe them.

Every case of "the customer says a feature was promised" is cheaper to prevent at handoff than to resolve in week three. Four changes close most of the gap, and none of them require sales to sell differently.

1. **The handoff note gets a "promised beyond the order form" line.** Anything sales said yes to that is not a line item, including timelines, integrations and "we can handle that". Blank is an acceptable answer; missing is not. The [handoff checklist](https://gaintrace.com/explore/onboarding/sales-to-customer-success-handoff-checklist) has the full note.
2. **The demo recording travels with the account.** Linked in the CRM at close. The CSM watches the customer's questions, not the pitch, before the kickoff, and any "yes" about a narrow capability gets clarified in the kickoff summary while it is still cheap.
3. **Sales gets a "we do not do" list.** Ten lines, maintained by product, of the things prospects most often assume and the product does not do. A salesperson who knows the ten answers gives narrower yeses.
4. **The kickoff reads the expectation back.** "You told us you bought this to stop keying 400 documents a week. Here is what that will look like at day 30, including the part that stays manual." Said on day 7, this is scoping. Said on day 40 in response to a complaint, it is an excuse.

The CSM who wrote about keeping a running line of decisions and commitments per account described the question these notes have to answer when things go wrong: "what they wanted, what we promised, and what changed since." A handoff note that answers the first two on day zero is the whole prevention. When the disputed feature is discovered before the kickoff, it also becomes one of the causes on the [onboarding no-show](https://gaintrace.com/explore/onboarding/customers-not-showing-up-to-onboarding) table rather than a crisis in month two.

## How does GainTrace keep what was promised next to the account?

GainTrace pulls the CRM deal notes, the order form and the support and call history into one account view, so the handoff line about what was promised, the demo recording link and the kickoff summary sit beside the usage data when the dispute arrives, and the CSM verifies in minutes rather than days. [Rescue playbooks](https://gaintrace.com/solutions/rescue-playbooks) run the first-call write-up and the five-day answer as dated steps, and the [customer success](https://gaintrace.com/solutions/customer-success) view shows which new accounts have an open expectation gap before it reaches the renewal.

## Frequently asked questions

### What do I say when a customer insists sales promised a feature we do not have?

Take the claim seriously without ruling on it: "You expected X and it is not there; I want to understand exactly what you expected so I can get you a proper answer." Ask what the feature would do for them, where in the process it came up, and what it is costing them now. Commit to a written answer within five working days and end the call. Do not defend sales or cite the recording on that first call.

### Should I show the customer the demo recording to prove nothing was promised?

Use the recording to decide your outcome, not to win the call. A customer who is already certain reads a recording sent at them as "prove it" and usually stays certain and becomes angrier, which is exactly what happened in the thread this page answers. Mention what you checked only if they ask. The answer they need is what you will do, with a limit stated plainly, not a verdict on their memory.

### How do I find out whether sales actually promised the feature without accusing anyone?

Check artefacts before people: the order form, the proposal, the demo recording and the pre-signature emails, in that order. When you talk to the salesperson, ask "what did we discuss around X and what did they take from it", never "did you promise X". Write the finding in three lines, what was said, what was shown and what the customer expected, and send it to both sides as the shared record.

### Should we just build the feature the customer says they were promised?

Not without a definition of done the customer has agreed to in writing. A feature built to placate an angry customer, with no stated ceiling, gets measured against the impossible version and produces a second complaint. If the outcome is reachable, offer a workaround with the limit stated. If product has committed the item, give a roadmap date. Otherwise a concession. A build belongs under roadmap with a date, or it is not an offer.

### How do I tell a customer the feature they want is technically impossible?

State the ceiling as a number on their data, not as a refusal. "On these formats we reach 75% automatically; the rest will always need a person, and here is the fastest way to handle it." Then say what would move the number, such as standardised inputs. Put it in writing before any further build so that success is measured against the real figure. A customer told 75% stays more often than one promised 100% and given 80%.

### How do we stop sales overpromising to new customers?

Add a "promised beyond the order form" line to the handoff note, link the demo recording to the account at close, give sales a ten-line list of what the product does not do, and have the kickoff read the customer's expectation back on day seven. None of that changes how sales sells. It changes what reaches the CSM and when, which is where most of these disputes are born.

## How this was researched

We read the r/CustomerSuccess thread on a client adamant that features were promised, along with the threads on what sales should share at handoff, what CSMs keep outside the CRM, and unrealistic customer expectations, and quote them here with links. We read 3,628 public G2 reviews of the three most-reviewed customer success platforms and used the reviewers' own complaints about promised timelines and integrations as the vendor-side mirror of the same gap. The script, the outcome table and the worked example are our recommendation and an illustration built from the thread, not customer data.

## Sources

- [r/CustomerSuccess: How to deal with clients who are adamant that we have promised them features that our product does not have?](https://reddit.com/r/CustomerSuccess/comments/1w00qi2/how_to_deal_with_clients_who_are_adamant_that_we/)
- [r/CustomerSuccess: What do you really want Sales to share with you before passing on a customer?](https://reddit.com/r/CustomerSuccess/comments/1vwi505/what_do_you_really_want_sales_to_share_with_you/)
- [r/CustomerSuccess: What do you keep outside the CRM, and does it survive a handoff?](https://reddit.com/r/CustomerSuccess/comments/1v4u9ap/what_do_you_keep_outside_the_crm_and_does_it/)
- [r/CustomerSuccess: How do I handle a customer with unrealistic time expectations without losing them?](https://reddit.com/r/CustomerSuccess/comments/1tinfmv/how_do_i_handle_a_customer_with_unrealistic_time/)

## Next steps

Run the first-call script on the next dispute, add the promised-beyond-the-order-form line to your handoff note this week, and then see the deal notes, recording and usage data on one account view. [Start free](https://app.gaintrace.com/auth/login) or [book a demo](https://gaintrace.com/booking).