What to Do When Sales Promises a Feature That Doesn't Exist Yet
Find out exactly what was said, decide honestly whether you're building it, and tell the customer the truth before they have to ask twice. That's the response, in order. The order matters because skipping straight to "let's see if we can build it" without first pinning down the actual wording is how a rep's "early next year, probably" turns into a customer's "you promised this would ship in Q1" a week before the renewal call.
The recurring version of this problem is a structural one, not a one-off bad actor. A rep is measured on closing the deal in front of them this quarter; a product team is measured on shipping the right things for the whole customer base. Nothing about those two jobs naturally produces a shared, visible record of what got promised to whom, so the promise lives in one person's head, or in a CRM field nobody else reads, until it surfaces as a support ticket, a renewal objection, or a Slack message asking why a contract line item doesn't work yet.
The first 48 hours
Once you know a promise was made and the ink is dry, four things need to happen quickly, and in this order:
Get the exact wording. "We'll look into it," "it's on the roadmap," and "this ships in Q1" are three different promises with three different obligations. Pull the call recording, the email thread, or the deal notes and find the actual sentence. Reps rarely lie outright; they compress "I think this is a good idea and I'll advocate for it" into something that sounds, from the buyer's side, like a date.
Make a real decision, not a stall. Someone with the authority to commit engineering time looks at the request and says yes, no, or yes-but-later, with a reason. "We're assessing" is not a decision if it's still the answer in three weeks.
Tell the customer before they ask twice. If the answer is no, say so, and say what they can do instead. Customers tolerate "that's not on our roadmap" far better than they tolerate silence followed eventually by "that's not on our roadmap." The trust cost of a walked-back promise is real, but it's smaller than the cost of a promise that quietly rots.
Write down who else was told the same thing. If one rep said it in one deal, it's a bad moment. If it came up in three deals across two quarters, it's a request with real signal behind it, and the account list matters for who gets told when it eventually ships.
How Naomi found out about the routing promise
Naomi Tran is a product manager at Solvent Labs, a spend-management tool for finance teams. Colin Doyle, an account executive there, closed a six-figure deal with Anvik Robotics, an industrial-parts manufacturer, after a demo call where Anvik's VP of finance pushed hard on one gap. Solvent approved whole expense reports, not individual line items, and Anvik's policy required routing anything over $500 to a category-specific approver regardless of the report total.
Naomi found out on the Anvik kickoff call, three weeks after signature, when the finance team's implementation lead opened with a question:
Implementation lead: Before we map the approval chains, can you point me to where line-item routing lives in the settings? Colin walked us through it in the demo.
Naomi: We don't have that yet. Line-item approval isn't built. Let me find out what was actually shown and get back to you today.
The Salesforce Close Notes on the opportunity had one line: "Confirmed line-item routing is coming, this quarter, per conversation with product." No product person had confirmed anything; Colin had said it to answer a blocking objection, expecting someone to bring it to Naomi's team before the contract closed. Nobody had. The gap between "I said this to close the deal" and "product agreed to build this" had traveled straight through signature without stopping.
Naomi worked through the four steps. She pulled the actual call recording (Colin had said "this is high on our list for early next quarter," which had been relayed to the buyer as a commitment), scoped a narrower version her team could ship in six weeks, told Anvik the real timeline that same day, and flagged the account so whoever ran the Anvik renewal in a year would know exactly what had been promised and when it landed.
Why the promise outruns the record
One knight in product's writeup on sales-led feature requests names the incentive gap directly. Reps get fired for missing quota, and have limited accountability for what happens to a customer after the deal closes, while product managers are held to retention and roadmap coherence that a rushed, single-customer build can quietly damage. Neither side is behaving badly by the measure they're held to. The fix the piece recommends, for requests still in flight, is to treat sales as a partner, talking to the prospect directly, checking whether similar existing customers hit the same wall, and scoping the smallest generic version rather than a bespoke one.
That advice is exactly right for requests caught before the contract closes. It doesn't cover what Naomi walked into, because by the time she heard about it, the deal was signed and the promise was already load-bearing for the relationship. The prevention has to happen earlier than the request, at the point where a rep is about to say something forward-looking to a prospect at all.
The commit gate that actually holds
One rule survives contact with practice. Any promise involving unbuilt functionality gets typed into the deal record before it reaches the prospect, in a field product actually reads, and it needs a one-line yes or no from product within a day, not a week. This isn't a "no rep may ever discuss the roadmap" policy, which reps will route around because deals don't wait. It's a fast, narrow gate on the specific claims that create the highest cost when they're wrong.
A weekly ten-minute review of everything logged in that field, run by whoever owns the roadmap, catches most of the drift before it reaches a signature. Attaching each entry to the account it came from means the request that shows up three separate times across three deals gets noticed as a pattern, not re-discovered from scratch each time.
Past a certain volume, the same gap reopens
A shared field and a weekly review hold up for a handful of reps closing a predictable number of deals a month. Past that, the same failure returns in a new shape:
- The promise gets made on a call, not typed anywhere, and lives only in a recording nobody replays until renewal.
- The Close Notes field and the engineering backlog are connected only if someone remembers to paste the account name into both, and that link breaks the first time either side gets renamed or reorganized.
- A request repeated across five accounts in five different regional pipelines looks, from inside any single deal, like a one-off.
That's the point where a manual log stops scaling and something needs to watch the calls and the CRM notes directly, not wait for a person to transcribe them. That's the category Modem works in. It reads Salesforce opportunities and Gong call transcripts alongside Slack, support tools, and issue trackers, matches the same account and the same request across all of them, and keeps commitments attached to the deal that produced them instead of leaving that link to memory. A promise made on a Gong call and echoed in a Salesforce close note becomes one tracked topic instead of two records nobody thinks to cross-reference, and it can be checked against Linear directly rather than trusting that whoever filed the ticket also caught the deal note. The Salesforce integration pulls opportunities, accounts, and contacts in as read-only context; the Gong integration does the same for call transcripts and speakers. We build Modem, so factor that in. A weekly review run consistently still handles most teams below that volume without any of this.
Related reading: how to avoid filing the same feature request five times from five different Gong calls covers the duplicate side of this same seam, and how to turn support tickets into roadmap items covers what happens after a commitment is finally scoped and needs to become real work.
What to do this week
If a promise already landed on a signed account, run the four-step response above today, not after the next standup. If nothing has landed yet, put one line in whatever your team already uses for deal notes: "unbuilt feature promised, product notified, yes/no within 24 hours." The gate is small enough that a rep can clear it mid-call, and it's the difference between a promise product chose to make and one product finds out about from an implementation lead three weeks later.
