How to Tell If a Jira Bug Was Reported by a Real Customer or Is Internal Tech Debt
Check the Reporter field last, not first. It tells you who typed the ticket into Jira, and in most shops that's an engineer or a support agent whether the bug came from a customer or not, because the people actually hitting the bug usually don't have a Jira Software seat to file it themselves. The signal that actually holds up is whether the bug traces back to something outside Jira: a linked service request, a support ticket number in the description, a company name anywhere in the thread. If none of that exists, and the reporter is someone on the engineering team with no external reference attached, you're almost certainly looking at internally generated work, a refactor cleanup, a QA sweep finding, a thing someone noticed while reading code.
That's the whole distinction, and it holds up because of a structural fact about how Jira is set up at most companies. Jira Software, the place bugs live, wasn't built for customers to file into directly. Customers who have any access at all usually go through a Jira Service Management portal, a support tool, or a person, and someone on staff re-files the bug in Jira Software afterward. That re-filing step is exactly where the origin gets lost unless it's deliberately preserved, and Reporter alone never preserves it. Here's what to actually check, and where the workaround stops holding up.
Why Reporter answers the wrong question
Jira's Reporter field is a standard field on every issue. It's editable, so it shows whoever is currently listed as having filed that specific ticket in that specific project, not necessarily whoever typed it in first, and it says nothing about who asked for it to exist. Three people can produce the exact same Reporter value for different reasons:
- A support engineer files a bug after a customer describes a problem in a call, because the customer has no Jira access at all.
- The same support engineer files a second bug purely because they noticed something odd while investigating the first one, unrelated to what the customer reported.
- An engineer, mid-refactor, files a third bug against their own code because they spotted a bug nobody has complained about yet.
All three show the same person as Reporter. Nothing about the field distinguishes "relaying a real complaint" from "noticing something on my own." If your team runs bugs through a single Jira Software project without a service desk in front of it, that's the whole problem. The field everyone checks first was never built to answer this question.
The signal that actually works: what the bug links to
Teams running Jira Service Management alongside Jira Software already have a real answer sitting one click away, they just don't always know to check it. The standard pattern for turning a customer's service request into engineering work is to create a separate development issue and link it back with a relates to connection, rather than moving or converting the original request, which would break the customer's portal access. That linking pattern is covered in detail in how to convert a Jira Service Management ticket into a development issue without losing the thread, and the mechanism matters here for a different reason. That link is the closest thing to proof of origin a Jira bug can carry.
A bug with a relates to link pointing at a JSM request came from somewhere outside the engineering team. A bug with no such link, no support ticket number pasted into the description, and no company name anywhere in the thread almost certainly didn't. It's not a perfect test, a rushed handoff can skip the link, but it's a real signal instead of a guess, and it costs nothing to check. Open the Linked Issues panel before you assume either direction.
“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 NotionA Source field for teams without a service desk in front of Jira
Not every team runs JSM. If support, sales, and engineering all file directly into one Jira Software project, there's no linked request to check, and the fix is the same kind of lightweight convention other teams use for adjacent gaps: a custom field, seeded honestly, with a rule for who sets it.
- Add a single-select custom field called
Source, with two values:Customer-reportedandInternal. Keep it to two values; a third "unclear" option becomes the default everyone reaches for under time pressure, which defeats the purpose. - Set it at filing time, not after. Whoever creates the bug picks the value as part of filing, the same way they'd pick an issue type. If the origin is genuinely unclear, that's information too, don't leave the field blank and treat blank as internal by accident.
- Automate it where you can. Jira's automation rules include an Edit work item action that can set a field's value, including a label or select field, when a rule condition matches. If bugs from your support tool arrive through a specific intake project or a recognizable prefix in the summary, a rule can set
Source: Customer-reportedautomatically instead of relying on someone remembering. - Require the company name in the description whenever
SourceisCustomer-reported. A checkbox without a name attached tells you a customer was involved and nothing about which one, which matters the moment two customers are affected by the same bug and only one gets mentioned.
Where the field and the link both stop working
Both mechanisms, the JSM link and the manual Source field, share the same failure mode. They depend on a person making the connection at the moment of filing, and that moment is usually the least convenient time to do careful bookkeeping.
- Under deadline pressure, the link gets skipped. An engineer chasing a fix during an incident creates the dev bug straight from memory of the customer call and never goes back to link the originating ticket.
- A
Sourcefield only reflects what the filer knew. If a support agent relays a bug without realizing three other customers already hit the same thing through different channels, the field says "one customer," not "recurring," and nobody bumps it later unless someone happens to notice. - The check doesn't scale past the person doing it. Checking Linked Issues by hand works when one or two people triage the backlog. It stops working once five people are filing bugs from five different intake paths and nobody has time to click through every one before sprint planning.
When nobody has time to click through every linked issue before sprint planning, this becomes the same problem as seeing which customers are affected by a Jira bug. A real signal exists, but it only surfaces if someone remembers to record it, every time, across every channel a report might arrive through.
Where Modem picks this up
Recording it without depending on that memory is what Modem is built for. Modem's Jira integration watches the projects you connect and pulls in the standard fields, including Reporter, but it doesn't stop at what Jira itself recorded. Modem also reads Slack, support tickets, and calls, and when a bug traces back to one of those conversations, that origin travels with it as a topic, a real customer, a real company, a real quote, rather than depending on whether someone remembered to add a relates to link or fill in a Source field before moving on. Ask an agent whether DRFT-511 came from a customer or from internal QA, and it answers from what it actually read, not from a field that was only ever as reliable as the person who set it.
Modem is also what we sell. Judge it against the specific gap above, whether your team's bug intake already has a working link-or-label habit that survives deadline pressure, not against the pitch. Below that threshold, the JSM-link check or a two-value Source field is a real answer and costs nothing to set up. If you want to see how other tools in this space handle the same job, best tools to turn customer feedback into Jira tickets lines up the field.
Try it on your own backlog
Pull up five bugs at random from your current sprint. For each one, check Linked Issues for a JSM request, then search the description for a company name. Count how many have neither. That number is roughly how many bugs in your backlog are getting prioritized on engineering judgment alone, whether or not that's the label anyone actually put on them.
