Live on-call Zendesk triage queue in Slack, powered by Groq

Every 10 minutes, run a triage loop over new and updated Zendesk tickets and keep a live queue for the on-call support team in Slack. Each ticket in the queue gets a suggested first response the on-call rep can copy or edit.

Trigger: cron on a 10-minute schedule. Persist a last-seen updated_at high-water mark between runs so we never reprocess the same tickets.

Step 1 — fetch. Call Zendesk List Tickets sorted by updated_at descending, filtered to tickets created or updated since the last high-water mark. Skip archived tickets. For each ticket in the window, call Zendesk Show Ticket to pull the full subject, description, requester, tags, priority, and status.

Step 2 — classify. For each ticket, send the subject and description to Groq's Create Chat Completion using a current llama-3.3-70b model (llama-3.3-70b-versatile). Ask for a single structured JSON response with five fields: a one-line summary, urgency (P1, P2, or P3), a category tag from {billing, bug, how-to, feature-request, other}, sentiment from {frustrated, neutral, happy}, and a suggested first response. Keep the suggested response to one short paragraph plus a signoff, and match the customer's tone. If Groq returns invalid JSON, retry once with a stricter system prompt, then fall back to a 'needs manual triage' placeholder row rather than dropping the ticket.

Step 3 — post the queue. Use the Slack Bot integration (bot token, not the user-token Slack integration — this is a shared on-call channel post). Send a Message to the on-call support channel as the parent message: a prioritized 'current queue' table with P1s at the top, then P2, then P3. Each row shows the ticket ID, one-line summary, category tag, sentiment, and how long it has been waiting. Persist the message ts so future runs update this same message instead of creating a new one.

Step 4 — thread the suggested replies. For each ticket in the queue, Send a Message with thread_ts set to the parent message ts, containing the AI's suggested first response formatted so the on-call can copy it verbatim or edit before sending. Keep a mapping of ticket_id → { parent_ts, thread_ts } between runs so we don't create duplicate threads.

Step 5 — collapse repeats. When a ticket changes (new comment, priority change, status update), do NOT post a new alert. Instead call Slack Bot's Update a Message on both the parent queue message (so the row reflects the latest urgency and waiting-time) and the ticket's existing thread reply (so the suggested response reflects the latest context). One message per ticket per shift, however many times it updates.

Shifts and cleanup. Treat each shift as a rolling window (default: a full day, but make the boundary configurable). When a ticket is solved or closed, strike through its row in the queue but don't delete the thread — reps may want to reference the suggested reply after the fact. Start a fresh parent queue message at the top of each new shift.

Note on Zendesk trigger choice: Zendesk isn't in the platform's poll providers list, so cron plus List Tickets with an updated_at filter is the right pattern here rather than a poll trigger.