Skip to main content
Neo recommends a technician using availability, skills, current workload, and previous work for the client.
This action can suggest a technician. Add the Assign Ticket to Technician action afterward to make the assignment in your PSA.
Triggered workflows only. Ticket Dispatch is not available in scheduled workflows.A triggered workflow dispatches one ticket per run, so the technician’s time slot stays reserved for the whole decision, and the calendar entry is written before the next ticket is decided. A scheduled workflow decides every ticket in its batch first and writes them afterwards, so a long batch can book two tickets into the same slot for one technician.To dispatch on a schedule, use two workflows: a scheduled workflow that finds the tickets and hands each one to a triggered dispatcher with the Trigger Another Workflow action.Scheduled workflows that already use Ticket Dispatch keep running. They cannot be saved again until the action is replaced. While one is still running, any run that books two overlapping entries for the same technician says so in its Executions message, naming both tickets and their times.

​
Quick start

1

Choose your trigger

Add to workflows triggered by “Ticket Created” or when tickets move between boards/statuses.
2

Select your technician pool

Choose how Neo gets the pool of technicians: manually select them (Dashboard Pool), pull from the ticket’s company team, or use the ticket’s board team (ConnectWise only).
3

Enable smart features

Turn on calendar checking and workload balancing (both are on by default).
4

Add assignment action

Follow this action with “Assign Ticket to Technician” to actually make the assignment.

​
How it works

Neo considers:
  1. Ticket requirements - Ticket content, priority, and complexity
  2. Technician availability - Calendars, working hours, and current status
  3. Expertise - Similar past tickets and skill areas
  4. Workload - Current ticket assignments and capacity
  5. Client relationships - Technicians who have worked with the client before

​
Setup

​
Technician pool

Choose where Neo gets the technicians to consider for dispatch using the Technician Pool Source dropdown:

Select where Neo should get the pool of technicians from

The three available pool source options

Dashboard Pool lets you manually select a fixed set of technicians directly in the workflow configuration. This is the default option.Use this when you have a specific team or group of technicians you always want Neo to choose from, regardless of the ticket’s company or board.After selecting this option, use the Technician Pool dropdown below it to pick which technicians should be included.

​
Other settings

Smart features: Enable calendar checking, workload balancing, and expertise matching. Custom instructions: Provide specific guidance for your team’s needs and preferences. Scheduling options: Enable automatic calendar booking to reserve time for assigned work. Round Robin mode (optional): Use fair rotation instead of AI optimization for equal distribution. Exclusion rules: Skip a ticket when it matches a condition you set. The rule This ticket already has a scheduled entry (service call) checks the ticket being dispatched, not the technician’s calendar. It stops Neo from re-scheduling a ticket that is already booked. It does not stop two different tickets from being scheduled on the same technician — Neo prevents that same-slot double book on its own, on both the AI and Round Robin paths. Three rules are checked again after Neo picks a technician, because a dispatch decision takes minutes and the ticket can change in that time. The ticket is already assigned skips a ticket a technician claimed while Neo was deciding. The ticket was resolved or closed by someone else skips a ticket somebody resolved or closed in that window, so Neo does not reopen it, book a session on it or email the contact about one. The ticket was merged into another ticket skips a ticket that was merged away in the same window, so nobody is assigned to a ticket that has been folded into another one. Each rule costs one extra read of the ticket in your PSA, and only when you turn it on. The rules are checked in that order and stop at the first one that fires, so a ticket a technician claimed costs one read even with all three on. The merged rule is available on ConnectWise, Autotask and Halo, the PSAs that report a merge on the ticket itself, so the toggle does not appear on ServiceNow or Syncro. The closed rule is available on every PSA. The closed rule compares the ticket against how it looked when Neo selected it, so a workflow that deliberately dispatches resolved or closed tickets is unaffected. It answers whether the ticket is resolved or closed, which is not the same as your filter’s list of statuses: if you exclude a status your PSA does not count as closed — a billing or quoting status, for example — a move to it during the decision is not caught by this rule. The rule also stands down when an earlier action in the same workflow already wrote to the ticket, because Neo then cannot tell its own change from somebody else’s.

​
ConnectWise resource entries

In ConnectWise, a ticket resource is a schedule entry, so what lands on the Schedule tab depends on whether the owner changes:
  • Neo assigns a different technician - ConnectWise adds an open resource entry with no start or end time for the new owner. Any earlier entry stays on the ticket and is no longer marked as the owner’s.
  • Neo assigns the technician who already owns the ticket - ConnectWise does nothing. If that technician’s only entry is marked done, the ticket is left with no open resource entry. This affects tickets that get re-dispatched.
The open-resource setting is off by default and ConnectWise-only. Neo checks the ticket after setting the owner and adds an entry only if that technician has no open one already. It never duplicates the entry ConnectWise just created, and re-dispatching the same ticket does not stack entries. When it adds one, it adds a new entry; a previous entry marked done stays as it is. It is skipped when Neo is already booking a timed entry for that technician, because that already puts them on the ticket as a resource. Assigning more than one technician (Add additional resources to tickets?) has always given the additional technicians an open resource entry; this setting extends the same guarantee to the primary technician.
Custom instructions cannot create resource entries. Those are created by these settings, not by the AI. Wording like “ensure an open resource entry exists” in your instructions has no effect.

​
Teams availability (presence & shifts)

With the Microsoft Teams — Technician Mapping integration connected and technicians mapped to their Microsoft accounts (the integration’s auto-map does this - see the setup guide), the Teams availability toggle makes dispatch aware of each technician’s live Microsoft Teams presence and, optionally, their Teams Shifts rota:
  • Skip technicians who are on a break (on by default) - Technicians who are Away, Offline, or out of office in Teams are not assigned work starting now. Busy, In a call, Presenting, Do not disturb, and Be right back still count as working. The check is time-scoped: a schedule entry booked further in the future is not blocked by someone being on a break right now.
  • Teams holding the shift rota - If your service desk runs its schedule in the Teams Shifts app, list the team(s) here. Neo prefers technicians whose shift covers the proposed assignment time and deprioritizes mapped technicians with no shift in the planning window. Neo also reads each shift’s label (an on-site client name, or an absence marker like Annual Leave) and, from the same team(s), each technician’s time off with its reason. An absence reason (Annual Leave, Sickness Absence, Bank Holiday) excludes them outright even if their PSA calendar looks clear. A reason that records where they are working (London Office, Working from Home, On Call) is read as context.
If Teams cannot be reached or technicians are not mapped, dispatch falls back to its normal PSA-based logic and the run output says why. Round Robin honors the on-break skip too (shifts apply to AI dispatch only). Custom instructions override the defaults - e.g. “Treat Do not disturb as unavailable” or “Ignore Teams presence for P1 tickets”. If presence is not being picked up as expected, see the integration page’s troubleshooting section.

​
Human in the loop (approvals)

The Human in the loop step decides when Neo must ask a person before a dispatch is applied. Requests arrive as Teams cards and on the dashboard’s Approvals page; answering in either place resolves both. Pick one of three modes: Then pick the approvers - who receives the card and can answer. At least one is required. Choose who approves the dispatch: Both proposed-technician settings need Neo to find the technician’s Microsoft Teams user. Neo first matches on the Entra mapping from the Microsoft Teams — Technician Mapping integration. For a technician who has no such mapping, Neo matches their name against the people registered with the Neo bot, and the name must be exactly the same. Neo sends the card to the configured approver list instead - so a ticket is never left stranded - when the technician has no match, when two registered people share the name, or when the technician is mapped to a Microsoft account that never registered with the Neo bot. “Ask only when unsure” questions have no proposed technician, so they always go to the configured approvers. These settings control the Teams card. On the dashboard’s Approvals page, an admin can still answer any pending request for the tenant. While a request is waiting, the ticket is parked: later runs skip it (free) and the execution shows Paused. It stays parked until someone answers, so keep an eye on the Approvals page’s pending count. Answering an “Always” proposal - the card shows the technician, the time slot, and any existing calendar entries Neo will move to make room:
  • Assign to <technician> - Neo applies exactly what the card shows. Nothing is re-decided or re-checked, so what you approved is what happens. The button carries the proposed technician’s name, so you can answer without reading the rest of the card.
  • Offer to someone else - Neo re-decides and offers the ticket to the next available technician. The person Neo had proposed is taken out of the pool, and the next card names everyone who has already declined. A text box is offered here and is optional: fill it in (e.g. “afternoon only, or try Alex Carter”) and Neo follows your note while still excluding the decliners; leave it empty and Neo simply picks the next technician. Neo keeps advancing on each further decline until someone approves. When every technician in the pool has declined, the ticket parks once with a message that names who declined and says the pool is exhausted - assign it by hand or add technicians to the pool. An exclusion lasts only while the ticket is unchanged. If the ticket is then updated in your PSA, that is a new situation: Neo decides again from the full pool, so someone who declined earlier can be proposed once more.
  • Don’t auto-assign - Neo stops dispatching this ticket and leaves it for manual assignment. Use it when the ticket should not be routed at all - you are taking it yourself, or it needs a decision before anyone works it. Unlike the other two answers, this one does not expire when the ticket changes. A decline says “not right now”, so a PSA update is fair reason to ask again; this says “not at all”, and a new note on the ticket is no reason to overrule it. To hand the ticket back to Neo, assign it in your PSA.
The exclusion applies to the technician Neo proposed, not to whoever pressed the button. With Proposed technician plus configured approvers, a lead who declines on a technician’s behalf is still asked about the next proposal for that same ticket.
The dashboard’s Approvals page offers the same three answers on a dispatch proposal, so an admin working the inbox is not limited to approve-or-stop. Answering many requests at once still offers only approve and reject, and a bulk reject means Don’t auto-assign - passing a ticket to the next technician is a decision about that one ticket.
Answering a “When unsure” question - the card states the dilemma and offers 2-4 concrete options:
  • Pick an option and Submit - Neo dispatches per that option, exactly as written.
  • ✏️ Tell Neo what to do - Type your own answer (it overrides any selected option); Neo dispatches following it. Your instruction wins even over the workflow’s standing rules - including working hours - so be as specific as you like.
  • Submit with nothing selected - Neo resolves the dilemma with its best judgment.
  • Decline - The ticket is left as is until it changes.
Credits: a dispatch that asks costs the same one credit as a dispatch that doesn’t. The run that decides (or asks the question) bills one credit per ticket; waiting is free, and applying your answer - including the re-decision after a note - is free. See Billing.
“When unsure” only asks when no lawful decision exists. If your instructions leave Neo an escape - e.g. “assign backup tickets to Casey” plus “don’t schedule Casey on weekends” on a Saturday - Neo will book Casey for Monday rather than ask. If tickets that feel like dilemmas aren’t producing questions, tighten the time bounds in your instructions (“…scheduled the same day the ticket arrives”).

​
Writing effective custom instructions

Use clear, specific custom instructions:
Key principles for good custom instructions:
  • Always use full names (first and last) for technicians
  • Write dates in full format (e.g., “2nd October 2025” instead of “02/10/25”)
  • Be specific about clients, ticket types, or conditions that trigger the rule
  • Identify exact technicians, skill tags, or team names for routing

​
Examples: Good vs. Bad

​
What you get

Running this action on high-volume workflows? See Parallel Dispatch - Neo Agent automatically prevents double-bookings when multiple dispatches run at the same time, so you can drop the Process Entities Sequentially safety knob and recover full burst throughput.

​
Best practices

You can control the name of the booked entry through your custom instructions - for example, “Name every schedule entry ‘NEO - [client] - [short summary]’”. If you don’t specify a naming convention, the entry is named after the ticket title (the default).HaloPSA appointment types: Neo can set the appointment type on the entries it books (e.g. Firm vs Tentative, Remote vs Onsite) from your own Halo appointment types. Two ways to control it, and they work together:
  • Default appointment type - A dropdown in the calendar settings, populated from your Halo appointment types. Neo puts this type on every entry it books unless a per-ticket rule overrides it.
  • Per-ticket, from custom instructions - Tell Neo which type to use per situation, for example “Use ‘Firm - Remote’ for strictly scheduled remote tickets and ‘Tentative - Remote’ for work that just needs to happen sometime today; use the Onsite equivalents for on-site visits.”
Neo matches the name to your tenant’s appointment types. If a ticket matches no rule and no default is set, the entry keeps Halo’s own default type.HaloPSA appointment body: Tell Neo what the appointment body should contain and it writes that text into the appointment’s note - for example “Put the caller’s name, phone number and a one-line summary in the appointment body.” If you sync your Halo appointments to Outlook or Teams, this is what technicians see in the calendar event. Say nothing about the body and the appointment is created without one, as before.
To prevent Neo from re-processing tickets that already have an owner, add a Filter Ticket condition to your Dispatch workflow:
Add a filter condition: owner.id is null
This ensures Neo will never re-process tickets that already have an assigned technician, even if the workflow triggers late.

​
Frequently asked questions

Neo calculates workload based on settings you configure under “Consider technician Workload” in dispatch settings:
  • Time period: Choose how many days back Neo should look (e.g., last 7 days)
  • Activity criteria: Select what counts as activity:
    • Ticket last update (any change to the ticket)
    • Last ticket time entry (logged work time)
    • Last ticket note (comments or updates)
Neo counts all open tickets (regardless of status, board, etc.) that had the selected activity within your chosen time period. If you want to filter by specific status, board, or any other field, you can customize this in custom instructions. For example, “When calculating workload, exclude tickets on the ‘Waiting for Customer’ board/status.”
  • Exclude child (bundled) tickets: When on, Neo does not count a technician’s child tickets toward their workload. Turn this on when related tickets are bundled under a parent ticket, so a technician is not counted once per bundled ticket. Available for ConnectWise, Halo, ServiceNow, and Syncro (Autotask has no parent-ticket concept). Each workload row now also shows its parent ticket when it has one, so you can reference the relationship in custom instructions too.
Start with a 7-day lookback period using “Ticket last update”.
Turn on “Should Neo balance assignments using this workflow’s history?” under “Consider technician Workload”. Neo then counts how many tickets this workflow has already given each technician and prefers the one with the fewest.What the counts cover. Only the tickets this workflow dispatched. A ticket a dispatcher assigned by hand in your PSA, or one another workflow assigned, is not counted. If you want your rule to mean every assignment, say so in your custom instructions and expect Neo to work from its own figures.Assignment history window. Set it to 0 for today only, counted from midnight in your timezone. Set any higher number and Neo gets two counts to compare instead of one: today’s, and the wider window. A rule with two tiers needs both, so a window of 7 is what makes an instruction like this work:
With the window at 0, the second line has no data behind it and Neo cannot apply it.Where it ranks. Assignment history is its own step, ahead of workload and expertise. Neo names the technician with the fewest assignments and compares each candidate against that figure. If your custom instructions state a different order, Neo follows yours instead — for example “current workload is only a balancing factor and should not outweigh assignment history”.Availability still comes first. A technician on zero assignments who is on lunch, off shift, or inside an appointment is not selected on count alone.
Neo automatically reads technician working hours from your PSA system. The setup process depends on which PSA you’re using:
Setup in ConnectWise Manage:
  1. Create different calendar templates for each work schedule (e.g., “7AM-4PM Schedule”, “8:30AM-5PM Schedule”, “9AM-6PM Schedule”)
  2. Assign the appropriate calendar to each technician in their member profile
  3. Neo will automatically use these calendars when checking availability
For your example schedules:
  • Create a “7AM-4PM” calendar and assign it to your 2 help desk technicians
  • Create an “8:30AM-5PM” calendar for your 2 technicians with that schedule
  • Create a “9AM-6PM” calendar for your 1 technician with that schedule
During a burst, Neo limits how many tickets one technician can be handed in a short window (three per rolling five minutes). When that limit is reached, Neo re-picks a different technician - one your custom instructions still allow - for the tickets over the cap.This burst limit is a soft cap, not a hard failure: if no other technician fits under it, Neo still makes the assignment rather than leaving the ticket unassigned, and Executions records that it fell back. A ticket is left unassigned only when your own custom routing rules rule out every candidate (for example “Escalation Team → do NOT downgrade to lower teams” or “Security Incidents → only the Security Squad”), so Neo won’t route around a rule you declared. Executions then shows “No technician recommendation found” along with the restriction that blocked the substitution.See Parallel Dispatch for the full behavior.
You can configure Neo to suggest multiple technicians for a single ticket using the “Number of technicians to suggest” setting.To set up multiple technician suggestions:
  1. Open the Configure Message Settings section in your Ticket Dispatch action
  2. Find the Number of technicians to suggest field
  3. Increase this number to however many technicians you want suggested (e.g., 10)

Configure how many technicians Neo should suggest for each ticket

How multiple technicians are assigned:When you use the “Assign Ticket to Technician” action after getting multiple suggestions, the PSA will assign them differently based on your system:
  • First technician: Assigned as the ticket Owner (primary resource)
  • Additional technicians: Added as Resources (secondary resources)
The Halo field uses agent objects with id and name values. Neo merges new agents with the agents already on the ticket, so a dispatch does not remove a technician added by hand.Halo appointments and additional technicians: a Halo appointment belongs to one agent, so Neo books it for the first technician. When the dispatch also picks additional technicians, Neo puts their email addresses in the appointment’s Other Attendees field, taken from each agent’s email in Halo. You do not need a custom instruction for this — it happens whenever a dispatch produces both a booking and an additional technician. An additional technician with no email address on their Halo agent record is left off the attendee list; the Additional Agents field on the ticket still names them.
Other Attendees records who shares the appointment. Whether Halo then emails those people or copies the appointment onto their own calendar depends on your Halo notification settings, not on Neo.