Can JQL Search for Feedback from a Specific Customer
Not reliably, no. JQL can search the text of an issue (summary, description, comment) and it can search structured fields like reporter, but Jira issues don't have a field called "customer" or "account" on them by default. So a query like text ~ "Acme Corp" only finds issues where someone happened to type those exact two words somewhere in the ticket. It misses the issue where a support engineer wrote "the customer from Acme" instead, the one where they abbreviated it "Acme Corp." with a period, and every issue where the company name never got typed in at all because the reporter was an internal engineer relaying a bug.
The honest answer is that JQL is good at exactly what it's built for, matching structured field values and literal text strings. It was never built to know that "Acme," "Acme Corp," and "acme.com" are the same account, and it has no concept of an account that spans more than one issue unless a human built that concept themselves with a custom field. What follows is what JQL actually searches, the three ways teams try to close the gap, and where each one stops holding up.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhat JQL actually searches when you type in a customer name
JQL's text search runs on the text field, which is shorthand for searching several fields at once, summary, description, environment, comments, and any unlimited-text custom fields, all with the ~ (CONTAINS) operator. Atlassian's own documentation on the text field confirms this is literal keyword matching. text ~ "renewal" finds the word "renewal," wildcards like text ~ "renew*" catch variants, and quoting a phrase matches the exact phrase. None of that is semantic. It doesn't know synonyms, it doesn't normalize a company name written three different ways across three tickets, and it can't tell you when a name is missing entirely because nobody typed it.
Structured fields are the reliable half of JQL, and reporter is the most relevant one here. reporter = "dana@acme.com" returns exactly the issues that one person filed, no ambiguity. But reporter is a single user, not an account. If three people at Acme file three separate tickets, reporter = has to be run three times, or turned into reporter in (...), and someone still has to maintain that list of email addresses by hand as employees join and leave the account.
If you're specifically working inside Jira Service Management rather than plain Jira Software, there is a structured customer concept: the Organizations field, which groups a company's portal users and lets you filter service requests by organization. It's a real, working field, but it's scoped to one service project at a time and doesn't reach into Jira Software issues that were never filed through a portal. That's a different enough setup that it gets its own guide rather than a paragraph here.
The three ways teams try to close the gap
None of these are wrong. Each one just has a specific, predictable ceiling.
- Search harder. Try every spelling variant of the account name across
text ~,summary ~, andcomment ~, and OR them together. This finds more than a single query, but it's a guessing game against however many ways a name gets typed, and it never finds the issue where the name was never typed at all. - Query the reporter. Reliable for one person, and reliable for a hand-maintained list of people, but it silently misses anyone hired after the list was built, and it says nothing about issues where the account's name shows up in a comment from someone else, like a support engineer relaying the report.
- Build a custom field. Add a single-select or label field, "Account," populate it on every new issue, and now
"Account" = "Acme Corp"is a real structured query with none of the guessing above. This is the option that actually works as advertised. It's also the same gap that marketplace apps are built to sell into: a Community write-up from Avisi Apps, maker of the Atlas CRM app, makes the vendor's case for its own product by pointing at the same root issue, standard Jira fields don't carry account context from other systems, so a custom field (or a connected app that supplies one) is what native JQL needs before it can query by customer at all.
Where this gap shows up in practice
For example, a support engineering team at a smart-meter monitoring vendor keeps its Jira project simple, a bug and feature-request issue type, no customer field, no JSM portal, just an internal tracker fed by support tickets and the occasional customer call.
In August, a field technician at Coldwater Municipal Utilities reported that meter readings from one neighborhood were coming in a full day late. A support engineer filed a ticket with the summary "delayed reads, Coldwater district 4." Three weeks later, a different Coldwater contact called in about the same lag on a different street, and a second engineer filed a second ticket, summary "readings arriving 24h behind expected," with no mention of Coldwater anywhere in the summary, description, or comments, because the engineer troubleshooting the timestamp logic never wrote the customer's name down at all.
Checking whether this was a recurring Coldwater problem ahead of a renewal call meant running text ~ "Coldwater". That returned the first ticket and nothing else. The second ticket, filed three weeks later for the same root cause, surfaced only because someone happened to mention the timestamp bug out loud in an unrelated sprint retro two months on, and by then the renewal call had already gone ahead with half the account's history missing.
The fix afterward was the custom field: an "Account" select list, added to the project and made required on new issues. It works going forward. It does nothing for that second ticket, which still has no account attached and will never show up in an "Account" = "Coldwater Municipal Utilities" query unless someone opens it and fixes the field by hand.
Where the custom field still runs out
A required custom field, populated consistently, is a genuinely reliable JQL query. It has three limits worth knowing before you rely on it:
- It only covers issues filed after you added it. Every backdated report, like that second Coldwater ticket, needs a manual backfill or it stays invisible to the field forever.
- "Required" is enforced at issue creation, not everywhere issues get created from. Automation rules, email-in issue creation, and bulk imports can all skip a required field depending on how they're configured, so the field's coverage is only as good as every path that creates an issue.
- It only knows about Jira. The same customer's complaint sitting in a support ticket or a Slack thread that never became a Jira issue doesn't exist in this view at all, and JQL has no way to reach outside Jira to find it.
That last point is the one that doesn't have a JQL-side fix, because the missing data isn't in Jira to begin with.
Where this stops working and what to look at next
Once an account's history is split across a Jira custom field, a support tool, and however many Slack threads mentioned them, no amount of better JQL closes the gap, because JQL only ever searches what's inside Jira. This is the layer Modem is built for. Modem's Jira integration watches your connected projects the same way a custom field would, but it also reads Slack, support tickets, and calls, matches the different ways one account gets mentioned across all of them, and keeps every issue, ticket, and thread attached to one company record automatically, no required field, no backfill, no name variant to guess at. Ask "everything from Coldwater Municipal Utilities" and it answers from that record instead of from whatever got typed into a field correctly. Modem is what we build. Read that claim the way you'd read any vendor describing their own product. What matters is the specific gap described above, not how convincing the pitch sounds.
If your Jira volume is small enough that one person can hold the account list in their head, you don't need any of that. The custom field covered earlier already closes the gap, and it's the simpler thing to build. The related problem of a single bug hitting several accounts, rather than one account across several issues, is covered in how to see which customers are affected by a Jira bug.
The smallest version you can start this week
Add a required "Account" field to your project today, and run one audit. Pick your three highest-volume accounts and search text ~ for each of their names across your last quarter of issues. Whatever the custom field would have caught that the text search missed is exactly the size of the gap this guide describes, and for most teams it's larger than the one ticket they went looking for.
