WorkerKitAI workers for support triage
Set up an AI worker to triage support email, prepare reply drafts and file issues, with explicit queue coverage, escalation owners and review checks.
Published by WorkerKit. Updated .
Use an AI worker to turn support email into a ranked queue, reply drafts and tracked issues. Your support team owns the replies, urgent escalations and anything the worker could not review. Start with one inbox and one task board so the handoff has a clear owner.
This guide covers a bounded support job within enterprise AI automation. WorkerKit accounts open by invitation: browse the kit now and request access before connecting accounts or running work.
The worker and its job
One worker kit covers this intake job. A second worker is useful only when you have another defined job to hand off, such as investigating a recurring problem. Installing more workers does not itself establish that handoff.
| Worker | Its job | Apps | Published run modes |
|---|---|---|---|
| Support Inbox Triager | Classify and prioritize support threads, prepare reply drafts and create or update issue tickets | Email and tasks | On demand; a support sweep every four hours |
The worker runs on WorkerKit's managed runtime. Between runs, its instructions and permissions remain available. The published four-hour cadence is a series of sweeps, not continuous monitoring or a response-time guarantee.
What happens during a support sweep
A customer reports that an action in your product fails. The worker reads the thread, applies the support priority rubric and prepares an acknowledgment as an email reply draft. It looks for an existing issue on the connected task board. A confirmed match receives the new report as a comment; otherwise, the worker creates a ticket with the symptom, customer, severity and email subject.
The support rep checks the draft against the customer's message and decides what to send. The board's assigned team owns the investigation. If the worker could not match an issue safely, read a thread or file a ticket, the rep resolves the gap. A ranked queue is useful only if somebody accepts responsibility for its items.
Urgent items appear first in the result with a NEEDS ATTENTION NOW flag. That flag does not page your on-call team by itself. Choose and verify a result-delivery route to the person responsible for urgent review, and retain your existing incident channel for time-critical reports.
How to set up AI workers for support triage
Have an invited account, an authorized support email connection, a supported task-board connection and a support lead ready. The kit has no required custom-input form or memory-setup questions, so review the actual instructions and rubric before the first run.
1. Define the inbox boundary and the receiving team
Choose one support inbox or a permitted scope within it and the board where real issues should land. Name the support lead who accepts the work, the person who reviews drafts and the owner of urgent escalations. These responsibilities may belong to the same person in a smaller team.
Write the acceptance criteria before installing. A completed run must identify the scope it reviewed, classify using the agreed rubric, preserve the customer's meaning, match existing tickets where appropriate and report anything left unread. Sending a message or closing an issue is outside this job.
Record how the team handles unsupported requests. Refunds, credits, legal positions and promised resolution dates need a person. If your organization requires approval before any ticket write, the published write-enabled kit needs a narrower design before use; draft review alone does not establish that approval policy.
2. Install the kit, pause its schedule and review access
Open Support Inbox Triager and choose Get this kit. Connect the authorized email and task accounts. After installation, continue to Start your worker, then use Close (X) before choosing a start or funding action. This opens the installed worker without starting its runtime.
The kit imports an enabled four-hour schedule. In Overview, open Automation → Schedules and switch Support sweep off using Pause schedule. Wait until its row reads Paused. If no schedule was created, leave the list empty while you evaluate the worker.
Inspect both app grants before running it. Keep unrelated accounts and boards outside the grant wherever the app's supported controls allow you to narrow them.
Email access includes reading, applying labels and creating reply drafts. It does not include sending email. Task access includes reading boards, items and comments, plus creating items, updating items and adding comments. Check the actual selected board and account, not just the app's name.
An agent can help through the WorkerKit MCP server after account access is established. It needs the installKits scope, calls kit_install_preview, shows you the proposed installation and calls kit_install only after your approval. App connections, enabling a schedule and starting paid runs also require your authorization.
3. Review the rubric, coverage rules and allowed replies
Read the kit's Support priority rubric. It distinguishes P1 incidents and blocked customers, P2 degraded service and P3 questions without time pressure. Align the interpretation with your team's actual support policy before enabling recurring work. Decide which escalation information belongs in the report and which needs delivery through another channel.
The rubric mentions account significance, but this kit has email and task access, not CRM access. Provide approved context needed for that decision or remove reliance on that signal. Do not assume the worker can retrieve a customer's account tier from an app it cannot read.
Review the sweep boundary too. The instructions use the run clock and an available prior-run checkpoint. Without a checkpoint, they begin with the preceding 24 hours and report that baseline. They limit app reads to 40 calls, including search pages, ticket lookups and thread reads, and require unreviewed scope and failed reads to be reported. This is an instruction limit to inspect in results, not a guarantee that every queue fits in a sweep.
The kit has no long-term worker-memory setup. Do not treat its first run as a complete historical backlog review or assume it discovers every old unanswered thread. Decide how a person reconciles older work and coverage gaps separately.
4. Run on demand and inspect the actual outputs
Confirm Support sweep still reads Paused, or that the schedule list remains empty. Under How this worker works, open AI model, then choose Set it up under Let WorkerKit run it. Use Change to review the model and set Max $ / run and Max $ / day. Choose Run worker now to prepare an on-demand run, then review and confirm Run now. If a notice says schedules would start, cancel and pause those schedules first.
Run over permitted support threads whose expected handling your team can assess. Keep recurring sweeps paused until the owner accepts the results.
Use a mix that exposes different mistakes, rather than only easy questions:
| Review case | What an acceptable result shows |
|---|---|
| A straightforward how-to question | A reply draft grounded in the thread, with no unsupported product claim |
| A bug already on the board | The correct existing issue receives the report; no duplicate ticket is created |
| A new bug | A new ticket describes the customer's symptom and separates suspected cause from fact |
| A refund request or legal threat | The result routes the decision to a person without promising an outcome |
| An incomplete or failed read | The result names the coverage gap instead of reporting a fully clear queue |
Inspect the email drafts and board changes alongside the run receipt. Confirm the ticket destination, priority, comments and changed fields. The receipt shows execution and cost; the support lead decides whether the classification and response are correct.
If the task board is unavailable, the kit's instructions allow triage and drafting to continue while reporting that nothing could be filed. Treat that as a partial result requiring a handoff, not as completed ticket intake. Before retrying a failed run, inspect any drafts and board changes it already made.
5. Enable a cadence that matches review capacity
After the owner accepts the on-demand results, return to Automation → Schedules. The imported Support sweep runs every four hours when enabled. Keep that cadence or choose another supported schedule that meets your coverage needs and plan limits. Confirm the actual schedule and time zone, then enable it using Resume schedule.
A four-hour cadence across a full day creates six scheduled opportunities to run. It does not ensure every inquiry is reviewed within four hours: failed runs, access problems, volume and partial sweeps can add delay. Review backlog growth and missed runs alongside completed-run results.
Configure where the run result is delivered using the options available to your account, then verify receipt by the responsible team. Test an urgent item and a partial result through the whole handoff. The test is complete when a person can identify the item, its evidence and the next action, not merely when the worker finishes.
What the worker can touch
| App | Published grant | Operating boundary |
|---|---|---|
| Read messages and threads, search, apply labels and create reply drafts | No send or delete operation is granted; a person reviews and sends replies | |
| Tasks | Read boards, items and comments; create and update items; add comments | Use the intended support board; inspect changed fields and ticket matches |
The app firewall limits available operations, and supported field restrictions on built-in apps can narrow what reaches the model. Review those settings against your actual support data. Do not assume every sensitive value in every field is automatically removed.
The instructions say never to close tickets. The task grant still permits item updates, which is broader than a promise to change only priority. Treat that instruction as a rule to evaluate; where a hard boundary is required, narrow the supported operation or redesign the job. An allowed operation can still produce an incorrect business result.
What to measure and budget
Count accepted triage outcomes, not just successful runs. A run can produce several useful drafts and tickets while leaving part of the queue unreviewed. Track that remaining scope so output volume cannot hide a growing backlog.
| Measure | What to collect | What it tells the support lead |
|---|---|---|
| Coverage | Reviewed time window, processed threads, failed reads and unreviewed scope | Whether the team knows what remains |
| Quality | Correct priority, ticket match, draft accuracy and escalation handling | Whether the result meets the job's criteria |
| Execution usage | Actual tool calls, model usage, failures and retries from run records | What the authorized sweeps consume |
| Human effort | Review, edits, ticket corrections and maintenance time | Whether the process creates useful capacity |
For six completed sweeps in a day, add the actual tool calls from those six runs and any retries. Do not substitute the 40-read instruction limit for total usage: ticket writes and draft creation add calls, and model usage is a separate meter. Measure under representative queue volume before estimating a month.
Check current daily caps, rate limits, schedule options and record retention on /pricing. Model tokens are billed at provider list price with no markup. Include applicable app charges, platform charges and review labour when calculating cost per acceptable result; WorkerKit's execution record does not supply your labour cost.
When to keep the process narrower
Leave incident response with the team's existing process when a report needs immediate attention. A periodic sweep can assist support intake, but it cannot replace a staffed escalation route simply because its output uses a P1 label.
If reviewers send drafts without reading the source thread, narrow the worker to classification and ticket preparation or reduce the volume it handles. A draft queue larger than the team's review capacity moves the bottleneck instead of resolving it. If existing rules already classify and route the inbox adequately, compare the added judgment and review burden before introducing a model; the AI agents and RPA comparison explains that choice.
Pause the affected worker when its behavior needs investigation. Check and correct completed writes separately, since pausing does not undo them. Resume after reviewing the cause, the revised instructions or permissions and a fresh on-demand result.
For a broader rollout, use the enterprise AI automation platform evaluation to assess ownership, authority, evidence and operating effort across jobs. Expand only when the support lead can explain what this worker finishes and what still belongs to the team.
FAQ
Does this worker reply to customers automatically?
Support Inbox Triager creates reply drafts. Its published email grant has no send operation, so a person reviews and sends from the email app. Ticket creation and updates are separate writes that occur during an authorized run.
Does the four-hour schedule mean the queue is always covered?
No. The worker performs scheduled sweeps and can report partial coverage. The team should review the processed window, failed reads and remaining scope, and keep a separate route for urgent incidents and older backlog.
Do we need a second worker for escalations?
Not for this setup. The receiving support team owns the tickets and urgent review. Add another worker when you have a defined investigation or preparation job with its own inputs, permissions and acceptance criteria; installing one does not automatically connect the handoff.
Can we try the worker before enabling a schedule?
Yes. The kit supports on-demand runs, but it imports an enabled schedule. Close runtime setup after installation, pause Support sweep in Automation → Schedules, then inspect the grants, set a budget and evaluate an on-demand run. You can request an invitation while preparing the inbox scope and acceptance criteria.