Support modes and states
The difference between a conversation state and its support mode, and how the hybrid AI-to-human machine moves a conversation between them.
Hark tracks two things about where a conversation sits: its state (a simple triage bucket) and its support mode (exactly who or what is serving the customer right now). The mode drives the state, so you usually set the mode indirectly by acting on the conversation.
States
The state is what the inbox filters on:
- OPEN: active and needs attention.
- PENDING: waiting on the customer to reply.
- SNOOZED: paused until a set time; the SLA clock is held while snoozed.
- CLOSED: finished.
Support modes
The mode is the fine-grained truth of who is handling the conversation.
| Mode | Who is serving the customer |
|---|---|
| AI | The AI bot, answering directly. |
| WORKFLOW | A scripted chat flow. |
| REQUESTING_HUMAN | Escalation to a person has begun. |
| IN_QUEUE | Waiting in the live queue. |
| RESERVED | Held for one agent to accept. |
| LIVE | An agent, in real time. |
| WAITING_CUSTOMER | The team replied; waiting on the customer. |
| WAITING_INTERNAL | Waiting on an internal action. |
| TICKET | An asynchronous ticket (email default). |
| RESOLVED | Handled. |
| CLOSED | Closed. |
Why two fields
Splitting mode from state is what makes Hark hybrid. A single conversation can start with the AI bot (AI), run a scripted flow (WORKFLOW), escalate to the queue (IN_QUEUE, RESERVED), go LIVE with an agent, then settle into a TICKET, all without becoming a new record. Meanwhile the coarse state stays readable at a glance in the list.
Handoff context
When a conversation escalates from a bot to a human, Hark assembles a structured handoff package: what the customer was trying to do, what the bot attempted, and the collected context. The receiving agent opens the conversation already knowing the story, so the customer does not have to repeat themselves.