How to tell a real feature request apart from a cold pitch in your support inbox

Look at the sender before you look at the wording. A real feature request comes from an email address tied to someone who already uses your product: a customer, a trial signup, someone inside a paying account. A cold pitch comes from a stranger's domain, no matter how closely the subject line mimics feedback, as in "any plans to add a public roadmap page?" The wording alone can't sort the two, because outreach senders have learned to write in exactly that register on purpose.

That's the actual filter. Identity comes first, phrasing second. A keyword rule that fires on "would love to see," "any plans to add," or "roadmap" catches genuine requests and agency pitches with equal confidence, because both groups are writing to trip the same rule. What a keyword can't check is whether the sender has ever logged in.

Front and Gmail rules only look at the message, never the sender

Front's rule engine is a text-and-metadata matcher, and its own guide to rule triggers, conditions, and actions confirms exactly that shape: "Message body contains," "Conversation subject contains," "From field contains," plus "Starts with" and "Ends with" variants on the same fields. Nowhere in that list is a condition for "sender is a customer," because Front has no concept of your customer roster. It only sees what a message says and who sent it, as strings.

Gmail filters have the identical shape: sender, subject, "has the words." Neither tool ships with any notion of who your customers are, so neither can separate a genuine ask from a pitch that copied the same phrasing on purpose. This isn't a missing feature waiting on a future release. Intent detection needs a fact the inbox software doesn't hold: whether this sender already has a relationship with your product. No amount of keyword tuning manufactures that fact out of message text, because the fact doesn't live in the text.

The rule fires on both messages, and only one has an account behind it

Two emails land in founders@ the same morning. One asks whether you'll add a CSV export that includes the IDs the sender is currently copying into a spreadsheet by hand every week. The other opens with praise for your product, asks whether you've considered adding a public roadmap page, and offers a call to walk you through what the sender built for other tools in your space. Both name a specific feature. Both use "have you considered." A Front rule that tags anything containing "roadmap" or "add" in the subject or body as feature-request fires on both of them, identically, and it reads the phrasing correctly in each case.

Now check the senders instead. Look up the first sender's domain in whatever system holds your active accounts, billing or auth, and you find a live subscription and prior support conversations on file. Look up the second and you find nothing at all: no signup, no login, no conversation history. That absence is the whole signal, and no phrase in either body could have supplied it, because both bodies were written to pass the same keyword rule.

So the fix isn't a longer keyword list. It's checking the sender against your customer table before the feature-request tag is allowed to stick, and routing anything that doesn't match to review instead.

Building the identity check by hand

Three pieces, roughly in order of effort:

1. Export or connect your customer list. A spreadsheet of active account emails and domains is enough at small volume. A scheduled export from your billing or auth system keeps it current without anyone remembering to update it by hand every week.
2. Match on domain, not only on exact address. Anyone emailing from a customer's domain should count, not just the original signup contact, because the ops manager who never created the account is still a real customer emailing from a real company. Exact-address matching alone misses every teammate who isn't the account owner.
3. Route unmatched senders to a review queue instead of auto-tagging them as requests. An unmatched sender using request-shaped language isn't automatically a spammer; it might be a prospect evaluating the product, which deserves a different reply than a link-building pitch does. The queue exists so a person makes that call, instead of a keyword rule making it by default.

This carries a small team most of the way. A founder checking founders@ once a day can eyeball ten unmatched emails and sort them correctly in a few minutes, which is exactly the scale this version is built for.

Where the manual version stops working

The spreadsheet-and-domain-match approach holds up fine until an inbox crosses a few thresholds:

• The customer list goes stale. New signups, cancellations, and plan changes don't update the sheet on their own, and a week of drift produces false negatives on real customers who now look "unmatched."
• Volume outruns manual review. Ten unmatched emails a day is a coffee-break task. Fifty is a part-time job, and reviewing them is the first habit that slips once the team gets busy with anything else.
• A yes-or-no match still doesn't answer the question that matters. Knowing a sender is a customer doesn't tell you whether three other people at the same account already asked for the same thing, or whether that account is up for renewal next quarter, the context that actually decides whether a request gets built.

That third gap is where we pick up. Modem gives a workspace a dedicated inbound address: forward founders@ or support@ to it, one message at a time or in bulk, and every email is checked against the people and companies Modem already knows from every other connected source, not a static list someone remembers to update. A message from a known account joins that customer's existing topic, with the requester and their company attached. A message from an unrecognized sender is flagged as unmatched rather than tagged as a request on faith. Setup is covered on the email integration page. Modem is what we build, so treat that as a disclosed interest, not neutral advice; for a two-person rotation checking founders@ once a day, the spreadsheet from the previous section is genuinely sufficient, and there's no reason to add a tool before the manual version actually breaks.

For the layer that sits just before this one, deciding what counts as a loggable request once you already know who's asking, see how to forward feature-request emails from a support alias into Linear. And once requests are landing on the right side of the split but getting stepped on by more than one teammate, avoiding duplicate replies in a shared support inbox covers the next failure mode in the same inbox.

The twenty-minute rule to add this week

Pull a list of active customer domains from wherever billing or auth keeps them, and add one Front or Gmail rule: unmatched senders using request-shaped language get tagged needs-review instead of feature-request. That single rule catches the cold pitch and lets the real customer request through clean, and it costs about twenty minutes to build.