Support Workers

A support worker is a Virtual Worker pointed at your help desk. It reads a ticket's full conversation, drafts a reply, and posts that draft as an internal note for a human agent to review, so you get faster first responses and off-hours coverage without a wrong answer ever reaching a customer unreviewed. You route specific ticket stages to a worker and a skill, keep replying and resolving as separate gated capabilities, and let shifts cover the nights and weekends your human team does not. After this page you will be able to assign a worker to a workflow stage, understand the draft-review flow, and cover the clock without a CSAT hit.

Support workers use the Support Agent permission role and run well on the in-app assistant over usage credits, so there is nothing to link to get started. See Hiring and Configuring a Worker.

Drafts as Internal Notes, Not Customer Replies

After this section you will understand the single most important thing a support worker does. When a support worker handles a ticket, it does not message the customer. It reads the ticket's public conversation, writes a reply, and posts that reply as an internal note on the ticket, the same kind of note your human agents leave each other. A human then reads the draft, edits it if needed, and sends it, or discards it. This is why a support worker raises your response speed without risking your CSAT: the worker does the reading and the writing, which is most of the work, and a person keeps the judgment call of what actually reaches the customer. Sending a message to an outside recipient always requires that person; it can never be made automatic.

Routing a Stage to a Worker: Stage Workers

After this section you will be able to have tickets picked up automatically at the right point in your workflow. Under Help Desk, then Stage Workers, you bind a worker and a skill to a specific ticket workflow stage. When a ticket reaches that stage, the assigned worker runs the assigned skill on it, drafts its output as an internal note, and, on success, the stage can advance. You configure, per stage:

  • The worker. Which support worker handles tickets at this stage.
  • The skill. The skill it runs, so the worker does the specific job that stage calls for rather than a generic reply.
  • Auto-dispatch. Whether tickets reaching the stage are picked up automatically, or wait for a person to hand them to the worker.

Auto-advance is gated on success: a stage moves forward only when the worker's run actually succeeds, and you keep a human gate where you want one. This maps a worker onto your existing triage process precisely, one stage at a time, instead of turning it loose on the whole queue.

The Stage Workers tab under Help Desk settings. Its subtitle explains you assign a Virtual Worker and an AI skill to staff each workflow stage, and that enabling auto-dispatch spends container credits and requires a fresh two-factor verification and an elevated grant. A Workflow selector (marked) and a Stage selector sit above the assignment area, with a note that each worker uses its own explicitly configured agent source and stage assignments never override account ownership or billing.
Under Help Desk, then Stage Workers, you pick a workflow and a stage, then bind a worker and a skill to it. Auto-dispatch decides whether tickets reaching the stage are picked up automatically, and it is a credit-spending, two-factor-gated action.

Reply Versus Resolve: Two Separate Gates

After this section you will be able to let a worker draft answers long before you let it close anything. Replying to a ticket and resolving or closing it are separate autonomy capabilities. A worker can be trusted to draft replies on a queue while still being unable to advance or close a ticket there. This is the guard against the failure everyone in support has seen, where deflection numbers climb because tickets get closed, not because problems got solved. Keep resolve supervised until a queue's transcripts prove the worker's answers hold up, then grant it. The two dials live in Autonomy and Approvals.

Does the worker reply to customers directly, or draft for a human? It drafts. The worker posts its reply as an internal note for a human to review and send. Sending to a customer always requires a person and cannot be made automatic.

What counts as done or resolved by a worker? Be concrete: a worker can draft a reply, and, where you grant it, post that reply or advance a ticket. Advancing or closing a ticket is its own gated capability, separate from replying, so nothing gets marked resolved just to inflate a deflection number.

How do I avoid a wrong answer closing a ticket? Keep the resolve or close capability supervised while you let the worker draft replies. Read the transcripts, and only grant close on a queue where the worker's answers have proven correct.

Grounding in Your Own Knowledge

After this section you will know where a worker's answers come from. A support worker draws on your workspace's own material, your documents, your data, and the skill you assign the stage, so its drafts reflect your product and your policies rather than generic guesses. Your operating instructions tell it what it must never promise and when to escalate to a human instead of answering. Because every draft is a reviewable internal note before anything is sent, you always see what the worker based an answer on and can correct it before a customer ever does.

Covering Nights, Weekends, and Holidays

After this section you will be able to cover the clock without paying overnight staff. A support worker's shift is how it gives you off-hours coverage on your terms. Put a worker on an evening or weekend shift and it picks up tickets after your human team logs off, drafting replies that are waiting for review when the team returns, or, on queues where you have granted it, posting them. Set a worker's holidays and it is off for those days. Off shift, a worker does nothing unless a task was scheduled; work that arrives waits in the queue and is taken up when the next shift begins, so nothing is dropped and nothing happens at an hour you did not intend.

Can a worker cover nights and weekends, and can I set its hours? Yes. A worker works the days and hours you set in its shift, read in its timezone, with holidays you choose. Off shift it does nothing unless you scheduled it, so you get overnight coverage without a worker acting at random hours.

Can I route specific ticket queues or stages to a worker? Yes. Assign a worker and a skill to a workflow stage under Stage Workers, and tickets that reach that stage are handled there. Auto-advance only fires when the worker's run succeeds, and you can keep a human gate.

Where to Next