A recurring customer issue is the same underlying problem showing up in more than one conversation, from one customer or from many. The fix for it is almost never an agent. It's a help article, a bug, a policy or a screen, and someone outside the queue has to change it.
This guide is the workflow for getting from "customers keep writing in about this" to a named owner with evidence. For the metric itself, see repeat contact rate.
Coming soon: Supportman will connect related Intercom conversations so recurring issues surface without a manual tag audit. Get notified at launch.
Repeat customer or recurring issue?
Two different patterns get called "repeats", and they point at different fixes.
| Pattern | What you see | It usually means |
|---|---|---|
| One customer, same issue, again | A customer's second conversation matches their first | The first fix didn't hold, or the customer never believed it was fixed |
| Many customers, same issue | The same intent keeps appearing across different people | A gap in docs, product or policy that every customer hits |
A customer who writes twice about different things isn't a repeat. Matching on the customer alone inflates the number, which is the false-positive problem covered in repeat contact rate. You need the issue to match too.
The intent-tag scheme
Everything below depends on one consistent label per conversation. Intercom's conversation topics can suggest groupings, and a short tag list of your own is what makes the matching reliable.
- Keep it to about 15 intents. Past that, agents choose inconsistently and the same problem gets three names.
- Name the problem, not the department. "CSV export fails" is an intent. "Technical" is not.
- One primary intent per conversation, applied at close.
- Cap "other" at about 10% of volume. If it grows past that, an intent is missing. Read the "other" pile monthly and promote the biggest cluster.
- Rename in one place. A tag that's been split or merged mid-quarter breaks every trend line that includes it.
Why rank intents by repeat share, not volume?
Volume tells you where the work is. Repeat share tells you where the fix isn't holding. Hypothetical month, two intents:
| Intent | Closed | Same-issue repeats within 14 days | Repeat share |
|---|---|---|---|
| Password reset | 120 | 6 | 5% |
| CSV export fails | 40 | 14 | 35% |
The numbers are made up to show the arithmetic. Ranked by volume, password reset comes first and CSV export looks small. Ranked by repeat share (14 ÷ 40 = 35%), CSV export is the one where customers come back, so it's the one to take to engineering. Show both columns, and decide the window first.
The repeat-issue log
One row per recurring issue, not per conversation.
| Column | What goes in it |
|---|---|
| Intent | The tag from your list |
| First seen | Date of the earliest conversation |
| Conversations / customers | Both counts. Many conversations from few customers is a different problem from the reverse |
| Example links | Three conversations that show it clearly |
| What customers were told | The answer being given now |
| Suspected cause | Docs, product, policy, agent accuracy or unknown |
| Owner outside support | A person who can change it |
| Status | Reported, accepted, fixed, or declined, with the date |
"What customers were told" is the column that makes the case. If the answer in the macro is the answer that isn't working, the owner can see it without reading ten threads.
The routing table
| What the data shows | Likely owner | Evidence to bring |
|---|---|---|
| Many customers, same question, the answer exists | Help center owner | Search terms customers used, the article they didn't find, the intent count |
| Many customers, same failure after a release | Engineering or product | First-seen date next to the release date, three example links |
| Customers disagreeing with a decision | Policy owner | The rule as written, the exceptions agents are making, the DSAT on these |
| One customer, same issue repeatedly | Support lead | What the customer was told each time, and whether it was the same answer |
| Same intent, different answers from different agents | QA and coaching | Two or three conversations side by side. See the QA rubric guide |
| Fin closing the intent and customers returning | Fin owner | The Fin conversations and the follow-ups. See how to QA Intercom Fin |
A rising repeat share on one intent is usually a content or product gap, not a skill gap. Check the help article and the macro before coaching anyone.
The monthly review
Forty-five minutes, with someone from product or engineering invited for the second half.
- Top five intents by repeat share, with volume beside each.
- New entries in the log since last time.
- Status changes. What was fixed, and did the repeat share fall afterwards?
- The "other" pile. Is an intent missing?
- One decision per issue: accept, decline with a reason, or ask for more evidence.
Step three is the one that proves the process works. A fix that doesn't move the repeat share wasn't the fix, and that's useful to know. For the ratings side of the same review, see DSAT root cause analysis.
What can Supportman do today?
Supportman doesn't detect recurring issues yet. It posts each Intercom rating to Slack as it lands, routes low ratings to their own channel, and scores closed conversations against your QA rubric, which gives you conversations to read for the "same intent, different answers" row above. Connecting related conversations to surface recurring issues is coming soon.
Frequently asked questions
What is a recurring customer issue?
The same underlying problem appearing in more than one conversation, from one customer or from many. It's different from a customer simply contacting support twice about unrelated things.
What are repeat tickets?
Tickets or conversations that return to a problem already handled, either on the same thread or as a new one. Counting them requires matching on the issue as well as the customer. See repeat contact rate.
How many intent tags should we use?
About 15. Fewer hides real problems inside broad buckets. More makes agents choose inconsistently, and the same problem ends up under several names.
Who fixes a recurring issue?
Whoever owns the cause: the help center owner for docs, engineering for bugs, a policy owner for rules. Support's job is to bring evidence and track whether the fix moved the repeat share.
How often should we review recurring issues?
Monthly for the full review. Add a quick weekly look at any intent whose volume spiked, since a release can create a recurring issue within days.