Engagement state — pending vs engaged

Conversation state in Atender has two independent axes:

• Lifecycle status — Active / Snoozed / Done / Archived — Where in the lifecycle is it?
• Engagement state — Pending / Engaged — Whose court is the ball in right now?

These are orthogonal — every Active conversation is also either Pending or Engaged. The two together tell you what to actually work on.

What each engagement state means

• Pending — Ball is in our court. The customer has spoken and we haven’t (yet) responded since their last message. — Reply, snooze with intent, or escalate
• Engaged — Ball is in the customer’s court. We’ve replied since their last message; we’re waiting on them. — Wait, follow up if they go silent, or close out if appropriate

A conversation flips between Pending and Engaged automatically as messages flow:

• Customer sends a message → flips to Pending
• Agent replies → flips to Engaged
• Customer replies → flips back to Pending
• And so on

Why this matters

The lifecycle status alone (Active / Snoozed / Done) doesn’t tell you the most important question: do I need to reply right now? You can have 200 Active conversations where 180 are Engaged (we already replied) and only 20 are Pending (waiting on us).

If you sort by Pending, you immediately see the work that needs you vs the work that’s waiting for the customer. This is the difference between drowning in your inbox and knowing what to focus on.

How engagement is computed

Engagement is deterministic — Atender computes it automatically by walking the conversation timeline, newest first, and stopping at the first signal that says one side or the other holds the ball. There’s no manual override. The rules in plain English:

• A conversation starts Pending when the customer’s first message arrives.
• Last meaningful event was an agent message → Engaged.
• Last meaningful event was a customer message → Pending.
• An assignment, team change, or AI handoff event leaves the conversation Pending — somebody on our side now owns it but hasn’t replied yet.
• For voice: customer_answered and call_answered count as Engaged (both parties active on a call).
• Automation-generated messages tagged isAutomated: true are skipped when classifying. They don’t flip the conversation to Engaged; the classifier looks past them to the previous human signal.

Snoozed and Done conversations also have engagement state — it’s just less actionable on a moment-to-moment basis. A Done + Engaged conversation is “we said our piece, customer hasn’t replied”; a Done + Pending conversation is “customer wrote back and reopened our reply, but we haven’t said anything to the new message yet.”

Don’t confuse engagement with status

Easy mistake: treating “Active” as the same as “Pending.”

• Active = lifecycle bucket. Conversation is alive, not closed.
• Pending = engagement state. We owe a reply.

Most Pending conversations are also Active. But:

• An Active + Engaged conversation is alive but waiting on the customer
• A Done + Pending conversation has been reopened by the customer but you haven’t responded yet

The two-axis model makes this visible. Your sort and filter combinations get more powerful when you can target one or the other or both.

Filtering by engagement

Common patterns:

• Active + Pending — Conversations needing a reply right now
• Active + Engaged — Conversations waiting on the customer; no action needed
• Done + Pending — Reopened conversations needing fresh attention (customer replied to a Done, you haven’t yet)
• All Pending across statuses — The full “owe a reply” list — useful for end-of-day cleanup

The conversation list lets you filter by engagement. Save the combinations you reach for as named saved filters.

A common gotcha — automation messages

Atender deliberately skips automation messages when computing engagement. The signal it uses is the isAutomated flag on the outbound message — if the flag is set, the classifier looks past that message to the previous human exchange. Auto-acknowledgements, CSAT-trigger follow-ups, and incident auto-replies therefore don’t mask a conversation that still needs a human reply.

This is why automation-generated messages must be tagged isAutomated: true when they’re sent. If a custom automation or webhook out forgets that flag, those conversations will look Engaged when they actually still owe a human response.

If you notice a Pending pile that “looks engaged” or an Engaged stat that’s drifted, the first thing to check is whether a recent automation change is sending outbound messages without the flag.

See also

• Conversation statuses — the lifecycle axis
• What is the conversation list?
• FAQ — Status vs engagement