A feature request is free product research
When a customer asks for a feature, they're handing you a piece of insight most companies pay to get: a real user telling you exactly where the product falls short of their need. How support handles that moment shapes both the customer's loyalty and whether the insight ever reaches the people who can act on it. Treated as a nuisance, it's wasted; treated as a gift, it compounds.
Capture it well, without overpromising
The trap is promising the feature to make the customer happy in the moment. “Great idea, we'll build that” creates an expectation you can't control and a disappointment later. Better: acknowledge the request sincerely, capture the specifics of what they're trying to accomplish, and be honest that you'll pass it to the team without committing to a timeline you don't own. Enthusiasm for the idea, honesty about the outcome.
Capture the why, not just the what
“Add a dark mode” is less useful to a product team than “I work at night and the bright screen strains my eyes.” The underlying need often has better solutions than the specific feature requested. A good chat digs one level down — what problem would this solve for you? — and passes along the need, not just the ask. That context is what turns a request into a good product decision.
Close the loop
The most powerful thing you can do with a feature request is follow up when something happens — when it ships, or even when the team decides against it and why. A customer who hears back feels genuinely heard and stays loyal; one who requests into a void assumes nobody listened. Closing the loop, even on a “not now,” is what makes customers keep telling you the truth.
How MyLiveChat fits
MyLiveChat's transcripts and tagging let you capture feature requests with their full context and spot which ones recur across many conversations — the ones worth the product team's attention. It keeps the record so a request isn't lost in an agent's memory, and the contact so you can close the loop when there's news worth sharing.
Language that captures without committing
The hardest part of taking a feature request is saying something warm that is not a promise.
Agents drift into “that is on the roadmap” or “that should be coming soon”
because both end the conversation pleasantly, and both create a specific expectation that
somebody will be held to months later.
The honest formulation separates the three things being conflated: that you have understood,
that it has been recorded, and that you do not control the outcome. “That makes sense
— I have written it up with your reasoning attached. I cannot promise it will get built or
say when, but it goes to the people who decide” is warm, complete and true.
If something genuinely is planned and publicly announced, say so and point at the public
statement rather than paraphrasing it. If it is planned but not announced, treat it as unannounced
— internal plans change, and a customer who was told privately about a date will quote it
back at you.
Retire “I will pass it on” unless you actually will. It is the most common phrase
in this category and, when it means nothing, it is the one that erodes trust fastest, because
customers eventually notice that passing it on never produces anything.
Separate the request from the problem
Most feature requests are a customer’s proposed solution to a problem they have not
described. Taken literally, they produce a backlog of specific, conflicting, hard-to-build items.
Taken as evidence of a problem, the same conversations become genuinely useful.
So ask what they were trying to do when they wanted it. “What were you working on when
you hit this?” frequently reveals that the underlying need is already met by something they
did not find, which turns a feature request into a documentation fix and a happy customer today.
When it is not already met, you now have the problem statement rather than one person’s
guess at the interface.
Record both, and keep them distinct in whatever you write. The request tells you what one
person asked for; the problem tells you how many other people are asking for the same thing in
different words. Ten requests that look unrelated in a list often collapse into two problems when
written this way, and that collapse is the entire value of collecting them.
Note the cost to the customer as well. “It would be nice” and “we work around
this for an hour every week” are very different signals that look identical once flattened
into a request list.
What to measure
Count distinct customers per underlying problem rather than total requests. One vocal customer
asking five times is not five signals, and treating it as such is how backlogs end up shaped by
whoever writes in most often.
Track how many requests turn out to be existing capability the customer could not find. A high
share is good news, because it is the cheapest possible fix — better documentation or
clearer naming — and it will not appear at all unless you record the resolution as well as
the request. Finally, watch whether anything ever comes back the other way: if no request has been
acknowledged as built in the last year, the collection process has become theatre, and agents
will stop taking it seriously long before customers do.