How an AI Agent Should Recognize a Repeat-Contact "Frequent Flyer" Customer

Quick answer

An AI agent needs a way to recognize, at the start of a new session, that this same customer contacted about this same unresolved issue in a prior, separate session, and to change its behavior accordingly: skip repeating troubleshooting steps that already failed, acknowledge the history directly rather than treating the customer as new, and lower the threshold for escalating to a human sooner than it would for a genuinely first-time contact. This requires linking sessions by customer identity and issue similarity, not just by a single conversation's context window, which is a different capability than single-session memory or single-session sentiment tracking.

Why this is a distinct pattern from single-session escalation

Most AI agent quality work focuses on getting a single conversation right: detecting frustration within one session (see detecting and de-escalating an upset customer mid-conversation) or measuring how often a single conversation ends without resolution (see measuring and reducing mid-conversation abandonment). Both of those are valuable but operate entirely within one session's boundaries.

The "frequent flyer" pattern is different: a customer who contacted about an issue, appeared to accept a resolution or simply gave up and left, and then comes back, in a wholly separate session, hours or days later, still stuck on the same underlying issue. Within either individual session, nothing looks unusual; sentiment might even be neutral, and abandonment metrics on either session alone might look fine. The pattern only becomes visible by connecting sessions together, and an agent that treats each session as an isolated, first-time contact will keep repeating the same first-contact playbook on someone for whom that playbook has already demonstrably failed at least once.

Why repeating the same playbook is actively harmful here

The natural default behavior, treating every new session as a blank slate and running the standard troubleshooting flow from the top, is actively counterproductive for a repeat-contact customer. It signals, whether intended or not, that the company has no memory of the customer's prior effort, forces them to re-explain a problem they already explained once, and re-runs steps they likely already tried and reported as unsuccessful. Each of these individually erodes trust; together, across a second or third repeat contact, they read as a company that either doesn't track its own support history or doesn't care to.

Detecting the pattern: linking sessions by identity and issue similarity

Two pieces of matching are needed to detect this reliably: identity linking (recognizing this is the same customer across sessions, via account ID, authenticated login, or another reliable identifier, not just a device or browser fingerprint) and issue linking (recognizing the new session's topic is the same or closely related to a recent unresolved prior session, not just any prior contact). Issue linking is the harder of the two, since customers rarely describe the same problem in identical words twice; a reasonable approach compares the current session's detected intent or topic category against recent prior sessions' topic categories for the same customer, rather than requiring an exact text match.

A practical threshold worth setting explicitly: how recent does a prior contact need to be, and how similar does the issue need to be, to count as a repeat contact worth flagging? Too loose a threshold creates false positives (flagging unrelated contacts as repeats); too tight a threshold misses real repeats that were phrased differently the second time. This threshold should be tuned against real data and revisited periodically rather than picked once and left alone.

Changing behavior once a repeat contact is detected

Once flagged, a few concrete behavior changes matter:

• Acknowledge the history directly and specifically, not with a generic "I see you've contacted us before" but with a concrete reference to what happened last time, framed as continuity rather than as a scolding recap ("Last time we tried resetting your sync settings and that didn't fix it, so let's try something different this time").
• Skip steps already tried and reported as unsuccessful. Repeating a failed step wastes the customer's time and reinforces the impression that nothing was actually recorded from the prior contact.
• Lower the escalation threshold. A genuinely first-time contact deserves a full attempt at automated resolution before escalating. A customer on their second or third unresolved contact for the same issue has already demonstrated that automated resolution has not worked for them, and the bar for handing them to a human, or at minimum flagging the case as needing closer attention, should be correspondingly lower.
• Flag the pattern internally even if the current session does resolve successfully. A customer who needed three attempts to get an issue fixed represents a worse experience than the resolution-rate metric alone would suggest, and is worth surfacing to whoever owns the underlying product or process issue that caused the repeat contacts in the first place, since a real fix there prevents the next customer from needing three attempts too.

This is a segment-level pattern, not just an individual one

Beyond changing behavior for the individual customer in the moment, tracking how often the repeat-contact pattern occurs, and for which issue types, is itself a valuable signal. An issue type that generates an unusually high rate of repeat contacts is very likely a signal of an underlying product or process problem the agent cannot actually resolve on its own, regardless of how the agent's conversational behavior is tuned. This connects to the broader question of when an agent is underperforming in a specific, identifiable way, covered in handling an AI agent that performs well overall but poorly for one segment or geography: a high repeat-contact rate concentrated on one issue type is exactly the kind of segment-specific underperformance that an aggregate quality metric can hide.

Balance recognition with privacy and creepiness

Referencing prior contact history needs to feel like continuity of service, not surveillance. Referencing something the customer would reasonably expect the company to remember (a recent, related support contact) reads as competent; referencing something unrelated or from far enough in the past that the customer would not expect it to be recalled can read as unsettling. Calibrate what gets surfaced back to the customer versus what stays purely as internal routing signal accordingly.

FAQ

How is this different from just having conversation memory within one long chat? Single-session memory only covers one continuous conversation. This pattern requires linking genuinely separate sessions, potentially hours or days apart, by customer identity and issue similarity, which is a different, additional capability.

Should the agent explicitly tell the customer "I see this is your Nth contact about this"? A specific, contextual reference to what was tried before is usually better received than a numbered callout of how many times they've contacted, which can read as keeping score against the customer rather than helping them.

What threshold should trigger repeat-contact handling? There is no universal number; it depends on typical resolution timelines for your product and issue types. Start with a deliberately chosen threshold, monitor for false positives and misses, and adjust rather than treating the first guess as final.

Does detecting this pattern replace the need to fix the underlying issue? No. Detecting and handling repeat contacts well improves the experience for customers stuck in the pattern, but a high repeat-contact rate for a specific issue type is a signal that the underlying product or process problem needs a real fix, not just better conversational handling around it.