Child & Interaction Tickets

A ticket rarely lives in isolation. During its lifecycle it can spawn child tickets for backend work, and — while that backend work is in flight — interaction tickets to keep the customer cared for. This page explains both, and why the AI goes quiet while a ticket is open.

Child Tickets

A child ticket is a sub-ticket created during a parent ticket's lifecycle to handle one small, well-defined part of the work — an objective — that a human or backend team needs to complete before the AI can continue.

A good way to think about it: the parent ticket is the whole customer request; a child ticket is one specific question or task that has to be answered by a person (often a backend team) before the AI can move forward — for example "confirm whether this order shipped" or "approve this exception."

When a child ticket is created

While the AI is working a ticket, a workflow can decide the next step must be handled by a human. When that happens, Flowcall:

• Creates a child ticket in queued, carrying the objective — the parameter to fill, an instruction for the agent, an optional hint, and either a free-text answer or a set of selectable options.
• Routes the child to the right team (often a backend team), based on the objective's tags.
• Names it after the parent (for example T-1024_c1, T-1024_c2).
• Inherits the parent's channel, order, and workflow, and starts its own SLA timer.

If an unresolved child for the same objective already exists, Flowcall reuses it rather than creating a duplicate — objectives are matched by name, ignoring case and spacing.

If the parent has an owner, automation cannot create the child. Flowcall assigns the parent to its owner for action instead; only the owner may decide to create a child manually.

What happens to the parent

When a child ticket is created, the parent moves to blocked and is unassigned — it's now waiting on the child's answer and can't progress on its own. This is true whether the parent was in progress, queued, or assigned beforehand.

Objectives are handled one at a time. When a new child is created and an older child is still queued or assigned, that older child is pushed back to blocked — unassigned, its SLA timer stopped, and its previous assignee remembered as the preferred agent — so exactly one child is ever actively worked. The newest objective is the one in front of an agent.

When a child is resolved

The child's current assignee—or an admin—submits the response and an optional resolution. Being involved in the ticket or owning its parent is not enough to resolve the child. Flowcall then:

1. Marks the child resolved by agent and copies its answer back onto the parent, under the objective's parameter name. Any resolution text is added to the parent as a note.
2. Looks at the parent's remaining open (non-interaction) children:
   • If one is already queued or assigned, nothing is promoted — the parent stays blocked and that child continues.
   • If only blocked children remain, the oldest is promoted to queued (with a fresh SLA timer) and the parent stays blocked.
   • If none remain and the parent is unowned, the parent is unblocked back to in progress — the answer flows into the AI workflow, the AI resumes the conversation, and the customer is served again.
   • If none remain and the parent has an owner, the parent moves to assigned and returns to its current owner. The AI does not resume; the owner reviews the child's response and decides what happens next.
3. Auto-closes any open interaction tickets attached to that parent.

When a parent ticket is resolved directly, any of its still-open (non-interaction) child tickets are auto-closed — moved to closed, unassigned, with a resolution note saying why. The same cascade runs when a parent is marked stale.

Sharing a resolution with the customer

When resolving a child, the agent can choose to share the resolution with the customer — it appears to them as a note — or keep it internal. Backend objectives are usually internal; the AI weaves the answer into its reply.

Crucially, a shared resolution is not sent to the customer verbatim. The agent's answer and any note are handed to the AI, which rewrites them in your account's customer-facing voice before sending. A backend agent can jot a terse, internal-sounding note — "courier says address incomplete, need landmark + alt number" — and the customer still receives a polished, on-brand message. This is why backend teams don't need to be trained on customer tone: they supply the facts, the AI handles the phrasing.

Awaiting information (keep the child open)

Sometimes the agent working a child ticket can't answer yet — they're waiting on the courier, another team, or the customer. Instead of submitting a resolution, they open the dropdown next to Submit and choose Awaiting information. The child ticket stays open (moved to an awaiting-response state) rather than being resolved, so it isn't closed prematurely and the parent stays blocked.

This differs from Snooze, which pauses the child for a set number of hours and then brings it back automatically. Use Awaiting information when you're waiting on someone else's input, and Snooze when you just want to defer the work.

A child can also be put into an awaiting state by the parent: when a parent ticket is marked awaiting response by system, its queued and assigned children are marked awaiting by system too and unassigned, so nobody works a child while the whole request is parked on the customer. A customer reply reactivates the most recent such child to queued and puts the parent back to blocked.

Request information from the customer

Sometimes the agent can't finish because they need something from the customer — a new date to reschedule a technician visit, a delivery address, a photo reference. Instead of messaging the customer themselves and remembering to check back, the agent clicks Request from customer on the ticket and picks what they need.

• The ticket leaves the queue. The ticket the agent was working on (the active child, or the main ticket when there is no child) is set to blocked and shows Waiting for customer input. A small AI-owned request ticket appears in the family while the request is open.
• The AI asks the customer. It writes a short question and sends it on WhatsApp and/or email. On WhatsApp it uses a normal message when the customer wrote in the last 24 hours, and the selected approved template otherwise.
• Replies go to the request, not the conversation. While the request is open, the customer's WhatsApp replies and email replies on the request thread are read by the request. An unrelated email on another thread still reaches normal support. If an answer is incomplete or invalid (for example a date in the past), the AI asks a follow-up question. If the customer asks for a person or cancels, the request ends straight away.
• The ticket comes back with the answer. The value is saved on the ticket (shown under Customer provided) and in the ticket's data. Then the ticket returns to the queue, to the same agent when they are available if that option was ticked. The AI conversation is not restarted.
• No reply. The AI sends reminders. At the timeout the ticket either returns to the queue with a note, or the whole ticket is closed, as chosen when the request was sent.

See Request Information from the Customer for setup and the full behaviour.

From the open request, an agent can view the Conversation, Enter answer themselves (for example when the customer phoned in), or Cancel request. While a request is open, adding a child ticket, marking the ticket awaiting and snoozing are not allowed.

Setup. An objective appears under Request from customer once Agents can request this from the customer is ticked on it in the Data Library (or the Copilot sets it up). There you choose the answer type (text, number, yes/no, date, date and time), the WhatsApp template and its variables, reminders, timeout and the default timeout behaviour. Agents need the Request information from customer permission, which agent roles have by default.

Automatic Resolution from Tracking Updates

Many child tickets exist only because an order is in flight — a dispatch is delayed, a shipment is "where is my order," a delivery is stuck. Once the shipment actually moves, the ticket is moot. Flowcall closes these out on its own when your logistics provider sends a tracking update, so the backend team doesn't spend its day manually closing tickets the carrier has already resolved.

When a tracking webhook arrives — from ClickPost, Shiprocket, or a Shopify fulfillment event — reporting that the order was dispatched, is out for delivery, was delivered, or went RTO, Flowcall does two independent things:

• Tells the customer. It sends the WhatsApp status update your account has mapped to that tracking event (see Broadcasts → Events). The same event won't message the same customer twice within 24 hours.
• Re-evaluates the open ticket. It re-runs the ticket's workflow against the fresh order state. If the original concern is now satisfied — the delayed order has shipped, the "where is my order" is now delivered — Flowcall auto-resolves an unowned parent ticket (as resolved by AI) and cascades auto-close to its child and interaction tickets. An owned parent cannot be auto-resolved; it is assigned to its owner for action instead. If the concern still isn't satisfied, nothing is closed and the ticket stays with your team.

Re-evaluation is de-duplicated per tracking event for 24 hours, so a burst of near-identical carrier updates only triggers one pass. This only auto-resolves tickets whose remaining work the tracking update actually makes unnecessary — it never closes a ticket that still has open questions.

Resolving Many Child Tickets at Once

When dozens of child tickets pile up on a backend team — say fifty "delayed dispatch" orders that all shipped over the weekend — resolving them one at a time is tedious. Flowcall lets a team clear them in a single pass with an Excel round-trip, from the Ticket View.

• Export Child Tickets downloads your open child tickets as a workbook with one sheet per objective type (all the "delayed dispatch" children on one sheet, all the "need alternate number" children on another). You can filter the export by task, team, or assigned agent — only options that actually have open child tickets are offered — and non-admins only see child tickets assigned to or involving them. Each row carries the ticket, its parent, the customer, the order, and the ticket's captured fields for context.
• The team fills in the answer column (named after that sheet's objective) and an optional Resolution Note offline. Rows left blank are skipped, so partially filled sheets are fine.
• Import Resolutions re-uploads the workbook. Each filled row runs the same resolution as an individual submit. The row is accepted only for the child's current assignee or an admin, and assignment is checked again during background processing. An unowned parent can return to the AI workflow; an owned parent returns to its owner. A single Share resolution note with customer choice applies to the whole batch. Rows are processed one at a time with a small delay so customer messages stay staggered, and you can watch progress as it runs.

Export handles up to 2,000 child tickets at a time and each import up to 500 rows; split larger sets into multiple files.

Tip: If your logistics provider can send Flowcall a tracking webhook, you often don't need to bulk-resolve unowned delivery tickets at all — tracking updates can auto-resolve them. Owned parents always return to their owner for the final decision.

Why the AI Stops Responding

When a ticket is open with a human — and especially when a backend child ticket is in progress — the AI stops auto-responding to the customer. This is deliberate: it prevents the AI from talking over a human who is mid-investigation or contradicting an answer the backend team hasn't finished yet.

Practically, the customer's AI is switched to manual while the human handles things. Any messages the customer sends in the meantime are held rather than auto-answered. For an unowned parent, the AI is re-enabled automatically once the work is resolved or the blocking child is answered and the parent returns to in progress. An owned parent returns to its owner after the final child instead, so the AI remains paused.

AI auto-replies can also be paused at the account or channel level independently of tickets — see Settings → Channel Access.

Interaction Tickets

Backend work takes time. A backend team might need hours to confirm something, and while the parent ticket sits blocked, the AI is paused — so a customer who messages in the meantime would otherwise get silence. Interaction tickets exist to handle exactly that situation.

An interaction ticket is created when a customer reaches out while a backend ticket of theirs is open and the AI is paused. It routes that customer interaction to a front-line team so someone can respond, without disturbing the backend work still underway.

When one is created

An interaction ticket is created when all of the following hold:

• The customer has an open backend ticket (a ticket on a backend team that isn't itself an interaction ticket).
• That backend ticket has been waiting at least a configured delay — interaction tickets are meant for the gap when the backend team is taking a while, not for instant replies.
• The customer sends a message during that window.

Interaction tickets must be enabled for your business, with a delay and a designated interaction team configured.

How it behaves

• It's created in queued and linked to the main ticket (the parent of the backend work, or the backend ticket itself) so the context stays connected. It's named after the main ticket (T-1024_i1, T-1024_i2).
• There is at most one open interaction ticket per main ticket — Flowcall won't pile up duplicates if the customer sends several messages.
• It's routed to the configured interaction team (a front-line team) and assigned like any other ticket.
• It carries the customer's mood at the time it was raised, which is also logged on the main ticket.
• Resolving an interaction ticket does not unblock or resolve the underlying backend work — it only handles the customer's immediate message. Unlike a child ticket, it never changes the parent's status.
• When the underlying work finishes — the backend child is resolved, or the parent is resolved, snoozed, marked awaiting response, or marked stale — open interaction tickets are moved to closed automatically.

In short: child tickets push work down to a backend team and block the parent; interaction tickets keep the customer attended to while that backend work runs.

Related

• Ticket Lifecycle — the statuses these tickets move through.
• Ticket View — working child and interaction tickets in the ticket panel.
• Agent Assignement & Team — backend vs front-line teams, and how each of these tickets is routed.
• Workflows — where objectives that become child tickets are configured.