Ticket Lifecycle

A ticket is how Flowcall tracks a piece of work. This page explains what a ticket is, the statuses it can be in, and how it moves between them. For the day-to-day workspace where agents act on a ticket, see Ticket View.

What a Ticket Is

In Flowcall, the first level of every conversation is handled by AI. The AI gathers information and decides whether the customer needs to be handed over to a human agent. A ticket is the mechanism for that handover — it marks that a customer now needs to be handled manually.

Reasons a ticket gets handed to a human include:

• Your process (SOP) requires it. For example, a refund may be technically possible for the AI to process, but your company wants a retention team to talk to the customer first and try to keep them.
• The customer asks for a human.
• Sentiment. If the customer is frustrated or aggressive, a ticket is created so a person can step in.

Every Conversation Creates a Ticket

Although tickets are primarily about handover, that's not the whole story: a ticket is created for every conversation. When a customer starts a conversation, a ticket already exists — it's just in progress, meaning it's still with the AI.

From there, the ticket either closes automatically when the AI resolves the conversation, or it gets handed over and assigned to a human agent.

Conversation starts
        │
        ▼
  Ticket created (in progress — with AI)
        │
        ├──► AI resolves ──► Resolved by AI
        │
        └──► Handover ──► Queued ──► Assigned to agent ──► Resolved by agent

A single conversation can produce multiple tickets over time.

The Statuses

Every ticket is in exactly one status at a time. There are twelve statuses, in four groups. The value column is the exact status string stored on the ticket — it's what you'll see in exports, the API, and ticket filters.

In progress

Status	Value	Meaning
In progress	in_progress	The AI workflow is actively driving the ticket. No human is needed yet.

Every ticket starts here. An in-progress ticket is not in anyone's queue and is not counted as open work.

Open (needs a human)

These are the statuses that put a ticket in the human queue. Internally these three are the open set — the one that decides whether a ticket counts as active work, blocks a duplicate ticket from being created, and makes the ticket eligible for assignment.

Status	Value	Meaning
Queued	queued	Needs a human and is waiting to be assigned to an agent.
Assigned	assigned	An agent has picked up (or been given) the ticket and is working it.
Blocked	blocked	The ticket is waiting on a child ticket — a sub-task being handled by another agent or team — before it can continue.

A ticket in queued or blocked is flagged unactioned until an agent works it; that flag is what the Inbox uses to surface untouched tickets.

Awaiting response

The ticket is waiting on the customer to reply. It is out of the active queue but not resolved, and it keeps its history so a customer reply can bring it straight back.

Status	Value	Meaning
Awaiting response (by agent)	marked-awaiting-response-by-agent	An agent marked the ticket as waiting on the customer.
Awaiting response (by system)	marked-awaiting-response-by-system	Flowcall marked it as waiting — for example after a long period with no customer reply. When a parent is marked this way, its queued and assigned children are marked the same way and unassigned.
Awaiting response to resolve	awaiting_response_to_resolve	Resolve confirmation is enabled and an agent clicked Resolve. Flowcall is waiting for the customer to confirm before the ticket closes for good.

Only the first two are reactivation statuses — a customer message pulls those tickets back into the queue. awaiting_response_to_resolve is handled by the resolve-confirmation flow instead (see below).

Resolved

The work is done. Resolved tickets leave the active queue and stop blocking new ticket creation.

Status	Value	Meaning
Resolved by AI	resolved_by_ai	The AI completed the conversation end to end (auto-resolved or auto-executed).
Resolved by agent	resolved_by_agent	A human agent resolved the ticket.
Closed	closed	Closed out by the system rather than worked to completion — a child or interaction ticket auto-closed once its parent finished, or a ticket closed by an integration.
Stale	stale	Marked stale because the work was abandoned or is no longer relevant — including an agent-marked awaiting-response ticket the customer never replied to.
Stale (automatic)	stale_marked_automatically	Marked stale by Flowcall on its own — a system-marked awaiting-response ticket that timed out, or an in-progress conversation that went inactive.

The three status sets

Much of Flowcall's behaviour keys off these groupings rather than individual statuses:

Set	Statuses	Used for
Open	queued, assigned, blocked	Assignment, the unactioned flag, "does this customer already have live work?"
Open and awaiting response	the open set plus the three awaiting statuses	Deciding which child and interaction tickets to auto-close when their parent finishes
Resolved	closed, stale, stale_marked_automatically, resolved_by_agent, resolved_by_ai	"Is this ticket finished?" — anything not in this set is still live

Note that in_progress is in none of them: it's live, but it is not human work.

How Statuses Transition

The diagram below shows the common path a ticket travels. Not every ticket touches every status — an AI-handled conversation may go straight from in progress to resolved by AI.

                       ┌─────────────────────────────────────────┐
                       │                                          │
  in progress ───────► resolved by AI                            │
       │                    ▲  (customer returns unhappy /        │
       │ handover           │   quick follow-up → reopened)       │
       ▼                    │                                     │
    queued ───────────► assigned ───────► resolved by agent       │
       ▲   │                  │                                   │
       │   │ child ticket     │ mark awaiting response            │
       │   ▼                  ▼                                   │
       │ blocked        awaiting response ───────────────────────┘
       │   │                  │   customer replies
       │   │ child resolved   │
       │   ▼                  ▼
       └── in progress    back to queued / blocked

The key transitions:

• Creation. Every new conversation opens a ticket in in progress. If that customer already has an in-progress ticket on the same channel, Flowcall updates it instead of opening a second one — unless the workflow or the order on the ticket changed, in which case a fresh ticket is started.
• AI resolves. If the AI finishes an unowned conversation, the ticket becomes resolved by AI. This covers both an AI auto-resolve and an AI auto-execute (the AI carried out the action itself) — both land on the same status, with the ticket flagged as auto-resolved or auto-executed. When resolve confirmation is enabled and the ticket is a root whose objective children have all finished, an AI auto-resolve waits for customer confirmation first. An owned parent cannot be resolved this way and is assigned to its owner for action.
• Handover to a human. When a human is needed, the ticket moves to queued, and the AI stops responding to the customer. Creating a queued ticket also starts the SLA timer and kicks off agent distribution.
• Straight to assigned. If the handover names a specific agent and force-assigns them, the ticket is created (or updated) directly as assigned, skipping queued, and an activity record is opened for that agent.
• Blocked by a child ticket. When part of the work is split off into a child ticket, the parent moves to blocked and is unassigned until that sub-task is answered. Once the last child is resolved, an unowned parent returns to in progress and the AI resumes; an owned parent moves to assigned and returns to its owner without resuming the AI. If other children are still open, one stays queued and the parent stays blocked.
• Awaiting the customer. An agent (or the system) can mark a ticket as awaiting response; the ticket is unassigned and its wait clock starts. For email tickets, Start after reply can make a successful agent or substantive AI reply perform this transition automatically. Agent replies use Awaiting response (by agent), while AI replies use Awaiting response (by system). When the customer replies, the ticket is pulled back to queued — its previous assignee is remembered as the preferred agent so it tends to return to the same person, and any remaining email follow-ups are cancelled. If the reactivated ticket is a child, the child goes to queued and its parent goes to blocked.
• Resolution. When resolve confirmation is off, an agent resolving a ticket sets it to resolved by agent; the AI resolving it sets resolved by AI. Either way, still-open child and interaction tickets of that ticket are auto-closed.
• Auto-resolution from tracking updates. A logistics tracking webhook (dispatched, delivered, RTO) can resolve an unowned open order ticket when the update makes the customer's concern moot — the parent is set to resolved by AI and its child and interaction tickets are auto-closed. An owned parent is returned to its owner for action instead. See Child & Interaction Tickets → Automatic resolution from tracking updates.
• Resolution confirmation. For an unowned, customer-facing ticket, when Resolve confirmation is enabled on a supported interactive channel, clicking Resolve moves the ticket to awaiting response to resolve and sends the customer a Yes/No confirmation. The same transition occurs without a parent handoff when the AI reaches auto-resolution after all objective children are terminal. Confirmation resolves the ticket with its original agent/AI attribution; rejection reopens it to queued; a timeout or too many declines can auto-resolve it. Internal-only tickets and owned parents bypass this deferred flow and close immediately.
• Going stale. A ticket that sits idle or abandoned for too long is marked stale or stale automatically. Which one you get depends on who set the wait: a ticket an agent marked awaiting response becomes stale, and one the system marked awaiting response becomes stale (automatic). An in progress conversation that goes inactive (on non-email channels, when the auto-stale setting is on) also becomes stale (automatic). Stale timeouts are configured per channel under Settings → Ticket Behavior, and a ticket is never marked stale while it still has an unresolved backend child ticket.
• Closed. closed is reserved for tickets the system closes out rather than someone working them: child and interaction tickets cascaded closed when their parent is resolved or marked stale, and tickets closed by an integration. Those closures record a resolution note explaining why.

Statuses at a glance

From	Trigger	To
(none)	conversation starts	in_progress
in_progress	AI finishes, parent unowned	resolved_by_ai
open parent	automation finishes, parent owned	assigned to owner
in_progress	handover needed	queued
in_progress	handover to a named agent (force assign)	assigned
in_progress	workflow needs a human objective (child created)	blocked
in_progress	inactivity, auto-stale enabled	stale_marked_automatically
queued	agent picks up / distribution routes it	assigned
queued / assigned	a child ticket is created	blocked
assigned	agent resolves (confirmation off)	resolved_by_agent
assigned	agent resolves (confirmation on)	awaiting_response_to_resolve
queued / assigned	agent marks awaiting customer	marked-awaiting-response-by-agent
queued / assigned	system marks awaiting customer (no reply)	marked-awaiting-response-by-system
blocked	last child resolved, parent unowned	in_progress
blocked	last child resolved, parent owned	assigned to owner
in_progress root with completed children	AI auto-resolves, confirmation on	awaiting_response_to_resolve
awaiting (agent/system)	customer replies	queued (parent → blocked if a child was reactivated)
awaiting by agent	wait timeout	stale
awaiting by system	wait timeout	stale_marked_automatically
awaiting_response_to_resolve	customer confirms	resolved_by_agent or resolved_by_ai
awaiting_response_to_resolve	customer declines	queued
awaiting_response_to_resolve	confirmation timeout / too many declines	resolved (auto)
resolved_by_ai	customer returns unhappy shortly after	queued
open / awaiting child	parent resolved or marked stale	closed

Reopening

As a rule, a resolved ticket isn't reopened — when a customer comes back, a new ticket is created.

The main exception is an AI-resolved ticket. Two things can reopen one:

• Negative sentiment. If the customer comes back frustrated, aggressive, or asking for an agent on a ticket the AI had just resolved, that same ticket is reopened to queued (the auto-resolved flag and resolve time are cleared) rather than starting fresh, so the context isn't lost.
• A repeat of the same request. If the AI resolves the same workflow again for the same customer, order, and thread, Flowcall updates the existing AI-resolved ticket instead of stacking up duplicates. On WhatsApp and live chat there is also a short one-hour cooldown: an identical follow-up within that window reuses the resolved ticket rather than creating a new one.

A ticket resolved by a human agent stays closed. If a new AI or customer event arrives on it, Flowcall opens a new ticket instead of touching the resolved one.

Resolve confirmation adds a pre-resolution exception for human-handled tickets and child-driven AI parent completion. While a ticket is still awaiting response to resolve, a customer rejection reopens the same ticket to queued. Once the ticket reaches its final resolved by agent or resolved by AI state, it stays closed.

Muted customers are the one case where no ticket is created or updated at all — the whole flow is skipped.

Cross-channel Ticket Handling

Customers sometimes reach out on more than one channel for the same request — for example, they email first and then send a WhatsApp message when they want a faster update. Flowcall avoids creating a second ticket for that customer while an active ticket already exists.

How the existing ticket is handled depends on its current state:

• Awaiting response. If the ticket was marked awaiting response because Flowcall was waiting for the customer, priority is not used. The customer's new message becomes the active channel, the ticket is reopened into the queue, and the AI sends a short acknowledgement on the channel where the customer replied.
• Queued, assigned, or blocked. If the ticket is already open with the support team, Flowcall uses the fixed Chat → Email → Voice Call priority. Chat groups WhatsApp, Instagram, and Live Chat. A higher incoming segment moves the ticket; an equal or lower segment keeps the existing source and tells the customer where support will continue.
• Voice Call. An existing Chat or Email ticket stays on its current segment when a voice call starts. A standalone Voice Call ticket moves to Email or Chat when the customer later contacts either segment.
• Manual. A manually created ticket is claimed by the first supported inbound customer channel. Later interactions follow the normal rules for the ticket's current status.

A ticket already on one chat channel stays there when the customer uses another chat channel. The fixed priority can be enabled or disabled under Settings → Ticket Behavior.

Current ticket	Incoming Chat	Incoming Email	Incoming Voice Call
Chat	Keep the existing chat source	Keep Chat	Keep Chat
Email	Move to the incoming chat source	Keep Email	Keep Email
Voice Call	Move to the incoming chat source	Move to Email	Keep Voice Call

This matrix applies only to queued, assigned, and blocked tickets while the setting is enabled. Awaiting-response and manual-ticket behavior remain the exceptions described above.

When email is involved, Flowcall also keeps the customer informed by email:

• If an email ticket is moved to WhatsApp, Instagram, or live chat, the email thread receives a notice saying the ticket moved to that channel.
• If the customer emails while the active ticket should stay on another channel, Flowcall replies by email telling them where support will continue.
• These routing notices are sent even if automatic email replies are off or the thread has reached the Max AI email replies limit, because they are operational handoff messages rather than normal AI answers.

Related

• Child & Interaction Tickets — how a ticket branches into sub-tasks, and what happens when a customer messages while a backend ticket is open.
• Ticket Ownership — how an owner controls parent resolution and receives delegated work back.
• Ticket View — the workspace where agents act on a ticket.
• Agent Assignement & Team — how tickets get routed to the right team and agent.
• Insights → Tickets — analyze ticket volume, status, and resolution trends.