HarkHarkDocs
Theme

The support lifecycle

How one conversation moves through the hybrid state machine: from AI or a flow, into the live queue, to a human, and on to a resolved or async ticket.

Every conversation in Hark carries two related fields: a fine-grained support mode (who is serving the customer right now) and a coarse state (the triage bucket derived from it). Understanding the mode machine explains how a chat can start with a bot, escalate to a person, and settle into an async ticket without ever becoming a second record.

Support modes

A conversation's mode says exactly who or what is handling it at this moment.

ModeMeaning
AIThe AI bot is answering the customer directly.
WORKFLOWA scripted chat flow (logic tree) is running the conversation.
REQUESTING_HUMANThe customer asked for a person; escalation has begun.
IN_QUEUEWaiting in the live queue for an available agent.
RESERVEDHeld for one specific agent until they accept.
LIVEAn agent is in a real-time chat with the customer.
WAITING_CUSTOMERThe team replied and is waiting on the customer.
WAITING_INTERNALWaiting on an internal action or another team.
TICKETAn asynchronous ticket (the default for email).
RESOLVEDThe issue is handled.
CLOSEDThe conversation is closed.

Email conversations default to TICKET because email is asynchronous by nature. Widget chats usually begin in AI or WORKFLOW mode and escalate only when needed.

States

The state is the simple bucket your inbox filters on: OPEN, PENDING (waiting on the customer), SNOOZED (paused until a set time, with the SLA clock held), and CLOSED. The mode drives the state, so you rarely set the state by hand.

A typical journey

  1. A visitor opens the chat widget. A flow or the AI bot greets them (WORKFLOW or AI).
  2. The bot resolves the question, or the customer asks for a human.
  3. On escalation the conversation enters the live queue (IN_QUEUE), then is reserved for an eligible agent (RESERVED).
  4. The agent accepts and the chat goes LIVE.
  5. If the answer needs follow-up, the conversation becomes a TICKET or moves to WAITING_CUSTOMER.
  6. When the issue is handled it becomes RESOLVED, then CLOSED.

Resolution outcome and who resolved it

When a conversation ends, Hark records both how it ended and who ended it, independently. The outcome is one of RESOLVED, PARTIALLY_RESOLVED, ESCALATED, FAILED, ABANDONED, DUPLICATE, or REDIRECTED. The resolver is one of AI, WORKFLOW, AGENT, CUSTOMER, or SYSTEM. Keeping these separate is what lets analytics answer questions like "how many issues did the bot resolve on its own" honestly.

One timeline

Everything above happens on one conversation record with one activity trail. A bot answer, a queue wait, an agent reply, a tag, a transfer, and the final resolution are all events on the same timeline, so no context is lost at any handoff.