How can we help?

Articles in this section

See more

All About ServiceAI's Triage Feature

Ricky Cecchini
  • Updated

ServiceAI's Triage feature uses AI to automatically categorize, route, and enhance incoming tickets from your PSA system. Instead of relying on end users to correctly classify their issues or dispatchers to manually sort through every ticket, Triage reads the subject and description of each ticket and makes intelligent decisions about how it should be handled.

This article covers everything you need to know about enabling, configuring, and monitoring the Triage feature in ServiceAI.

Availability

Triage is currently available for the following PSA/ticketing systems:

  • ConnectWise — uses separate Routing, Categorization, and Assignment rule sets
  • Autotask — uses Unified Triage Rules
  • Zendesk — uses Unified Triage Rules, with support for ticket forms and auto-discovered custom fields
  • Halo — uses Unified Triage Rules
  • Syncro — uses Unified Triage Rules
  • Kaseya BMS — uses Unified Triage Rules

Syncro and Kaseya BMS use a manual webhook configuration in your PSA. For HaloPSA, ServiceAI creates the webhook when you save Triage settings with Triage turned on, and manual setup is the fallback. See Troubleshooting Triage Webhook Configuration for setup details.

Usage Limits:

  • Professional Tier: 200 ticket triages per month
  • Enterprise Tier: Unlimited triages

Your usage resets monthly, and you can view your current usage at the top of the Triage settings page.

Enabling Triage

To enable the Triage feature:

  1. Navigate to Settings from the gear icon in the top navigation bar
  2. Select the Triage (beta) tab from the settings menu
  3. Toggle Enable Triage to activate the feature
  4. Click Test Permissions to verify your PSA API user has the required permissions for the Triage Server
    • If you are not able to pass the permissions check, ensure that you have entered the appropriate permissions into ServiceAI based on your specific PSA.
    • For HaloPSA, this also checks that the API application has access to webhooks.
  5. Click Save Settings to confirm your changes

Once enabled, the full configuration options will become available, and the Triage tab will appear in your left-hand sidebar.

The Triage settings page is organized into four titled sections beneath the entry controls (Enable Triage, Test Permissions, and Testing Mode):

  • Fast Feedback — the agent summary and auto-response controls, including the auto-response template
  • Rules — the Triage Rules document (or, for ConnectWise, Routing Rules, the Categorization & Assignment Rules document, and Approved Feedback Rules)
  • Field Updates — Automatic Field Updates, Assignment Pool, and Priority Alert Keywords
  • Settings — monitored boards, ignore rules, spam destination, excluded sources, and the webhook configuration

Per-Company AI Triage

Each company has its own AI Triage toggle that controls whether ServiceAI triages tickets belonging to that company. The toggle appears as a pill with a state label and a switch in the header action bar of the Company detail page.

AI Triage is on by default for every company, so there is no change in behavior for existing Tenants — Triage continues to process tickets exactly as before unless you choose to opt a company out.

When you turn AI Triage off for a company, the webhook-driven triage workflow cleanly skips that company's tickets before any AI runs. Those tickets are not triaged and do not count toward your monthly triage usage. Unlike triage rules — which are guidance the AI interprets — this toggle is a reliable gate: a disabled company's tickets are always bypassed.

Changing the toggle requires Editor-level permission on the Companies module. To set it, open the company from Companies, then use the AI Triage control in the header action bar of the Company detail page.

Testing Mode

Before deploying Triage to actively modify tickets in your PSA, it's strongly recommended to enable Testing Mode. When Testing Mode is active, ServiceAI will analyze tickets and log what changes it would have made without actually modifying anything in your PSA system.

This allows you to:

  • Observe how the AI interprets and categorizes tickets
  • Fine-tune your rules before going live
  • Build confidence in the system's decision-making
  • Identify any adjustments needed to your Rule Sets

You'll see a clear indicator on triaged tickets showing "Testing Mode - No Changes Applied" when this mode is enabled.

Spam handling in Testing Mode: When Triage detects a ticket as spam while in Testing Mode, the triage result will display "Testing Mode - Spam Detected" along with the spam confidence score. Since Testing Mode does not modify your PSA, the ticket will not be moved to your Spam Destination board — the spam detection result is recorded for your review only.

Configuring Triage Rules

Triage uses plain-language prompts to define how tickets should be handled. This approach is designed to be more intuitive than traditional rule-based systems. Rules are no longer edited as a line-by-line list. Instead, each rule area is a single Markdown document that you author in a full-screen editor.

In the Rules section of Triage settings, each rule area shows a scrollable read-only display of the current document with an Edit button. Clicking Edit opens a blade with a full-screen Monaco editor where you can write and revise the entire document at once. Your changes are applied when you save the document and persist when you save your triage settings.

Using Comments in Rule Documents

Because rule documents are written in Markdown, you can add comments to organize your rules. Any line that starts with a hash followed by a space (for example, # Routing) is treated as a comment for your own organization and is stripped before the text reaches the AI. This lets you add headings, section labels, and commented-out example templates inline without affecting how the AI interprets your rules.

A hash that is not followed by a space (for example, #1 priority or #urgent) is preserved as real rule content and is sent to the AI. Keep this distinction in mind when a rule legitimately needs to begin with a hash.

Triage Rules (Autotask, Zendesk, Halo, Syncro, Kaseya BMS)

For Autotask, Zendesk, Halo, Syncro, and Kaseya BMS, ServiceAI uses a single unified Triage Rules document rather than separate Routing, Categorization, and Assignment sets. One document drives every decision the AI makes about a ticket, which is then evaluated in a single combined AI analysis per ticket.

This approach has two benefits:

  • Rules read more naturally because they can describe routing, categorization, and assignment in the same sentence
  • Triage runs one AI call per ticket instead of three, reducing latency and AI cost

Triage Rules use each PSA's native field terminology in the prompt, so the AI is aware of the exact field names it is being asked to update.

Example rules:

  • "Printer and copier tickets should be routed to the Hardware Support queue and categorized as 'Hardware' with sub-issue 'Printer/Copier'"
  • "Network tickets should be assigned to Samuel Smith and use the Network Team queue"
  • "Password reset requests should use the Tier 1 Support queue and be categorized as 'Account Access'"

For Zendesk, your Triage Rules can also reference ticket forms and their form-specific custom fields. The AI will select the appropriate form and populate its fields during the same triage pass.

Edit the document by clicking Edit on the Triage Rules display in the Rules section of Triage settings.

ConnectWise Rules

ConnectWise is handled differently from the other PSAs. Because its categories, types, and assignees are board-dependent, routing must be decided before categorization and assignment can be evaluated. The Rules section for ConnectWise therefore shows three parts: Routing Rules, a single Categorization & Assignment Rules document, and Approved Feedback Rules. Routing is applied first, and the Categorization & Assignment Rules document is read by both the categorization and assignment steps.

Routing Rules determine where tickets should be sent based on their nature. Use these to direct tickets to specific boards in ConnectWise. Example: "Printer and copier tickets should be routed to the Hardware Support board."

The Categorization & Assignment Rules document covers both the correct Type and SubType and the appropriate technician assignment. The categories must exist in ConnectWise on their respective boards, and assignment works best on specifically-named resources within ConnectWise. Examples: "Printer tickets must have the category 'Hardware' and subcategory 'Printer/Copier'." and "Network tickets should always be assigned to Samuel Smith."

Approved Feedback Rules lists the Tenant-wide rules that you approve through Issues. Routing, categorization, and assignment all read them alongside their own rules, so you can review and edit them here.

Like the unified Triage Rules document, all three ConnectWise rule areas are edited in the full-screen Monaco editor and support Markdown comments using the hash-followed-by-space syntax described above.

Agent Mode Rules in Triage Briefings

The Agent Mode Rules you configure under Settings > Rules (the same Agent Mode Rules that shape AI Chat in Agent mode) now also shape the wording of the Fast Feedback agent summary internal note that Triage posts back to your PSA. This lets a single set of coaching rules govern both the in-app AI Chat in Agent mode and the post-triage briefing that lands on the assigned technician's ticket.

For example, an Agent Mode Rule like "Always confirm device patch status before recommending a reboot" will now bias the agent summary section of the triage internal note in the same way it biases AI Chat in Agent mode. Routing, categorization, assignment, and field decisions are governed by the Triage Rules above — Agent Mode Rules are scoped to the agent-summary text only and do not influence routing decisions.

If your Tenant has no Agent Mode Rules of its own, the system defaults are used instead.

Triggering Actions From Triage Rules

If you have built one or more Actions (reusable webhook automations) and set them to Use in Triage, Triage can run them automatically while it analyzes a ticket. A Triage-mode action is exposed to the triage AI as a tool, and the AI decides when to invoke it based on your plain-language Triage Rules — there is no separate action-matching screen to configure. The AI runs an action only when one of your Triage Rules names it and the ticket meets that rule's condition, and text inside a ticket cannot trigger one.

To wire an action into triage:

  1. Create the action under Settings > Actions and set its mode to Use in Triage. See Using Actions: Reusable Webhook Automations in ServiceAI for how to build the webhook request and store any secrets it needs.
  2. In your Triage Rules document, add a plain-language rule that tells the AI when to run the action, referring to it by the name you gave it. For example: "When a ticket reports a server outage, run the Create Major Incident action."
  3. Save the rules document, then save your triage settings.

During triage, the AI constructs the action's request from the ticket's details and fires it whenever your rules call for it. Every run is recorded in the action's run history, where you can review exactly what was sent and retry it if needed.

Best Practices for Rules

  • Keep rules clear and straightforward to avoid contradictions
  • While there's no hard limit on the number of rules, be reasonable — too many overlapping rules can cause confusion
  • Use specific language and exact field names in quotes when possible
  • Start with a few key rules and expand as you observe the AI's behavior
  • Don't try to spread tickets across several people with rule wording such as "assign evenly," "round robin," or "don't assign the same person twice in a row." Triage evaluates each ticket on its own, so use the Assignment Pool instead.
  • Assignment rules can refer to the ticket number and to whoever the ticket is currently assigned to — for example, "only set the Resource when the ticket is unassigned or assigned to an API user"

Fast Feedback

Fast Feedback adds two AI-drafted outputs to every triaged ticket: an agent summary posted as an internal note for the assigned technician, and an optional auto-response posted publicly to the requester. Both are produced by the same dynamic-query workflow that powers AI Chat and the public chat experience, so a customer asking through a ticket gets the same caliber of answer as one asking through your chat page. Available for all supported PSAs.

Enable Agent Summary

When enabled, ServiceAI posts an internal note headed AI Technical Summary on each triaged ticket containing a concise, technician-facing summary of the issue, what's been tried, and a suggested next step. The summary now uses the full AI Chat toolset — it can mine similar tickets and KB articles while drafting — so the briefing is grounded in your tenant's own historical context.

The internal note also includes:

  • A Confidence indicator showing how confident the AI was in the underlying analysis
  • A Related tickets section listing similar past tickets, with PSA-native links so technicians can jump to the source ticket inside their PSA
  • A Related KB articles section listing up to five knowledge base articles the AI consulted while writing the summary and reply (articles it cites come first, and articles without a link are skipped), with links that resolve correctly for both external sources (ITGlue, ConnectWise KB, etc.) and articles created inside ServiceAI

Enable Auto-Response

When enabled, ServiceAI can post a public-facing reply to the requester only when the AI's confidence in the response meets your configured threshold. The auto-response runs through the same dynamic-query workflow as the public chat at /chat?tenant=…, so it can search your KB and (when allowed) consult ticket history while drafting.

Because the reply is posted on the ticket the requester already submitted, it never tells them to open a ticket or contact support. When a person needs to get involved, the reply says that a technician will follow up on the ticket or invites the requester to reply with more details. A reply that tells the requester to submit a ticket is scored very low, so it normally falls below the threshold and is held back as an internal note instead of posting publicly.

Below-threshold drafts are not posted publicly — instead, they are surfaced as a dedicated internal note so you can review what the AI would have said and tune the threshold accordingly.

Every public auto-response ends with a clear AI disclaimer indicating that the reply was AI-generated, that a technician is still reviewing the ticket, and inviting feedback on response quality.

Auto-Response Template

The Auto-Response Template customizes the wrapper applied around the AI-drafted body. The template uses {{ai-response}} as the placeholder for the AI body. Common uses include adding your MSP's signature, branding the disclaimer, or adjusting the tone of the wrapper to match your customer-facing voice. ServiceAI does not edit your template: if the template itself contains a link or wording that asks requesters to submit a ticket, edit the template to remove it.

The template is shown as a scrollable read-only display with an Edit Template button. Clicking Edit Template opens a blade with the same full-screen Monaco editor used for triage rules, where you can revise the wrapper text. Your edits persist when you save your triage settings.

The display pre-fills with the built-in default so admins can see (and edit) the operative wrapper text. Use Restore default to revert to the built-in default. If your saved template equals the current default exactly, ServiceAI clears your override so future improvements to the default automatically apply.

The Auto-Response Template is only editable when Enable Auto-Response is on.

Formatting tip: The template is written in Markdown. Use **bold** for emphasis (for example, to call out a disclaimer line) rather than Markdown headings (# or ##). Several PSAs render Markdown when the comment is posted, so a heading line is shown as a large H1/H2 that looks out of place next to the normal-sized response body. Bold renders consistently everywhere. See Zendesk-Specific Triage Behavior for an example.

Allow Ticket Data to Be Used to Generate Response

When this toggle is on (default), the auto-response can consult your tenant's ticket history while drafting — useful when a public answer would benefit from prior resolutions for the same issue. When off, the auto-response is restricted to KB and web search, matching the toolset available to anonymous public chat.

Confidence Threshold

The Confidence Threshold controls how confident the AI must be before its drafted response is posted publicly. Default is 90%. Accepts any value from 0% to 100%:

  • 0% — every draft is posted publicly
  • 90% (default) — recommended starting point
  • 100% — only the very highest-confidence drafts post publicly

The Confidence Threshold input is enabled only when Enable Auto-Response is on. The confidence score is a combined score that ServiceAI calculates, not the AI's own rating alone. It gives equal weight to the AI's rating of its draft and to how well your knowledge base supports the answer, measured by the best-matching article the AI retrieved while writing the reply. Thin ticket information (for example, no company or category, a short description, or a requester with no resolved tickets) lowers the score by at most 5%.

Knowledge base support cuts both ways: a strong match with a relevant article raises the score, and no match lowers it. As a result, well-documented questions are more likely to clear the threshold, and questions your knowledge base doesn't cover are less likely to. A drafted reply that no knowledge base article backs scores well below the default 90% threshold, so it is held as an internal note.

Reviewing Below-Threshold Drafts

When auto-response is enabled but a draft falls below the configured threshold, the draft is posted as an internal note that includes the assessed confidence and the threshold in effect. This is the recommended way to tune your threshold — review a few weeks of below-threshold drafts and lower the threshold once you're comfortable with the quality at that confidence level.

Tip: If well-documented questions still fall below the threshold, check that the relevant knowledge base article is synced to ServiceAI and is not marked internal — internal articles are not used when drafting a customer response. To see how tickets actually resolved, with or without a posted reply, see Resolution Attribution.

Testing Mode and Fast Feedback

While Testing Mode is on, neither the agent summary nor any public response is posted to the PSA, regardless of the Fast Feedback toggles. The drafted content is still recorded in the Triage Detail view so you can preview it.

Additional Configuration Options

Monitored Boards/Queues

Specify which boards or queues ServiceAI should monitor for triage. Select one or more from the list, which is populated from your PSA. The field is labeled with your PSA's own term — for example, Monitored Boards for ConnectWise or Monitored Queues for Autotask. At least one selection is required while Triage is enabled. This allows you to control exactly where Triage operates rather than having it run across all boards.

If ServiceAI has not yet cached your PSA's boards or queues, a text box appears instead of the list. Enter the names separated by commas; the list replaces the text box after the next cache refresh.

Ignore Ticket Rules

Optionally list phrases that you do not wish to allow ServiceAI to triage. This is helpful for things like RMM alerts, backup reports and more - anything that you don't want to waste triage credits on.

By default, each rule matches against the ticket subject. A rule can be a plain phrase, which matches when the phrase appears anywhere in the subject, or it can include the * wildcard to stand in for any text — for example, disk space alert* matches any subject that starts with "disk space alert", and *backup*failed* matches subjects containing "backup" followed by "failed". Matching is not case-sensitive, and line breaks or extra spaces in the ticket text don't stop a phrase from matching, so a phrase still matches alert text that wraps across lines.

Also Match the Ticket Description: Turn on this toggle, directly below the rules list, to apply your ignore phrases to the ticket body as well as the subject. It is off by default. Use it for monitoring and RMM alerts whose identifying text appears only in the ticket body. It works for every supported PSA.

Review your phrases before you turn this toggle on. A short, general phrase that was safe to match against subjects (such as "alert" or "vpn") can match a great many ticket bodies, and an ignored ticket is skipped silently — it gets no entry in the Triage log and uses no triage credit.

Ignore Ticket Rules are enforced for every supported PSA — ConnectWise, Autotask, Zendesk, Halo, Syncro, and Kaseya BMS. Matching tickets are skipped before triage runs, so they do not consume triage credits. Changes to your rules take effect within about a minute.

You can add as many rules as you like by selecting the + Add Rule button. The rules list pages through all of your rules, so every rule you have added is visible.

Excluded Sources

Use the Excluded Sources multi-select to prevent Triage from processing tickets that originate from specific sources in your PSA. This is useful when certain ticket sources (such as RMM integrations, monitoring tools, or automated email addresses) create tickets that should not consume triage credits or be modified by AI.

How to configure:

  1. Navigate to Settings > Triage
  2. Scroll to the Excluded Sources field under Additional Configuration Options
  3. Select one or more sources from the dropdown — the list is populated from your PSA's available ticket sources
  4. Click Save Settings

Tickets arriving from any excluded source will be silently skipped by Triage. They will not appear in the Triage log, will not count against your monthly triage limit, and will not be modified in your PSA.

Tip: This works well alongside Ignore Ticket Rules (which filter by subject line content and, optionally, the ticket description). Use Excluded Sources when entire ticket sources should be bypassed, and Ignore Ticket Rules when you need keyword-based filtering within sources you otherwise want triaged.

Spam Destination

Optionally specify a board or queue where spam tickets should be moved. The AI detects spam tickets regardless of this setting; when a destination is specified, detected spam is routed there. Leave this blank if you do not want spam tickets moved — they are still detected, but are left in place rather than routed to a destination.

Known Senders in Spam Detection

When a ticket's requester email address matches an existing user in your Tenant, spam detection is told that the sender is likely a real user who may be reporting a problem. This helps avoid false positives when end-users in your client environments submit tickets that happen to use phrasing common in spam (security alerts, password reset requests, etc.).

A known sender is not excluded from spam detection. The AI still makes the final decision, because email addresses can be spoofed. The match is made on the full email address (not case-sensitive) rather than on the domain, so an address at a free email provider such as gmail.com or outlook.com is treated the same as any other address.

Automatic Field Updates

Select which ticket fields the AI is allowed to automatically update. Available options may vary based on your PSA, but typically include:

  • Subject
  • Category/Type
  • SubCategory/Subtype
  • Classification/Item/Configuration
  • Priority
  • Estimated Time
  • Board/Queue (Routing)
  • Source (ConnectWise, Autotask, Halo, and Kaseya BMS)
  • Assignee (Owner in ConnectWise, Resource in Autotask, and Agent in Zendesk, Halo, Syncro, and Kaseya BMS)
  • Company (labeled Organization, Customer, or Account in some PSAs)
  • Ticket Type (Autotask only)

The Work Type checkbox (ConnectWise, Autotask, and Halo) and the Billing Code checkbox (ConnectWise and Autotask) also appear, but Triage cannot update these fields. Enabling them has no effect, and Triage Details marks them as Unsupported.

Only enable the fields you want the AI to manage. This gives you granular control over what changes Triage can make. The Ticket Type option appears only for Autotask tenants.

Selecting a field is what permits Triage to change it. You do not need a triage rule before Triage will set Priority, Estimated Time, Board/Queue, or the assignee — rules still guide how Triage chooses a value, but they are not what allows the change. Triage still needs a basis in the ticket: it changes Priority only on concrete evidence (the ticket's content, a Priority Alert Keyword, or the requester's own answer to an urgency question), never on general impression, and it changes the Board/Queue only when another option fits the ticket better than the current one. Triage changes Source only when the ticket itself says how it arrived — for example, the requester says they phoned, or the ticket is a forwarded email — and otherwise leaves it unchanged.

The Automatic Field Updates allow-list is honored end-to-end: the Triage Details page, the AI's prompt, and the actual PSA writes all use the same enabled-field set. Fields you have not enabled are not shown as proposed changes in Triage Details, are not included in the AI's analysis prompt, and are not written back to your PSA — so you only ever see and act on field changes for fields you have explicitly allowed.

Triage writes only values that exist in your synced PSA options. A suggested value that isn't one of your options is dropped instead of being written, and Triage Details lists it as Invalid value. For classification values on the PSAs that use the unified Triage Rules document, Triage makes one more attempt that offers the AI only that field's own options before dropping the value. For Autotask and Kaseya BMS, a Sub-Issue Type must also belong to the Issue Type Triage selected, or to the ticket's current Issue Type if Triage leaves Issue Type unchanged. A Sub-Issue Type that exists in your PSA under a different Issue Type is dropped rather than written, and Triage Details lists it with the reason.

Assignment Pool

The Assignment Pool rotates ticket assignment evenly across a fixed set of agents that you choose, instead of letting your triage rules pick the assignee. Use it when you want tickets distributed evenly: rule wording such as "distribute evenly," "round robin," or "don't assign the same person twice in a row" can't be enforced, because Triage evaluates each ticket on its own.

The Assignment Pool is available for every supported PSA. It assigns through your PSA's assignee field: Owner in ConnectWise, Resource in Autotask, and Agent in Zendesk, Halo, Syncro, and Kaseya BMS.

How to configure:

  1. Navigate to Settings > Triage
  2. In the Field Updates section, make sure your assignee field (Owner, Resource, or Agent) is selected under Automatic Field Updates
  3. Under Assignment Pool, turn on Assign from a pool instead of from triage rules
  4. Select the agents to rotate through. You can type a name to filter the list, and agents who are inactive in your PSA are marked (inactive).
  5. Click Save Settings

Settings will not save while the pool is turned on with no agents selected, or while the assignee field is not selected under Automatic Field Updates. The message tells you which one to fix.

How the pool assigns tickets:

  • Tickets are dealt out in turn by ticket number, so consecutive tickets go to consecutive pool members and the spread stays even. A given ticket always maps to the same person.
  • While the pool is on, triage rules no longer decide assignment, but they still drive every other field
  • Anyone not in the pool — such as API users, shared helpdesk accounts, or agents who only appear on older tickets — is not assigned while the pool has an assignable member. A ticket already assigned to someone outside the pool is reassigned to a pool member.
  • A ticket already assigned to a pool member keeps that member, so triaging it again never moves it to a different technician
  • Pool members who are inactive in your PSA, on your agent exclusion list, or (on Autotask) not assignable because they have no service desk queue or service desk role are skipped. If no pool member can be assigned, Triage falls back to rule-based assignment rather than leaving the ticket unassigned.
  • A pool of one agent sends every ticket to that agent

The selected agent is written to the ticket's Owner, Resource, or Agent field and shown as the assigned agent in Triage Details.

Who Triage Can Assign

Whatever your rules say, and whether or not the Assignment Pool is on, Triage assigns tickets only to agents who can actually take them:

  • Agents who are inactive or disabled in your PSA are never assigned, even if a triage rule names them. ServiceAI refreshes each agent's active status from your PSA on every sync, so an agent you disable in your PSA drops out after the next sync. You don't need rule wording such as "don't assign inactive agents."
  • Agents on your Agent ID Exclusions (All) list under Settings > Exclusions are never assigned, even if a triage rule names them
  • Autotask API-only resources, such as the API user ServiceAI connects with, are treated as inactive and never assigned. Autotask reports these resources as active because the integration signs in with them.
  • Autotask resources that are not a member of any Service Desk queue, or that have no active service desk role, are never assigned, because Autotask rejects them as assignees. ServiceAI checks this on each Autotask sync. If a resource doesn't appear as a candidate, add them to a service desk queue and give them a service desk role in Autotask, then run a sync.
  • For Zendesk, ServiceAI syncs your full list of Zendesk agents and admins on every sync, so a rule can name an agent who hasn't worked a ticket yet

If a rule names an agent Triage can't assign, the ticket is left unassigned rather than given to someone else. Triage Details explains why in the list of enabled fields that were not written: the agent is not active in your PSA, the agent is on your agent exclusion list, the agent can't be assigned tickets in Autotask (no service desk queue or service desk role), or no active agent with that ID is synced to ServiceAI. If every synced agent is on your exclusion list, Triage Details says so, which tells you to review the list rather than re-sync your PSA. Likewise, if none of your active Autotask resources can be assigned tickets, the Resource field shows No options and Triage Details says that each is missing a service desk queue or an active service desk role. These explanations appear only when the assignee field is selected under Automatic Field Updates.

Priority Alert Keywords

Define keywords that trigger automatic priority escalation. When these keywords appear in a ticket's subject or description, the ticket will be flagged for priority handling.

Common examples include: bitcoin, breach, encrypted, hacked, malware, ransom, ransomware, virus

You can add custom keywords relevant to your business by entering them in the field (minimum 3 characters) and clicking + Add.

Viewing Triage Results

Once Triage is running (in either Testing Mode or live), you can view the results by selecting Triage from the left-hand sidebar. This area serves as a log of all triage decisions made by the AI.

Confidence-style columns in the Triage grid (Spam Confidence, Duplicate Confidence, Routing Confidence, Fast Feedback Confidence) all render as percentages.

To find a ticket, type all or part of its PSA ticket number into the filter at the top of the ticket ID column. The filter accepts letters and numbers (for example, Autotask's T20250611.0001) and matches any ticket whose number contains what you typed.

Triage Details View

Selecting an individual triaged ticket shows you the complete decision-making process the AI followed:

  • Ticket Received: Shows when the ticket was received, along with the Ticket ID, Original Subject, Requester Name, Requester Email, and a summary of the issue.
  • Spam Detection: Displays whether the ticket was flagged as spam or marked as clean, including a confidence percentage and reasoning.
  • Routing Analysis: Shows any routing changes made (or that would be made in Testing Mode) based on your Routing Rules.
  • Duplicate Detection: Indicates whether the ticket appears to be unique or a duplicate of an existing ticket. Triage now also recognizes forwarded copies of an existing ticket as duplicates of the original — previously, an email submitted as a ticket and then forwarded to the support mailbox could result in two separate tickets without a duplicate relationship. The forwarded version is now linked back to the original ticket and surfaced in the Duplicate Detection section just like any other duplicate match.
  • Field Classification: The core of the triage decision — shows the before and after values for each field the AI updated. Only the fields you have enabled under Automatic Field Updates appear here; disabled fields are not shown as proposed changes and are not written back to your PSA. Ticket Type (Autotask) and Source changes also appear here when Triage sets them.

Assignment Analysis: Displays any technician assignment decisions based on your Assignment Rules, or made by the Assignment Pool when it is enabled.

Ticket Updated: At the bottom, you'll see processing time, current mode (Testing or Live), and a status badge showing what happened in your PSA: Changes Applied to PSA, Partially Applied (some changes were written and others were not), PSA Rejected Update (none of the field changes were written), or Testing Mode - No Changes Applied. When an update is only partly applied or is rejected, a short explanation appears under the badge. In Testing Mode, this step is titled Ticket Not Updated, and a note confirms that no changes were made to the ticket in your PSA system.

Under Fields Configured for Update, every field you enabled under Automatic Field Updates appears as a badge. A green badge with a check mark means the change was written. Hover over a badge to see the reason for its result.

Below the badges, a list titled Enabled fields that were not written (Enabled fields not written in this test run in Testing Mode) gives each remaining field an outcome badge and a plain-language reason:

  • No change — the AI found no basis for changing the field
  • Invalid value — the suggested value isn't one of your synced PSA options (on Halo, also a value with no matching HaloPSA option), or an assignment rule named an agent Triage can't assign
  • No options — no options were available for the field, either because none are synced yet (re-syncing your PSA usually resolves this) or because none are configured for the ticket's board or parent value
  • Options unavailable — the options couldn't be loaded for this run, which is usually temporary
  • Unsupported — Triage can't update the field on your PSA (Work Type and Billing Code), so enabling it has no effect
  • Rejected — your PSA refused the value and it was dropped from the update, or (on Halo and Zendesk) your PSA accepted the update but did not set the field on the ticket, so it is not recorded as written
  • Not attempted — nothing was written because Triage is in Testing Mode, the ticket was classified as spam, your PSA rejected the whole update, or the update was interrupted before ServiceAI could confirm the field (for example, a timeout or a PSA error partway through a Halo update)

Because this list also appears in Testing Mode, you can see exactly which fields would and would not be written before you go live. Older triage records show only the field badges.

Resolution Attribution

For tickets where Fast Feedback drafted a customer response, Triage Details can show a Resolution Attribution panel that records who actually resolved the ticket once it closed. The panel appears in the Fast Feedback area of Triage Details, directly under the Customer Response. There is nothing to turn on, and the assessment is read-only: it posts nothing to your PSA and changes no ticket.

The panel appears only when all of the following are true:

  • The ticket was triaged in live mode, not Testing Mode
  • Fast Feedback drafted a customer response (Enable Auto-Response was on), whether or not the reply was posted
  • The ticket is closed in your PSA and has been closed for at least 48 hours

Assessments run nightly, so it's normal for recently closed tickets not to show the panel yet.

The panel shows one of these outcomes:

  • Rapid Response — the ticket closed after the auto-response with no technician reply
  • Technician — a technician had already replied publicly before the auto-response, or the conversation continued after it with more than two customer replies or more than two technician replies
  • Auto-Closed (No Resolution) — no one replied after the auto-response and the ticket closed five or more days later, which usually means your PSA closed it for inactivity
  • Indeterminate — a technician replied once or twice after the auto-response, so ServiceAI can't tell whether they confirmed the answer or solved the issue independently, or the ticket saw activity after it closed

When no reply was posted (for example, because the draft fell below your Confidence Threshold), the panel also shows a Comparison Group badge. These tickets are assessed by exactly the same rules to give you a baseline. A Comparison Group ticket that closed with no technician reply is labeled Rapid Response even though no auto-response was sent, which is what makes the two groups comparable.

Below the outcome, the panel shows a one-line explanation; for Rapid Response outcomes, the customer's own words confirming the fix, quoted from the ticket, when available; and the details behind the verdict: Time to close, Customer replies after, Technician replies after, Technician replies before, Reopened after close (when it applies), and when the ticket was Assessed.

Comparing the outcomes of posted replies with the Comparison Group over time is a good way to judge whether your Confidence Threshold is set well.

Ticket Persistence

Triaged tickets remain in the Triage log even if they're deleted from your PSA. This log specifically serves as a historical record to understand the AI's decisions at the time of processing.

If your PSA sends a notification for a ticket it can no longer find by the time Triage reads it (for example, because the ticket was deleted or merged), Triage skips that ticket. No entry appears in the Triage list, and it does not count toward your monthly triage usage.

Zendesk-Specific Triage Behavior

In addition to the unified rules above, Zendesk triage has a few integration-specific capabilities:

  • Ticket forms: ServiceAI auto-discovers the ticket forms configured in your Zendesk instance, along with each form's field layout. During triage the AI can select the appropriate form and update its form-specific custom fields in a single pass
  • Picklist auto-discovery: Standard and custom ticket field picklists, groups, and agents are refreshed automatically — no manual list maintenance is required
  • Comments: When comment creation is enabled, Triage posts its decision as a comment on the Zendesk ticket
  • Fields Zendesk accepts but does not apply: If Zendesk accepts an update but does not set a field, for example an agent who isn't assignable in the ticket's group, Triage Details lists that field as Rejected and shows the update as Partially Applied
  • Markdown rendering in comments: Zendesk interprets Markdown in the comment body, so any formatting in your Auto-Response Template is rendered when Triage posts the comment. Use **bold** for emphasis and avoid #/## headings — Zendesk displays those as oversized H1/H2 text that does not match the rest of the response. Other PSAs such as Autotask and Kaseya strip or convert Markdown, so this oversized-heading effect is specific to Zendesk.

Recommendations to Get Started with Triage

  1. Start with Testing Mode enabled to observe AI behavior without risk
  2. Begin with a limited set of monitored boards rather than all boards at once
  3. Add a few clear routing and categorization rules based on your most common ticket types
  4. Review the Triage log regularly to identify patterns and refine your rules
  5. Gradually expand your rule sets and monitored boards as you gain confidence
  6. Disable Testing Mode only when you're satisfied with the AI's decision-making

Triage is designed to reduce the manual effort of ticket categorization and routing while ensuring tickets get to the right place faster. By using natural language rules, you can customize the AI's behavior to match your team's specific workflows and preferences.

PSA Field Name Reference

ServiceAI uses the native field names from your PSA system, so your Triage Rules and the changes shown in the Triage Detail view speak in your PSA's own terminology. The table below maps each internal ServiceAI triage field to its native name in every supported PSA. A dash (—) means the PSA either has no equivalent field or does not expose it for triage, so it will not appear as a checkbox under Automatic Field Updates or as a proposed change in the Triage Detail view for that system.

ServiceAI Field ConnectWise Autotask Halo Zendesk Kaseya BMS Syncro
Subject Summary Title Summary Subject Subject Subject
Routing Board Queue Team Group Queue —
Category Type Issue Type Ticket Type Category Issue Type Ticket Type
Subcategory SubType Sub-Issue Type Category 1 Subcategory Sub-Issue Type —
Classification Item Ticket Category Category 2 Classification — —
Priority Priority Priority Priority Priority Priority Priority
Status Status Status Status Status Status Status
Work Type Work Type Work Type Work Type — — —
Estimated Time Budget Hours Estimated Hours Estimated Hours — — —
Billing Code Billing Code Billing Code — — — —
Ticket Type — Ticket Type — — — —
Source Source Source Source — Source —
Agent Owner Resource Agent Agent Agent Agent
Company Company Company Customer Organization Account Customer

These labels appear throughout the Triage Detail view, Triage Settings checkboxes, and Triage grid column headers, and are the exact terms to use when you reference a field in your Triage Rules.

A few PSA-specific notes:

  • Zendesk additionally supports Form and Custom Fields. ServiceAI auto-discovers your ticket forms and their form-specific custom fields, and can select the correct form and populate its fields during the same triage pass.
  • Syncro has no Subcategory or Classification level, and its routing field (Problem Type) is free-text rather than a fixed picklist, so ServiceAI does not automatically route Syncro tickets. Syncro triage covers Subject, Ticket Type (Category), Priority, Status, Agent, and Company.
  • Kaseya BMS has no Classification, Work Type, Estimated Time, or Billing Code fields available for triage.
  • Ticket Type is an Autotask-only field and appears only for Autotask tenants.
  • Work Type and Billing Code appear as Automatic Field Updates checkboxes for some PSAs, but Triage does not currently update them. Triage Details reports them as Unsupported.
  • Source appears as an Automatic Field Updates checkbox for ConnectWise, Autotask, Halo, and Kaseya BMS. Triage changes it only when the ticket itself says how it arrived.

Recovering a Spam-Flagged Ticket

If a ticket was incorrectly identified as spam and deleted, you can restore it directly from ServiceAI:

  1. Enable the Show Deleted toggle on the Tickets page to display spam-deleted tickets.
  2. Click on the ticket to open its detail view.
  3. Click the Include in AI button to restore the ticket.

Once restored, the ticket will be re-included in AI analysis. The spam flag is cleared so it will not be re-deleted on the next sync.

Note on PSA Internal Notes

ServiceAI no longer posts an internal note to your PSA system when a ticket is identified as spam. Spam detection is handled silently within ServiceAI to avoid cluttering your PSA ticket history.

Triage Rule Syntax: Common Mistakes

Triage Rules in ServiceAI are written as plain natural-language sentences. They are not parsed as code, so programming-style expressions, comma-separated quoted lists, and if/then blocks will not be evaluated the way you might expect.

Avoid:

if contains File Share Event - External, File Upload Limit Exceeded, Stale Account Clean Up change queue to Network Alerts

Use instead:

Tickets with subjects containing File Share Event - External, File Upload Limit Exceeded, or Stale Account Clean Up should be routed to the Network Alerts queue.

When a triage rule is not firing as expected, double-check the following:

  • The rule is phrased as a natural-language sentence rather than a code-like expression.
  • The rule lives in the Triage Rules document for your PSA.
  • The queue or board name in the rule exactly matches the queue or board name in your PSA.
  • Triage is not currently in Testing Mode.
  • The field you are trying to update is enabled under Automatic Field Updates.
  • Open the ticket in Triage Details and read the reason listed for the field under Enabled fields that were not written. It tells you whether the value was invalid, was rejected by your PSA, had no options to choose from, or the AI found no basis for a change.

Related articles

Comments

0 comments

Article is closed for comments.