Playbook: Build a Daily Zendesk Support Triage Agent

Your support team starts each day the same way: someone opens Zendesk, sorts through new tickets, looks for urgent escalations, checks what is about to miss SLA, and posts a summary for the team. It is repetitive, easy to do inconsistently, and exactly the kind of work scheduled triggers are good at. This playbook walks you through setting up an agent that runs every morning, reviews your Zendesk queue, and produces a triage summary your team can act on immediately.

What you will build

By the end of this playbook, you will have:

  • A Zendesk triage agent with a prompt that reviews the current queue and highlights what needs attention first
  • A daily scheduled trigger that runs the agent automatically every morning
  • A repeatable summary format that separates critical issues, near-SLA breaches, and routine backlog
  • Run history in the Tasks page so you can review each triage run, inspect failures, and rerun on demand
  • Slack notifications for failed runs so the team knows when the automation needs help

What you need before you start

  • Access to the AI chat
  • Access to your Zendesk API, including the subdomain, authentication method, and the ticket fields your team relies on
  • An agent configured in your workspace with access to the tools your support process depends on
  • A clear definition of your triage rules, such as what counts as urgent, how you define SLA risk, and which queues or tags should be included
  • Optional: Slack connected at the workspace level and your personal Slack identity linked, if you want run notifications

If you have not created tools before, there is not a standalone tool-creation guide in this docs set yet. The closest examples are the MCP server playbooks, especially Build an Order Management App on Top of Your WMS and Build an Intake App for a System Only Engineers Can Use. This playbook includes the tool-building steps you need for the Zendesk example.

Step 1: Define the Zendesk triage rules

Before you schedule anything, decide what the agent should look for. A useful support triage summary usually answers these questions:

  • Which tickets are critical and need attention immediately?
  • Which tickets are close to breaching SLA?
  • Which tickets have been unassigned too long?
  • Which themes or repeated issues are showing up today?
  • What should the team do first?

Write those rules down in plain language. Then give the AI the context it needs:

"I want to automate our morning support triage in Zendesk. Our Zendesk subdomain is acme-support.zendesk.com. Review the open support queue and produce a concise summary for the team. Treat tickets as critical if they are marked severity 1, mention production issues, or are from enterprise customers. Flag tickets that will miss SLA within the next 4 hours. Flag unassigned tickets older than 2 hours. Group repeated issues into themes."

If your team has special routing rules, include them now:

"If a ticket mentions billing, route it to the billing pod. If it mentions SSO or login failures, route it to platform support. If a ticket is missing enough detail to diagnose, call that out in the recommendations."

Step 2: Build the Zendesk tools first

Do not point a scheduled trigger at a vague prompt and hope the agent magically reads your support system's mind. Build the tools first so the agent has concrete ways to inspect the queue.

Start with the read operations:

"Create a tool called 'list_open_zendesk_tickets' that pulls open Zendesk tickets. It should support filtering by group, priority, status, and updated_since. Return ticket ID, subject, requester, assignee, priority, status, tags, created_at, updated_at, and SLA due time if present."

"Create a tool called 'get_zendesk_ticket_details' that takes a Zendesk ticket ID and returns the full ticket details, including description, comments, custom fields, group, assignee, requester, and any SLA fields."

Then add a focused query tool for triage:

"Create a tool called 'search_zendesk_tickets' that searches Zendesk tickets by text, tags, requester, or organization. Return the fields we need for triage plus a short snippet from the latest comment."

Test each tool as soon as it exists:

"Use list_open_zendesk_tickets to show me the current open tickets in the Support group."

"Use get_zendesk_ticket_details for ticket 10452."

If something is off, fix it before moving on. This is the same tool-building pattern used in the MCP server playbooks: define one useful tool, test it, then expand the set.

Step 3: Test the prompt manually first

Do not schedule the first draft blind. Run the prompt in the AI chat so you can see whether the output is useful before it starts firing automatically every day.

Now that the agent has Zendesk tools, try something like:

"Use the Zendesk tools to review the current support queue and generate a morning triage summary with these sections:

  1. Critical issues
  2. Tickets at risk of SLA breach
  3. Unassigned backlog
  4. Repeated themes or patterns
  5. Recommended first actions

Keep it short and operational. If a section has no items, say 'None.'"

Look for the usual problems:

  • Too much detail and not enough prioritization
  • Missing tickets that should have been flagged
  • Recommendations that are vague or not actionable
  • Output that changes format every run

Refine the prompt until the output looks like something your team would actually trust at 8:00 AM.

Step 4: Create the scheduled trigger

Once the prompt is solid, create the recurring trigger from the AI chat:

"Create a daily trigger at 7:30 AM America/New_York called 'Morning support triage'. Use my support triage agent and this prompt:

Use the Zendesk tools to review the open support queue and generate a morning triage summary with these sections:

  • Critical issues
  • Tickets at risk of SLA breach in the next 4 hours
  • Unassigned tickets older than 2 hours
  • Repeated themes
  • Recommended first actions

Prioritize severity 1 issues, enterprise customer tickets, and production-impacting problems. If a ticket needs more context, call get_zendesk_ticket_details before classifying it. Keep the summary concise and operational."

The AI should confirm the trigger name, schedule, timezone, and next run time.

Choose a time that gives the team enough lead time to act. For example:

  • Before shift handoff if you run a global support team
  • Before standup if the summary is reviewed live
  • After upstream systems have finished overnight syncs, if the agent depends on fresh ticket data

Step 5: Force a test run and inspect the output

Do not wait for tomorrow morning to discover the prompt is mediocre. Open the Tasks page after creating the trigger and use Rerun Task to run it immediately.

For the first few runs, inspect:

  • The final summary output
  • The run status
  • Total duration
  • Any tool errors or incomplete steps in the execution log

If the run fails, use the error message and execution log to figure out whether the problem is:

  • Missing tool access on the agent
  • A prompt that assumes data the tools do not return
  • An upstream system outage or timeout
  • A formatting instruction that is too vague

See Viewing Job Runs for the full run detail workflow.

Step 6: Make the prompt resilient

A good scheduled workflow does not just work when everything is perfect. It should also fail cleanly when something is missing.

Update the prompt so the agent handles edge cases:

"If one Zendesk tool call fails, continue with the data you already have and clearly note what could not be checked. If you cannot complete the triage confidently, say 'Needs manual review' and explain why. If there are no urgent items, explicitly say that there are no critical issues today."

This improves two things:

  • The output stays useful even when one part of the workflow has problems
  • The run is more likely to finish with a helpful result instead of collapsing into an unhelpful failure

If the revised prompt is materially different, create a new trigger with the improved instructions and disable the older one. Scheduled triggers are easier to operate when each trigger has one clear purpose and one stable prompt.

Step 7: Tune the summary for the team

After a few runs, you will see what the team actually uses and what they ignore. Tighten the output around that.

Useful follow-up prompt refinements include:

"Limit each section to the top 5 items by urgency."

"For every recommended action, include the ticket ID and owner if one exists."

"In repeated themes, group similar tickets together and estimate the customer impact."

"If the queue is healthy, keep the summary under 5 bullet points total."

The goal is not to produce a beautiful essay. The goal is to make morning triage faster and more consistent.

Step 8: Operationalize failure handling

Scheduled triggers already help here:

  • Failed runs can notify you in Slack immediately if Slack is connected
  • Successful and partial runs still appear in the Tasks page for review
  • You can rerun the task manually if the issue was temporary

This means you do not need to guess whether the automation ran. You can verify it, inspect it, and recover quickly.

If failures become frequent, common fixes are:

  • Narrow the prompt so it asks for fewer expensive checks
  • Ensure the agent has access to every tool it references
  • Move the run later if upstream systems are not ready at the current time
  • Split one overloaded trigger into two smaller ones, such as "Morning triage" and "Enterprise escalations review"

See Troubleshooting for common run and notification issues.

What you built

You now have a repeatable support triage workflow:

  • An agent that knows how to review Zendesk using your team's rules
  • A scheduled trigger that runs the triage automatically every morning
  • A predictable summary that highlights urgent work, SLA risk, and backlog
  • Run history and logs in the Tasks page for verification and debugging
  • Failure visibility through Slack notifications and task statuses

Instead of someone manually performing the same queue scan every day, the team starts with a structured operational summary. The process is faster, more consistent, and easier to improve over time.

Related guides