KoltrixFeature requests in the inbox: logging them without promising
How to reply honestly to feature requests without committing, log them in the customer's own words, count real demand, and close the loop later.
On this page(9 sections)
- Play 1: Reply honestly without committing
- Play 2: Ask about the problem, not the feature
- Play 3: Log it in the customer's words
- Play 4: Tag consistently so you can count
- Play 5: Merge duplicates, keep every requester
- Play 6: Don't let support become the roadmap
- Play 7: Close the loop
- Checklist for every feature request email
- Bottom line
"Any chance you'll add dark mode?" arrives in the support inbox, and the person replying has two bad options that feel natural: promise something to be nice, or brush it off to be safe. Both cost you later.
Feature requests are some of the most valuable email a product team receives. They tell you what customers are trying to do and where the product falls short. Handled well, they become a steady stream of product insight and a reason for customers to trust you. Here's a playbook for doing that.
Play 1: Reply honestly without committing
The reply has three jobs: thank them, show you understood what they want, and be honest about what happens next. It should not promise a feature or a date unless one actually exists.
Words that accidentally promise:
- "Great idea, we'll add that!"
- "That's coming soon."
- "I'll get the team to build that."
Words that are honest:
- "Thanks, I've logged this with our product team."
- "I can't promise if or when we'll build it, but requests like this directly shape what we work on."
- "I'll let you know if it ships."
A good reply often includes a question, because the most useful information is what they're trying to accomplish:
Hi Priya,
Thanks for suggesting this. I've logged it for our product team.
To make sure I capture it properly: what are you hoping to do with a
calendar view? For example, plan publishing dates, or see deadlines
across projects? The "why" helps us more than the feature name.
I can't promise if or when we'd build it, but I'll email you if it
ships. In the meantime, [workaround, if one exists] might cover part
of it.
Sam
Play 2: Ask about the problem, not the feature
Customers describe solutions: "Add a calendar view." Underneath is a problem: "I can't see what's due this week." Different customers asking for different features may share the same problem, and the best solution might be none of the features they named.
Useful questions:
- "What are you trying to do when you run into this?"
- "How are you handling it today?"
- "How often does this come up for you?"
Not every request needs this. If someone asks for an obvious small thing (a CSV export button), skip the interview. Save the questions for requests that are vague or large.
Play 3: Log it in the customer's words
A feature request log only works if it's consistent and searchable. The minimum fields:
| Field | Example |
|---|---|
| Date | [date] |
| Customer / account | Priya, [workspace] |
| Plan or tier | Team plan |
| Request (their words) | "Can we get a calendar view of all projects?" |
| Underlying problem | Can't see deadlines across projects in one place |
| Link to thread | [link] |
| Tag | planning, views |
| Workaround offered | Filter by due date |
Keep their original wording. Summaries drift ("wants a calendar") and lose the nuance that tells product what actually matters. The underlying problem is your interpretation; the quote is the evidence.
Where should the log live? A spreadsheet works for small teams. A dedicated feedback tool or a tracker your product team already uses works as you grow. What matters is that support can add to it in under a minute and product actually reads it.
Play 4: Tag consistently so you can count
Logging without tagging gives you a pile of anecdotes. Tagging lets you count. Agree on a small set of tags that map to areas of the product or to problems: reporting, integrations, permissions, mobile, planning.
Then, once a month, someone counts:
- How many requests per tag?
- How many distinct customers per tag? (One customer asking five times isn't five customers.)
- Which plans or customer types are asking?
This gives product a demand signal with real names attached, instead of "lots of people want integrations."
Play 5: Merge duplicates, keep every requester
When a second customer asks for the same thing, don't create a new entry from scratch. Add them to the existing one. The list of people attached to a request is what you'll use later to close the loop.
If your log is a spreadsheet, a simple approach is one row per request and a column of requester names or thread links. If it's a tool, use whatever "vote" or "link customer" feature it has.
Play 6: Don't let support become the roadmap
Support teams sometimes feel pressure to advocate hard for every request, especially from vocal customers. That's not their job. Support's job is to capture requests accurately and surface patterns. Product decides what to build, weighing requests against strategy, effort and everything else.
Make this explicit inside the team. It protects support staff from feeling responsible for every "no," and it protects product from being driven by whoever emails loudest.
Play 7: Close the loop
This is where most teams fall down, and where the goodwill is.
When a feature ships: email everyone attached to the request. Personally if the list is short, with a simple template if it's long:
Hi Priya,
A while back you asked about a calendar view for projects. It shipped
today: [link to announcement or docs].
Thanks for the suggestion. If it doesn't quite fit what you needed,
reply and let me know.
Sam
When you decide not to build it: this is harder, but often appreciated. A short, honest note, especially for customers who asked repeatedly or have large accounts, builds trust. "We've decided not to build this, because [brief reason]. Here's what we suggest instead."
When nothing has changed: you don't need to send updates. Silence is fine as long as you didn't promise anything.
Checklist for every feature request email
- Thanked them and restated what they asked for
- Made no promise about whether or when
- Asked about the underlying problem (if the request is vague or large)
- Offered a workaround if one exists
- Logged it in their own words, with a link to the thread
- Tagged it, and added them to an existing entry if it's a duplicate
- Set expectations: "I'll let you know if it ships"
Bottom line
Treat feature requests as evidence, not obligations. Reply warmly and honestly without promising, ask what problem they're solving, log their exact words with a tag, and count distinct customers per tag. When something ships, tell everyone who asked. That single follow-up email turns a request into loyalty.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
