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.
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 honest 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:andnewer_than:, usingd,m, oryfor day, month, or year, to bound the window instead of scrolling a chronological list by hand.after:andbefore:, inYYYY/MM/DDformat, 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.
If your shared inbox is Front rather than Gmail, the search-and-mass-action version of this same idea is covered in applying tags retroactively to old support emails in Front, which walks the equivalent operators for that tool.
What three years of BrightPath's inbox actually said about Splunk
Winnie Sokol had been fielding the shared Gmail inbox at BrightPath Care, delegated access the whole team reads through, for two years when a renewal call went sideways this week. The customer wasn't complaining so much as comparing:
Customer, on a call: We're seriously evaluating [a competitor] for the renewal, mostly because of the audit trail export. If BrightPath had that, this conversation would be a lot shorter.
BrightPath sells scheduling software to home health agencies, which is exactly the kind of account a missing export feature can lose. Before she took that line to the product team, Winnie wanted to know whether it was a new complaint or an old one nobody had connected. She searched the shared inbox, narrowing to the three years before today so this week's own call didn't pad the count: ("SIEM" OR "Splunk" OR "audit log" OR "access logs") older_than:1d newer_than:3y.
Five results came back, spanning three years and four different agencies:
Email, 2024: Any way to pull our access logs out programmatically? Compliance wants them in our own SIEM eventually, not urgent yet.
Email, 2025: Following up on the Splunk question I think someone here asked last year, is this anywhere on the roadmap now?
Email, this month: We're looking at exporting our audit trail for an internal security review. Does BrightPath support that today?
The 2025 message was the giveaway. It referenced a "Splunk question... last year" that nobody currently on the team remembered, filed under a subject line that just read "quick question," from an agent who left BrightPath eighteen months earlier. Without the search, that thread would have stayed real, on-topic, and invisible, exactly where it had been sitting since 2025.
Four separate agencies, three years, one request. That's the write-up Winnie brought to the roadmap conversation, and it's a materially different pitch than "a customer mentioned this on a call today."
Where the manual search stops scaling
The search above is genuinely the right tool for an occasional, high-stakes question like Winnie's, 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 competitor conversation this week had gone differently, the five-email history would have stayed buried until the next time it happened to matter.
- The phrasing list is never complete. Winnie's four terms caught five emails. A sixth customer who wrote "let us pull our own logs" wouldn't have matched any of them, 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 of those four agencies 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 four phrasings Winnie used.
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
That's the layer Modem is built for. 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 classified on what it actually says, not on a keyword match, and every new email that arrives afterward joins the same running topic automatically. Winnie's four differently worded emails, an "access logs" request in 2024, a follow-up mentioning Splunk in 2025, and an audit-trail question this month, would land as one topic with four accounts attached rather than five 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. Here's the honest line: 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 earning its keep 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 honest reason to treat that number as a floor, not a ceiling.
