How to Search Years of Old Support Emails for a Recurring Feature Request

You find it by combining date-range operators with an OR across every phrasing you can think of, then running the search again for the phrasings you didn't think of the first time. A shared support inbox, whether that's a Gmail address run by delegation, a Google Group's collaborative inbox, or a plain forwarding alias, keeps every message it has ever received. Nothing ages out on its own. The obstacle isn't retention; it's that search only matches the words someone actually typed, and a request that's come up for three years has almost certainly been typed three different ways.

That means there's no single query that returns "every time anyone asked for this." There's a query you build once, bound with older_than: or after:, widen with OR across your best guesses at wording, and rerun the next time someone remembers a fourth phrasing a customer once used. Below is the operator syntax that gets you there, what a collaborative inbox adds on top of raw search, and the point where rerunning that query by hand stops being worth doing yourself.

“we need SSO before rollout”

“any update on single sign-on?”

“SSO came up twice on this call”

↓ classified + deduped into

SSO requests

8 accounts asking · quotes kept

filesLinear issue, quotes attached

writesinsight report in Notion

answersyour agents

Why the inbox works against you as it ages

Three things compound the longer a request has been sitting in your history, and none of them are about how much mail your account can hold.

• Subject lines drift. A "Re:" chain from 2023 gets forwarded into a new thread in 2024 with a fresh subject, and whatever kept the two connected in someone's head doesn't survive the handoff.
• The phrasing changes with the person asking. A developer asks for "SIEM integration," a compliance lead asks to "get our logs into Splunk," and an ops manager asks if you can "export the access history." Same request, three vocabularies, no shared keyword between them.
• Departed teammates take their memory with them. The one agent who remembers handling this exact question two years ago left the company last spring. Whatever thread they were thinking of is still in the mailbox, but the "oh yeah, this has come up before" instinct that would have surfaced it left with them.

None of that shows up as a gap until someone specifically needs the answer to "has this come up before, and how often," and finds that the answer takes actually looking, not just remembering.

The search that actually gets you there

If the shared inbox runs on Gmail, whether through delegated access to a single support login or a Google Group's collaborative inbox, the tool for this job is Gmail's own advanced search operators. Four of them do almost all the work:

• Quotation marks for an exact phrase: "audit log export" matches only that wording, not the words scattered anywhere in a message.
• OR, or the bracketed shorthand { }, to check several phrasings in one search: "SIEM" OR "Splunk" OR "audit log".
• older_than: and newer_than:, using d, m, or y for day, month, or year, to bound the window instead of scrolling a chronological list by hand.
• after: and before:, in YYYY/MM/DD format, when you want a specific date range rather than a rolling one.

Stacked together, a real query looks like ("SIEM" OR "Splunk" OR "audit log" OR "access logs") older_than:1d newer_than:3y. That returns every message in the window containing any of the four phrasings, in one pass, instead of four separate searches.

If the inbox is a Google Group's collaborative inbox specifically, Google's own documentation describes real team features on top of that: conversations can be assigned to a member, marked complete or marked as a duplicate of another conversation, filtered by assignment or resolution status, and organized with labels independent of both. Those are useful going forward, for keeping five new mentions of the same request from turning into five untracked threads. None of them retroactively find what's already buried in three years of history that predates the labels existing. For that, the search above is still the tool, run once per phrasing you can think of.

Where the manual search stops scaling

The search above is genuinely the right tool for an occasional, high-stakes question like this one, worth the twenty minutes it takes when the situation calls for it. It stops being the right tool at a few predictable points.

• It only runs when someone remembers to run it. Nothing prompts the search. If the renewal conversation that sent you looking had gone differently, that history would have stayed buried until the next time it happened to matter.
• The phrasing list is never complete. A query only catches the wordings you put in it. A customer who wrote "let us pull our own logs" wouldn't have matched any of the four terms above, and there's no way to know how many of those are still sitting uncounted.
• It answers "how many emails," not "how many customers." A double-count is easy to miss by eye: if one account had emailed twice, the raw hit count would overstate the interest without a second pass to check.
• Every recurrence starts the search over. There's no running total that carries forward. The next time this comes up, someone reruns the same query from scratch, hoping they remember the same phrasings that worked the last time.

None of that is a criticism of the search operators themselves; they did exactly what they're built to do. The gap is that nothing between searches keeps a standing count, which means the answer to "has this come up before" always depends on someone deciding to go look.

Where Modem picks this up

Modem is built to keep that standing count. Its email integration gives a workspace a dedicated inbound address; forwarding the backlog to it, in bulk or one at a time, gets every past mention grouped into topics on what it actually says, not on a keyword match, and every new email that arrives afterward joins the same running topic automatically. Differently worded emails, an "access logs" request from years back, a later follow-up mentioning Splunk, and an audit-trail question this month, would land as one topic with every account attached rather than separate threads someone has to notice are related. Sender addresses link across channels too, so if the same request also showed up in a sales call or a Slack message, it joins the same count instead of starting a second one. This is our product, which is reason enough to read the comparison skeptically instead of taking the pitch at face value. Put plainly: if "how many times has this actually come up" is still an occasional, high-stakes question you can answer with twenty minutes of manual search, stay there, the search above already gets you that for free. Modem starts doing work a person cannot once that question turns into a running total you need on tap.

The adjacent failure mode, a reply to an already-resolved thread carrying a brand-new request that gets buried under the old thread's tag, is covered separately in stopping new feature requests from hiding inside resolved email threads.

The one search to run before your next roadmap conversation

Write down every phrasing you can think of for the request in question, three or four is usually enough to start, and run one query: the terms joined with OR, bounded with older_than: for however far back your inbox goes. Whatever comes back is the real count for the phrasings you thought of. Whatever a departed teammate might have phrased differently is the reason to treat that number as a floor, not a ceiling.