FAQ — Status vs engagement
A two-axis state model is unusual. Here are the questions agents and admins ask most often.
Why does a conversation have two state fields?
Because they answer different questions:
- Status answers “where in the lifecycle is this conversation?” (Active, Snoozed, Done, Archived)
- Engagement answers “is the ball in our court right now?” (Pending, Engaged)
A single field can’t capture both. An “Active” conversation can be either Pending (we owe a reply) or Engaged (we replied, waiting on customer), and the two vary independently.
Isn’t “Pending” the same as “Active”?
No. They’re orthogonal — they vary independently.
- Active + Pending = alive, customer wrote last, needs reply
- Active + Engaged = alive, agent replied last, waiting on customer
- Done + Pending = closed while we still owed a reply. A customer writing back would have reopened it to Active instead, so this one is rare
- Done + Engaged = closed from agent side, customer hasn’t replied (the typical “done done” state)
Active is “not snoozed, not done, not archived.” It doesn’t tell you whether you owe anything.
Which one tells me what to work on?
Engagement does — conceptually. In practice, the conversation list cannot be filtered or sorted by engagement today. There is no Pending/Engaged quick filter, no engagement field on a saved filter, and the public API returns engagementState on each conversation without letting you filter on it.
Where you can act on the split: Dashboard → Right Now breaks the open queue into New, Pending and Engaged and lets you slice by channel, team and agent. Clicking a cell deep-links into the inbox, but because there is no engagement filter both Pending and Engaged land on the Active tab. A first-class engagement filter is a known gap.
How does engagement get computed?
Atender computes it automatically from the message stream:
- Customer sends a message → Pending
- Agent replies → Engaged
- Customer writes back → Pending
- Assignment, team change, or AI handoff event → Pending (someone on our side now owns it but hasn’t replied)
There’s no manual override. The rule is deterministic. See Engagement state for full mechanics.
Review imports, such as Trustpilot conversations, are a special case. A newly imported review can start as Engaged, a review revision can move the conversation back to Pending, and a deleted review is archived. For reviews, Engaged does not necessarily prove an agent already responded — it may just reflect how the review import was classified.
Why is an inbound custom-channel conversation Engaged?
Some custom inbound endpoints are configured for notifications, alerts, or one-way events where no human reply is expected. For those channels, Atender marks the conversation Engaged by design: the inbound event is recorded, but it doesn’t mean “the ball is in our court.”
This exception is specific to custom inbound endpoints configured that way. Ordinary inbound email, chat, and SMS messages still become Pending because they usually represent a customer waiting for a reply.
What about internal notes — do they change engagement?
No. Internal notes are not customer-facing and don’t move the ball. A note from one agent to another is invisible to the engagement computation.
What about automation messages — are those “us” speaking?
Mostly no, with one important exception. Atender skips an automation-generated message when classifying engagement — unless the agent pipeline authored it. An Agent Stack reply is a real answer, so it counts as Engaged even though no human typed it; keying on the automated flag alone used to make the same AI answer count on web chat and not on email, Slack or voice.
So auto-acknowledgements, CSAT triggers and incident auto-replies don’t mask a conversation that still owes a human reply, while an Agent Stack answer does end the Pending run. The flag is set by Atender when the message is sent — it is not something you set on your own automations, and it is not a writable API field, so a drifting engagement number is not something you fix by re-tagging.
Why do Snoozed conversations have engagement state?
Because conversations don’t lose their last-spoken-side just because they’re paused. A Snoozed conversation:
- Pending → customer wrote, you snoozed before replying (rare but happens)
- Engaged → you replied, snoozed, waiting on customer
When the snooze ends and the conversation returns to Active, the engagement state is still meaningful.
Can I have a Done + Pending conversation?
Yes. It happens when:
- You marked a conversation Done while it was Engaged (waiting on customer)
- The customer then wrote back
- The conversation reopened to Active… and engagement flipped to Pending
Until you reply, the conversation is Active + Pending. (If you hadn’t replied yet but the conversation was still “Done” somehow due to a bug, it’d be Done + Pending — but in normal flows the customer’s reply moves it to Active first.)
Why doesn’t the conversation list show engagement on each row?
To keep the list scannable. The row shows what every conversation needs (subject, contact, last update, tags, SLA) and engagement would colour half the list one way and half the other.
There is currently no substitute in the list either — engagement is neither a per-row badge nor a filter. Use Dashboard → Right Now for the Pending/Engaged counts.
What if engagement gets out of sync?
Engagement is computed from the message log, so it shouldn’t drift. If you ever see a conversation that “feels wrong” (you’re sure you replied last but it shows Pending), check:
- Is there an inbound message you missed (auto-collapsed thread, attachment-only message)?
- Was the last “outbound” actually an internal note rather than a reply?
- Did automation tag a message such that the system reclassified it?
If none of those explain it, it’s worth flagging — engagement misclassification is a high-priority bug because it directly affects “what should I work on.”