When does an AI agent use this pattern?

When the trigger described above matches the situation the agent is handling. The agent queries FusedFrames at runtime, this pattern is returned and the agent follows the recorded reasoning and steps to reach the recorded outcome.

How were the steps captured?

By the desktop app on the machine of someone who actually does this work. It records clicks, keystrokes, copy and paste, drag and drop, selected text and screen regions across Zendesk, then groups them into the meaningful steps shown above.

Where does the reasoning come from?

From the operator. When the desktop app sees a decision the action alone cannot explain, it asks why in the moment. The operator's answer is recorded and becomes the reasoning attached to the pattern, so the AI agent gets the thinking and not just the steps.

What if my team handles this differently?

Capture how your team actually does it. The desktop app records what your operator does on your tools and the web app distills that into a pattern shaped by your team. Each team's library reflects their own approach rather than the example shown here.

What if a case looks like this pattern but does not quite fit?

The pattern is linked to 1 alternative. The agent can follow the connections shown on this page to a related pattern that matches the case more closely.

How does my AI agent actually call this pattern?

Through the read-only REST API or the npm CLI. Create an API key in the dashboard, choose whether it accesses all libraries or specific ones and have your agent query at runtime. The response is structured JSON ready for tool use.

Is the data shown on this page from a live customer?

No. Example libraries on this site are illustrative. Patterns in your own account are built from your team's captured actions and stay private to your workspace.

How do I build a pattern like this for my team?

Install the desktop app on the machine of the person who already does this work, ask them to handle a real case end to end, then distill the captured action into a pattern in the web app. The pattern you end up with mirrors how your team actually operates.

Triaging a new Zendesk ticket and assigning a priority

When a new Zendesk ticket arrives in the unassigned queue, the support rep reads the body in full and sets the ticket form, priority and assignee group against the team's matrix. Enterprise tenants and watchlist accounts get bumped one priority step and an internal note records the priority reasoning for the next person who looks at the ticket.

Tags

zendesktriagepriorityformrouting

Lets your agent filter to the right pattern

Categories and tags scope the retrieval set, so your agent receives only the patterns relevant to the task instead of scanning the full library.

What and why

The observed behaviour and the reasoning behind it.

Behaviour

When a new Zendesk ticket arrives in the unassigned queue, the support rep opens it, reads the body fully, then sets the ticket form (Bug Report, Billing, Account, Onboarding), the priority (P1, P2, P3 or P4) and the assignee group. Priority is set against an internal matrix: P1 for a paid customer who is fully blocked, P2 for blocking with a workaround, P3 for an annoyance and P4 for a feature ask. Customers on the enterprise plan or with a tenant ID matching the watchlist are automatically bumped one priority step. The support rep then leaves a one-line internal note explaining the priority choice so the next person who looks at the ticket understands the call.

Reasoning

Priority drives the first-touch SLA, the auto-assignment rules and the macro the customer eventually sees when their ticket is held for engineering. Getting priority right at triage avoids the much louder mistake of escalating something that did not warrant it, or missing something that did. The enterprise bump exists because enterprise customers have higher commercial impact and explicit response-time commitments in their contracts. Writing the priority reasoning in an internal note prevents the cycle of teammates asking each other on chat why something was set to P1, and protects the support rep from looking inconsistent if a re-assignee disagrees later.

Gives your agent an operator's reasoning

Behaviour records the action; reasoning records the rationale. Your agent applies both to handle cases that diverge from the captured examples.

Cause and effect

What initiates this pattern and what it produces.

Trigger

A Zendesk ticket arrives in the unassigned queue, either submitted directly through the help form, forwarded by email or converted from an Intercom conversation.

Outcome

The ticket has a form, a priority and a group assignee that match the team's matrix. An internal note records the priority reasoning. Enterprise tenants and watchlist accounts have been bumped where applicable.

Tells your agent when to act and what to verify

Your agent stays within the scope set by the trigger and outcome, so it doesn't extend beyond the work or finish before the outcome is met.

Standard operating procedure

Step-by-step instructions to reproduce this pattern.

Zendesk

Open the unassigned queue and pick the next ticket. Read the body in full, including any attached screenshots or trace logs.

Skim-reading is the most common cause of priority mistakes. The body sometimes hides the real ask in the third paragraph (e.g. 'we're seeing this on the live tenant for our customer demo tomorrow morning').

Expected: You have a complete sense of what the customer is reporting and any deadline cues they have surfaced.

Zendesk

Set the ticket form by matching keywords in the body to the form list: Bug Report (error, broken, crash, 500, loop), Billing (invoice, VAT, refund, charge), Account (seat, role, permission, SSO) or Onboarding (setup, getting started, first time).

Set exactly one form. Forms drive the custom fields the customer is asked to fill in if the ticket reopens, and switching the form later loses any data already collected.

Expected: The ticket form matches the customer's primary issue.

Zendesk

Assign priority using the team matrix. P1: paid customer fully blocked. P2: blocking with workaround. P3: annoyance or polish issue. P4: feature ask.

Severity (impact on the customer) is not the same as priority (how soon we will act). A widespread visual glitch can be high severity and still be P3, because it does not block work. Resist the urge to set P1 just because the customer's tone is escalated.

Expected: The priority matches the matrix and reflects how soon the team should act, not how upset the customer sounds.

Zendesk

Check the customer organisation against the enterprise watchlist. If the tenant ID matches an enterprise plan or a strategic account, bump priority by one step (P3 to P2, P2 to P1).

The watchlist is maintained in the Zendesk organisation tags. Tenants tagged 'plan:enterprise' or 'watchlist' get the bump automatically. Smaller paid tiers do not.

Expected: Enterprise and watchlist tenants are at the bumped priority. Other tenants stay at the matrix-derived priority.

Zendesk

Set the assignee group based on the form: Bug Report goes to bug-triage, Billing goes to billing, Account and Onboarding go to support-general.

Always assign to a group, never directly to an individual at this stage. Direct assignment turns into an unanswered ticket the moment that person is on leave.

Expected: The ticket is in the correct assignee group's queue.

Zendesk

Add a one-line internal note explaining the priority choice (e.g. 'P2: blocking but workaround is to use the legacy export. Watchlist tenant Northwind, no bump needed because already P2.').

The note should let any teammate audit the priority decision in five seconds. Mention the matrix bucket and any bump or non-bump explicitly.

Expected: The ticket carries an internal note that justifies its priority and assignee group.

Hands your agent your team's exact steps

Your agent executes the documented procedure in order, against the applications named at each step, producing consistent output across human and agent runs.

Book a demo

Related patterns

How this pattern connects to other patterns in the library.

Often previous

Converting an Intercom conversation into a Zendesk ticket

Often next

Reproducing a customer-reported bug on a staging tenant Searching Linear for a duplicate engineering issue

Alternative to

Triaging an Intercom conversation by topic and intent

Lets your agent confirm the match and its scope

Alternative patterns let your agent compare candidates and select the closest match. Previous and next patterns define position in the workflow, so the agent operates within the scope of this one.

Supporting actions

Actions that provide evidence for this pattern.

Triaged Northwind Logistics #82441 as P1, bumped from P2 (enterprise)

Set Eastview Studios #82398 to P2, bug-triage group

Atlas Energy #82355 set P3, billing form, internal note added

Sundermark Capital #82310 P2, watchlist bumped from P3

Periwinkle Retail #82287 set P4, feature-request inbox

Shows your agent the evidence behind the pattern

Each pattern is derived from captured action sequences. Your agent can reference the source actions to verify any field, so nothing it acts on is authored by hand or hallucinated.

Metadata

Timestamps and identifiers.

Evidence	Observed 124 times across 5 connections
Applications	Zendesk
First seen	4 Feb 2026, 08:41
Last seen	6 May 2026, 16:32

Helps your agent rank patterns by confidence

Action count and last-seen timestamp weight each pattern by frequency and recency, so your agent selects the highest-scoring match rather than the first returned.

Questions

Frequently asked questions

Book a demo View all examples

Speak to the founder

Get a demo. Watch a live capture, then an AI agent query the result.

Ask anything. Pricing, security or integrating with your stack.

No purchase obligation

Book a call

Start capturing

Record in minutes. Install once and work as normal.

Plug AI agents in. One API call from any AI agent stack.

Refund on unused credits if you cancel