Customer Support Ops Official

Reads a ticket, drafts a KB-grounded reply with a confidence level, uses a known-issue canned response when one matches, and escalates low-confidence tickets. Draft only.

1. 01Select tickets to answer from the Tickets table. If {{ticketId}} is provided, work only that ticket. Otherwise read tickets whose Status is New and take at most {{maxToProcess}} (default 5). For each, first check the Known Issues table for a match; if one matches, use its approved canned response as the basis. Otherwise search the Support Knowledge Base for the answer.Output: For each ticket: the matched known issue or the relevant KB passages, and whether the ticket can be answered from available knowledge.
2. 02Draft a reply in the knowledge base's support voice, grounded only in the KB or the matched canned response, noting briefly what it was based on. Assign a Confidence of High, Medium, or Low. Follow the escalation rules: if Confidence is Low, or the ticket involves anger, churn, refunds, account deletion, or legal or privacy concerns, do not present a customer-ready answer; set Status to Escalated and write a short internal note on why. Never invent policies, facts, or promises.Output: For each ticket, the drafted reply (or escalation note) and the confidence level.
3. 03Write the results back to the Tickets table: put the draft in AI Draft, set Confidence, and set Status to AI Drafted for answerable tickets or Escalated for the rest. Do not send anything.Output: Confirmation of which tickets were updated, then a short readable summary using headings and bullet points: how many drafted by confidence level and how many escalated with the reason. Never output JSON or raw data.

Classifies new tickets by category, sentiment, and priority, and flags known-issue matches. Updates the Tickets table.

1. 01Read tickets from the Tickets table whose Category is empty or Status is New, up to {{maxToProcess}} (default 15). For each, determine Category, Sentiment, and Priority from the subject and message. Check the Known Issues table for a match and note it. Base everything only on the ticket content.Output: For each ticket: proposed Category, Sentiment, Priority, and any known-issue match.
2. 02Update each ticket row with the Category, Sentiment, and Priority. If a known issue matches, note it in Resolution Notes so the Reply Drafter can use the canned response. Do not draft the customer reply here and do not send anything.Output: Confirmation of the rows updated, then a short readable summary using headings and bullet points: counts by category, how many negative-sentiment or urgent, and how many matched a known issue. Never output JSON or raw data.

Clusters recent tickets into recurring issues, proposes canned responses, and flags help-center gaps into the Known Issues table.

1. 01Read recent tickets from the Tickets table (roughly the last {{lookbackDays}} days, default 7). Group them into clusters of the same underlying issue. Identify clusters that are frequent or rising and not already captured in the Known Issues table.Output: A list of candidate recurring issues with how many tickets each covers and whether it is already a known issue.
2. 02For each genuinely new recurring issue, create a Known Issues row with the issue, affected area, Status Investigating, a proposed canned response, and the linked ticket count. Also note any help-center gaps the clusters reveal. Do not duplicate existing known issues.Output: Confirmation of Known Issues rows created, then a short readable summary using headings and bullet points: the new recurring issues by volume and the suggested help-center additions. Never output JSON or raw data.

Extracts feature requests from tickets and maintains the Feature Requests table with frequency counts.

1. 01Read recent tickets from the Tickets table (roughly the last {{lookbackDays}} days, default 14), especially those categorized Feature Request or containing a suggestion. Identify the underlying feature request in each.Output: A list of feature requests found, each mapped to whether it already exists in the Feature Requests table.
2. 02For each request already in the Feature Requests table, increment its Frequency. For each genuinely new one, create a row with the request, requester if known, Frequency 1, and Status New. Do not create duplicates and do not invent requests.Output: Confirmation of rows created or updated, then a short readable summary using headings and bullet points: the most-requested features by frequency. Never output JSON or raw data.

Reads the support tables and produces a weekly insights digest of volume, deflection, drivers, known issues, and feature demand.

1. 01Read recent rows from Tickets, Known Issues, and Feature Requests. Compute volume, the split of AI Drafted versus Escalated, an approximate deflection read, the top categories and sentiment trend, the known issues driving the most tickets, and the most-requested features.Output: The computed totals and top lists from the tables.
2. 02Write a concise weekly digest for the support lead. Optionally record the day's totals as a row in Support Metrics.Output: A readable digest using headings and bullet points: volume and deflection, top drivers, sentiment, known issues to watch, and top feature requests. Lead with the headline numbers. Never output JSON or raw rows.