Skip to main content
Ticket Triage can move tickets to the right queue or board. It also analyzes incoming tickets and fills in important details like priority, type, company, and contact information.

​
Quick start

1

Add to new ticket workflow

Add the action to workflows triggered by “New ticket created” to automatically categorize incoming tickets.
2

Choose fields to fill

Use the Add field to triage button and pick the fields you want completed - priority, type, company, contact, custom fields, and so on. The picker stays open, so you can add several in a row, and it only lists the fields your PSA supports.
3

Add custom instructions (optional)

Open a card’s Advanced settings and turn on Use your own instructions to give Neo specific guidance for that field.
4

Add update action

Follow with “Update Ticket Fields” to actually apply the suggested changes to your tickets.

​
Configuring the fields

Each field you add becomes its own card. The card names the field and says in one line what Neo does with it, so a whole triage setup reads top to bottom without opening anything.
  • Adding a field: use the Add field to triage button. A field you already added drops out of the list, so you cannot triage the same one twice.
  • Nothing to fill in: most fields work straight away on Neo’s defaults. Priority, Status, Type and the rest ask you nothing when you add them.
  • A custom field asks for two things: its name in your PSA, and where its options come from. Those sit directly on the card, because Neo cannot triage the field without them.
  • Tuning a field: everything optional lives under the card’s Advanced settings. You get only the settings that field actually has - the ones for other fields are not shown.
  • Reading a saved setup: each card shows a small tag for every setting you changed, for example Custom instructions or Limit the options: 3.
  • Changing a field: remove the card and add a new one for the field you want instead.
  • After triage: moving the ticket to a board or queue is a separate step at the bottom, not one of the fields.

​
How it works

The action:
  1. Analyzes ticket content - Reviews title, description, conversation history, and related information. Screenshots are read with a vision model and .eml and .pdf attachments are read as text, so a custom instruction can use what is in them (see Reading Images and Reading Email and PDF Attachments)
  2. Identifies key details - Extracts company, contact, and issue type information
  3. Applies smart categorization - Uses patterns from past tickets and your custom instructions
  4. Sets appropriate priority - Determines urgency based on impact and affected users
  5. Suggests field updates - Provides recommendations for all configured fields
The action processes fields in order: basic information such as company and contact first, then categorization, then priority.

​
Autotask contract options include exclusions

When triaging the contract field on Autotask, each contract option also tells Neo which work types that contract does not cover, so it can separate covered work from billable work instead of falling back to the company default:
This lets you write instructions like “never pick a contract whose exclusion list contains the ticket’s work type”. Neo reads this from your contracts’ exclusion sets and any per-contract exclusions you have configured in Autotask, and covers both at once. Nothing appears for a contract that has no exclusions configured, including one that points at an exclusion set you have left empty. In that case, Autotask itself holds no exclusion data for Neo to use. If a contract’s exclusions are missing from triage, check that its exclusion set actually lists work types in Autotask.

​
Syncro fields you can triage

On Syncro, the field picker offers: Neo only picks from the problem types your Syncro account already has. Add one in Syncro and triage can use it straight away: it reads the list from Syncro rather than waiting for a sync.
Syncro itself accepts any text in Problem Type, so it will not reject a value that is not on your list. Neo restricts itself to your list, which is what keeps the field consistent enough to report on.

​
Syncro tags

Syncro has no fixed tag list, so tell Neo what to apply in the field’s custom instructions. This is the same as tags on Autotask. Triaging a tag adds it. The ticket’s existing tags are left alone, and re-running the workflow will not add a duplicate. Turning on Let Neo clear this field lets Neo clear the tags instead, which removes all of them. Syncro’s API has no way to remove just one.
Triage Ticket Type before Custom Field in the same workflow. Neo already orders it that way: the type decides which custom fields a ticket can hold, so settling it first is what makes custom-field triage useful.

​
Syncro custom fields

Custom fields in Syncro belong to a ticket type, so a ticket can only hold the fields its type defines. Enter Custom field name on the card exactly as it appears in Syncro. Capitalisation does not have to match, but the name does. If the name matches no field on that ticket’s type, the workflow stops with an error listing the fields the ticket does have. That is deliberate: Syncro accepts an unrecognised field name without complaint and saves nothing, so a silent success would be worse. Updating one custom field leaves the ticket’s others untouched.

​
Setup

Company rules (optional): pin a memory on a company to give this action rules that apply only to that client. Pinned company memories are added to every run; there is nothing to switch on.

​
Common use cases

For the Description field (Autotask), the Summarize description toggle is on by default. Neo rewrites the body into a brief 2-5 sentence summary. Turn it off to use the field for targeted cleanup only: combine it with custom instructions to strip email-security banners, hyperlinks, or signatures while keeping the original wording and length intact. With the toggle off and no custom instructions, Neo leaves the description unchanged.
Write your due-date rules in the Due Date field’s custom instructions, in plain language. Neo reads them and computes the date. Rules you can write:
  • Lead times per priority: “Priority 1 = due in 1 day, Priority 2 = due in 3 days, Priority 3 = due in 5 days, Priority 4 = due in 14 days”.
  • Business days or business hours: “16 business hours”, “14 business days from the ticket creation date”. Business hours count only the open hours you set in Settings. Business days step over your non-working days and keep the time of day the starting point had. Both read the weekday in your Settings timezone.
  • A date the ticket states: “If the client provides a due date, use it” — or an offset from it: “set the due date to the day before the stated deadline”.
  • A clock time: “next business day at 8am”.
  • From the current due date: “move the due date forward 1 day”.
  • Weekend rule: “if the due date falls on a Saturday or Sunday, move it to the following Monday”.
  • Guards: “only when the status is Waiting Kit”, “do not change the due date for spam”.
Neo never invents the date arithmetic: your rule picks the starting point and the offset, and the date is computed in code from them. The same rule, the same starting point, and the same business hours and timezone in Settings always give the same date. Two starting points move on their own. A rule that counts from the current time re-triages to a later date, because the current time has moved. A deadline the ticket states in words — “by next Friday”, “the 2nd” — is read out of the ticket text against the date of the run, so a re-triage on another day can read it as another date; a deadline written as a calendar date does not move.
Add one sentence to the Due Date custom instructions: “if the due date falls on a Saturday or Sunday, move it to the following Monday”. This covers every due date — your own rules, the default priority lead times, and a stated weekend deadline alike. Neo judges the weekday in your Settings timezone and keeps the time of day. It works as your only due-date instruction too; the earlier Move weekend due dates to the following Monday toggle is retired in favor of the written rule.
Find the real company and contact for tickets logged against a generic “Unknown” company, from email signatures and ticket content.
Set the final service category or billing type from the work actually done, on tickets that are marked resolved.

​
Default priority instructions

The following instructions are used by default when determining ticket priority. You can override them in Ticket Triage action settings.

​
Frequently asked questions

For every field it triages, Neo makes one of three decisions, and the triage note on the ticket reports each one:
  • Match found: Neo picked a value and updated the field. The note shows the predicted value and the reasoning.
  • Verified - left unchanged: Neo examined the field and actively confirmed the existing value matches the ticket. Nothing was written, on purpose: the field was already right.
  • No update applied - left unchanged: Neo could not make a decision for this field (for example, no options were available for the ticket’s company), so it left it untouched.
Every outcome is followed by the reasoning behind it, so a field left unchanged tells you why. The most common reason is one of your own custom instructions on that field. If a field consistently comes back unchanged when you expected an update, the reasoning line will name the rule that caused it.A run where many fields come back “verified” is a healthy sign: it means the ticket arrived mostly correct, not that triage stopped working. If a field has no value at all, Neo never reports it as “verified”: it either picks the best matching option or states that none of the available options fit.
This happens in Autotask when a ticket’s contract belongs to a different company than the ticket. Autotask rejects the whole update until the two match, so Neo replaces or clears the contract to let the rest of its updates land. Two situations lead there.Neo changes the company during triage. Here’s what’s happening behind the scenes:
  1. The ticket already has a contract attached from the original company
  2. Neo identifies the correct company during triage and attempts to update it
  3. Autotask prevents the company change because the existing contract belongs to the old company, not the new one
  4. Neo removes the old contract to allow the company change to proceed
  5. Neo applies the default contract for the newly assigned company
  6. If that company has no default contract, or Autotask rejects it too, Neo leaves the contract empty and applies the rest of its updates
A technician changes the company in Autotask while Neo is working on the ticket. Neo is not touching the company field here: its update fails because the contract still on the ticket belongs to the previous company. Neo re-reads the ticket to get its current company, then applies steps 5 and 6 above.This is an Autotask system limitation, not a Neo configuration issue. When a ticket has a contract attached, Autotask requires that any company change must use a contract associated with the new company.
To avoid the first situation, you can exclude the Company field from your Ticket Triage action configuration. However, this means tickets with incorrect company assignments won’t be automatically corrected. The second situation starts with a company change made in Autotask, so no Ticket Triage setting prevents it.