Record a customer feature request on the deal itself: a custom field with a short list of options, and the customer’s exact words in one note next to it. Do that, and once a month you can answer the question the product side actually cares about: which missing capability blocked how many deals, worth how much. A request in a call is an anecdote. A request on a deal with a value is an argument.
The quarter Ansel couldn’t add up
An illustrative case, with made-up names and numbers. Quillon Labs sells shift-scheduling software to small clinics. Ansel founded it and still builds most of it. Odalys sells it. At quarter end Ansel sits down with the pipeline and asks the one product question he cares about: what did people ask for that we don’t have?
Odalys sent 22 proposals that quarter. In nine deals, somewhere in the notes, a clinic manager asked for calendar sync with the contractors who cover night shifts. In two, somebody wanted an export the bookkeeper could use. Ansel found them by reading all 22 deals, note by note.
He still can’t answer. “Calendar sync comes up a lot” is what he can say. Not how many of the nine were lost because of it, how many are still open, or what the open ones are worth. The information exists. It lives in prose, and you cannot sum prose.
A request is not an objection
“You’re too expensive” is an objection, and it belongs in your objection handling log. “Do you integrate with QuickBooks?” is a request about what the product is, and it has to reach whoever decides what gets built next.
Where to log feature requests in Pipedrive
On the deal, in a Multiple options custom field. Call it something plain, like Requested capability. Pipedrive has 16 custom field types, and a Multiple options field holds up to 1,000 options (Pipedrive: custom field types), far more than you need. Multiple options rather than Single option, because one prospect can ask for two things and you want both on the deal.
We don’t invent the list up front. The first version has two options: Other and whatever the team has already heard three times. A request that isn’t on the list gets Other plus the customer’s sentence in a note, as close to verbatim as memory allows. “We need the contractor calendars to show up in your schedule” is useful. “Wants integrations” is not. Once a month someone reads the Other deals and promotes anything that keeps coming back to its own option.
Keep the list short on purpose. Ten to fifteen options is where we’d stop, and that is a habit of ours, not a Pipedrive rule. Give a rep forty options and they stop reading, pick the first one that roughly fits, and the count is wrong again. If the field starts to sprawl, custom fields cleanup in Pipedrive covers the pruning.
The deal you lost and the deal still open
The same request means different things in an open deal and a lost one, and the field alone doesn’t say which. So we record a second thing.
| Request in an open deal | Request in a lost deal | |
|---|---|---|
| What goes in Requested capability | The option, or Other + quote | The option, or Other + quote |
| What else to record | Your answer to the customer: no, workaround, or roadmap | Whether this was the reason, or a nice-to-have mentioned in passing |
| Where that second part lives | A note on the deal, dated | The lost reason Missing capability if it decided the deal; the note alone if it didn’t |
The hard part is the lost column. When a deal dies, a request from three weeks earlier is an easy story to tell, and not always a true one. So the question at the loss is blunt: would they have bought if we had it? If the honest answer is “probably not, they went with the vendor their network recommended”, the lost reason is something else and the request stays in the the field as a nice-to-have. Both are worth knowing. They are not worth the same money.
Why not count from the comment a rep types when marking the deal lost? Because Pipedrive saves that comment as a note on the deal (Pipedrive: lost reasons). A note is readable. A field is countable. Setting up lost reasons is its own topic: lost reasons in Pipedrive, and for the wider review, win-loss analysis for a small team.
Not a software team? Same mechanics: a distributor hears “can you deliver on Saturdays”, a training company hears “do we get a certificate at the end”, and both go in Requested capability with the quote.
The first working day of the month
The product person, or the founder playing that role, opens Insights and builds a Deal Progress report. It can be viewed by a Single option or Multiple option custom field and measured by deal value or by number of deals (Pipedrive: Insights deal progress report). View it by Requested capability, measure by deal value, then switch to number of deals.
Two cautions. The date filter is the date deals entered a stage, so set the range to the period you care about. And a deal carrying two requests can show up under both, so read each column on its own and don’t add them up.
The lost side comes from elsewhere. Per the lost reasons page, a Deal performance report can be filtered by lost reason, and the deals list can show a lost reason column. Either tells you which deals went to Missing capability.
Then rep and product sit down together. For each request near teh top: how many deals, how much, how many lost with Missing capability as the reason. That last split is the whole conversation. “Six open deals asking for calendar sync” is a reason to think about a roadmap. “Three deals lost to it this quarter” is a reason to think about it this week.
We think the field is cheaper than a feedback platform while requests stay in the dozens per quarter. That’s our rule of thumb, not data. Past it the monthly read of Other stops being quick, and the method shows its edges.
What this field will never catch
It only sees requests said to a salesperson about a deal. Support tickets, reviews and churned customers’ parting comments live somewhere else. Enterpret’s June 2026 guide makes the point from the other side: when requests from sales conversations and from support sit in separate systems, each one looks less common than it is (Enterpret, 2026). A field in Pipedrive doesn’t fix that. It fixes the half that has a deal value attached.
Savio described a HubSpot version of the same instinct in 2023, built on a Zapier step and a #Product tag in the Closed Lost Reason (Savio, 2023). When support starts sending you more requests than sales does, a dedicated feedback tool earns its price. Not before.
Tell them what happened to the request
The loop is closed by a person, not a report. When something from the field ships, the rep goes back to every deal that asked for it, open or lost, and says so. “You asked for contractor calendar sync in March. It’s live.” No lost deal gets a warmer reason to reopen, and you only know who to send it to because of the field. When something is not going to ship, say that too: “We’re not building a bookkeeping export; here is the CSV route people use instead.” A straight no lets the open deals decide instead of waiting on you.
Ansel’s next quarter started with one chart and contractor calendar sync at the top, a number under it. He built it, and Odalys sent nine messages that each began with “you asked for this”.
A disclosure: we build SalesBond, a sales management layer on top of the CRM a team already uses; we started with Pipedrive. It doesn’t track feature requests. Its Deal Health checks deals against more than 20 rules, so if you want a second look at your pipeline, check your CRM with SalesBond.
