What is Returning Customer Detection?

Returning Customer Detection prevents the most expensive failure mode in customer support: the same person, the same issue, three different conversation threads. When a customer who already has an open or recently resolved conversation contacts you again, Atender recognises them, asks one short clarification, and either appends to their existing thread or creates a new conversation as you’d configured.

The result: one issue, one thread. Agents see the full history. Customers don’t repeat themselves. Conversation counts reflect real issues, not duplicate contacts.

How a returning contact is handled

1. Detection — the customer is identified by phone number (Voice / SMS), session or authenticated identity (Web Chat), or email address (Email).
2. Match — Atender looks for the customer’s recent conversations within a configurable threshold (default: the last 24 hours).
3. Clarification — the customer is asked, in their channel’s appropriate format: Is this about the same issue, or something new? On Phone and SMS this is a press-1 / press-2 prompt; on Web Chat and Email it’s a message asking them to choose.
4. Action — based on the answer, Atender either appends the new contact to the existing thread, starts a new conversation, or — if the customer doesn’t answer in time — falls back to a configured timeout action.

Cross-channel by design

Detection works across channels per identifier. A customer who emailed yesterday and calls today about the same issue gets connected to the same conversation. The phone caller ID matched the email contact, so Atender knew it was the same person.

• Voice — Caller ID (phone number)
• SMS — Phone number
• Web Chat — Session / authenticated identity
• Email — Email address

What “recent” means

Each channel has its own threshold (default 24 hours, configurable in minutes). Conversations resolved within the threshold are eligible to be reopened; older ones aren’t. The threshold is per channel because the right window is different — a 24-hour threshold makes sense for chat; some teams want 7 days for email.

Configurable triggers

You decide which previous-conversation states count as “the customer is returning.” Per channel, you can include:

• Unanswered — they reached out before, didn’t get a response, and are reaching out again
• Resolved within threshold — they got a response, the conversation was marked Done recently, and they’re following up
• Snoozed — they have an open conversation that’s currently snoozed

Most teams enable all three for chat and email, and tune phone separately.

What happens if they don’t respond to the prompt

Real customers sometimes don’t follow press-1 / press-2 prompts. The timeout action decides what to do when the clarification times out:

• Do nothing — The new contact starts a fresh conversation — same as if detection were off.
• Add to existing conversation — Append the new contact to the matched conversation by default. Safer when most returning customers are following up on the same issue.
• Create new conversation — Start a new conversation by default. Safer when most contacts that look “returning” are actually unrelated.

Pick whichever default best fits your team’s pattern. You can change it per channel.

Why it matters

For high-volume teams with longer resolution times — anywhere a case can take days to resolve — customers naturally follow up. Without detection, every follow-up creates a new conversation, fragmenting context across threads. With detection:

• One issue, one thread — agents see the full picture
• No “can you explain again?” — the customer doesn’t have to retell their issue
• Conversation metrics reflect real issues, not contact volume
• Cross-channel handoffs are seamless — emailing then calling about the same thing keeps both contacts together

Where to start

• Configure it: Configure returning customer detection
• Common issues: FAQ — customer keeps creating new conversations