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. Update Ticket Fields writes the same suggestion, so either one assigns the ticket.If you leave them both out on purpose, the workflow still works as a suggestion-only dispatcher. Its dispatch result in the Executions message then starts with “No change was written to the PSA”, naming the missing action, so nobody reads the suggestion as a completed assignment. The ticket note says the same, when an Add Ticket Note action follows Ticket Dispatch to post it.
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:
Technician Pool Settings showing the pool source dropdown

Select where Neo should get the pool of technicians from

Technician Pool Source dropdown expanded showing Dashboard Pool, Company Team, and Board Team options

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 Choose technicians and groups, use the Technicians and groups picker below it to add single technicians, technician groups, or both. The list under the picker shows every technician in the pool. A group’s current members join the pool on every run, and dispatch reads the group’s instructions once. A technician limited to their preferred companies leaves the pool for a ticket from any other company, whatever the pool source.

​
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. Public holidays: When you set a holiday source, Neo reads each technician’s holiday list and blocks a holiday by default, the same way it treats time off. A proposed slot that lands on a holiday is rejected, whether or not the technician already has entries on the day: the AI path is sent back for a different day, and Round Robin moves on to the next technician. An urgent ticket does not lift the block. Your custom instructions do: say that your technicians work public holidays, or name the dates or the kinds of ticket they cover, and Neo books the slot. On Autotask with the holiday source set to PSA Holidays, a technician whose Autotask calendar gives them holiday hours — they work holidays on a reduced schedule — is not blocked. US Holidays gives every technician the same list and reads no calendar, so that exception does not apply there; use a custom instruction if your team works some of those days. With the holiday source set to None, Neo does not read holidays and does not apply this block. Today’s earlier entries: By default Neo reads each calendar from the current time onward, so an entry that ended earlier today is not in it. Turn on Should Neo see today’s earlier calendar entries? when your instructions judge a technician’s whole day, such as a cap on booked hours or “more than five hours of visits means out all day”. Neo then reads the calendar from the start of the day and marks each finished entry as ended. A finished entry counts toward the day’s total and never blocks a new slot. With Microsoft Teams Shifts on, Neo also reads the shifts that ended earlier today and marks them as ended, so an instruction such as “unavailable once their last shift of the day has ended” can apply. Neo still skips entries marked complete in Autotask and done in ConnectWise. Round Robin does not use this setting. Round Robin mode (optional): Use fair rotation instead of AI optimization for equal distribution. When Round Robin also books calendar time, it reads each technician’s calendar across the same days in the future window the AI path uses, and honors the same holiday source. So instructions that allow a booking on the next business day are checked against that day’s real calendar. Round Robin still asks first whether the technician works today: a technician whose weekly hours are marked not working today is skipped, and no day inside the window is offered for them. Round Robin uses your custom instructions only to judge availability (who works when, holiday cover included). So when it is on, these stop applying: other instructions about which tickets to assign or skip, or to whom (for example alerts, a ticket type, or “give a night ticket to whoever starts tomorrow”), and Human in the Loop set to ask only when unsure (it asks no new question; asking every time still works). When nobody is available, Neo makes no assignment. Neo Support lists these effects before it turns Round Robin on for you. 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. That cover is two layers: a reservation between simultaneous Neo runs, and a live re-read of the technician’s calendar before Neo settles on the slot. The re-read runs only when the workflow has an Assign Ticket action that books the slot. The second layer looks for a booking made outside Neo, by a technician or by one of your own automations, while Neo was deciding that ticket. When it finds one, Neo picks another slot or technician, and Round Robin moves to the next technician. An entry Neo already saw in the calendar when it chose the slot does not count, so an overlap your instructions allow still goes ahead. The re-read looks at the scheduled work your PSA books against the technician, which on Autotask means service calls. On ConnectWise, an entry that spans several days counts only for the hours it books on each day, the same as in the calendar Neo reads — unless ConnectWise returns the series with no per-day detail rows, or a full page that may be truncated, when Neo treats the whole span as overlapping rather than clearing it. Four 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. The ticket was moved to a different status, board/queue or team skips a ticket somebody re-routed in that window — the case where a technician takes a ticket back out of your dispatch queue by hand, without closing or claiming it. Each rule costs an 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 four 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 and re-routed rules are 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. On a triggered workflow, Neo selects the ticket when it checks your filter, so a close seconds after that check counts as a change during the decision — for example, from an automation that closes alert tickets soon after they are created. The rule also covers the wait for a human approval: a question or proposal records whether the ticket was open when Neo selected it, and the run that continues it after your answer compares against that record rather than against the ticket as it was after the wait. The re-routed rule does not cover the approval wait, because an answer often moves the ticket itself. The closed rule 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 caught by the re-routed rule below rather than this one. 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. The re-routed rule is the general form of that, and it is the one to turn on if your technicians take tickets out of the dispatch queue by changing the status or moving the ticket to another team. It compares three things against how they looked when Neo selected the ticket: the status, the board or queue, and — on ConnectWise and Halo, where the team is a field of its own — the team. Any of the three moving is a skip. It compares against the snapshot rather than against a list of statuses, so it catches a move to any status you did not expect, including one your PSA does not count as closed, and it leaves a ticket that has not moved alone whatever state it is in. A rename in your PSA is not a re-route. Like the closed rule, it stands down when an earlier action in the same workflow already wrote to the ticket. Because it is the broadest of the four, it is checked last: a ticket that was also claimed, closed or merged is reported under the rule that names the change precisely.

​
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 who receives the card and can answer:
  • Approvers - people. Each one gets the card in their own Teams chat. The list shows the people in your connected directory who use the Neo Agent app in Teams. Someone who is missing opens the Neo Agent app in Teams and sends it one message, then appears in the list.
  • Teams channels & chats - Neo posts one card in each, and anyone in the channel or chat can answer. Use this when a team of dispatchers shares the work. See Approvals in a Teams channel or chat.
Pick at least one person or channel. 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. When neither finds a Teams user and the Neo AI Agent in Slack is connected, Neo sends the card to the technician’s Slack member, linked by email. Neo reads the stored Slack links of your technicians. They refresh after each technician sync and when you click Match again, so a new technician has no Slack target until then. Neo sends the card to the configured approvers, channels and chats instead - so a ticket is never left stranded - when the technician has no match in Teams or Slack, 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 or Slack 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, with no new decision and no new availability check, so what you approved is what happens. The exclusion rules still apply, checked against the ticket as it is when Neo resumes after your answer. 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 assign - Neo stops dispatching this ticket and leaves it for manual assignment. An owner already on the ticket stays. 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 assign - passing a ticket to the next technician is a decision about that one ticket.
Answering a “When unsure” question - the card asks which technician should take the ticket and offers 2-4 assignments:
  • Pick a technician and Submit answer - Neo decides again with your pick as the answer, and assigns that technician.
  • ✏️ Guide Neo to make another assignment decision - Type your own instruction (it overrides any selected option); Neo decides again following it. Your instruction wins even over the workflow’s standing rules - including working hours - so be as specific as you like. To book over an existing calendar entry when your rules forbid double-booking, say so in words (for example “Double book is approved”); a time alone does not approve it.
  • Submit with nothing selected - Neo decides with its best judgment.
  • Don’t assign - Neo stops dispatching this ticket and leaves it for manual assignment. An owner already on the ticket stays. Like the same answer on an “Always” proposal, it does not expire when the ticket changes, so Neo will not come back with the question on the next PSA update. Assign the ticket in your PSA to hand it back to Neo.
After you answer, Neo decides one more time, and that decision does not ask again: it assigns a technician, or leaves the ticket unassigned if your answer says so. A later run on the same ticket is a new decision and can ask a new question. If a ticket should not be dispatched at all - it is spam, closed, merged, or you are handling it yourself - press Don’t assign.
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.
Tickets nobody should take. If your custom instructions say to leave a kind of ticket unassigned (for example “Spam, recruitment emails and backup reports that show success: do not assign a technician”), “When unsure” follows them and asks nothing. Neo quotes the instruction it followed on the run page. The rule must be in your instructions: when Neo only finds that nobody is free or eligible, it still asks. Write the rule as a sentence that names the kind of ticket: Neo quotes at least 15 characters of it, so a rule as short as “Spam: no tech” still gets a question.
A technician’s own rule and a rule for everyone. With AI dispatch and Include AI profile on, a technician’s own custom instructions (on their profile) decide for that technician when they differ from a dispatch instruction that covers every technician, such as “pick the lowest workload”. Neo follows the technician’s rule for them, the general rule for everyone else, and asks nothing. Two instructions that both name the same technician can still be a real conflict, and “When unsure” asks about those.
“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

​
Reserving time on a technician’s day

Some rules reserve space on the calendar instead of ruling a technician out - a lunch gap that can fall anywhere in a window, travel time between onsite visits, a morning kept clear, a cap on booked hours. Neo treats these as hard constraints and judges the day as the booking would leave it, using the arithmetic your rule states: the gap either side of a slot for a spacing rule, the day’s booked total for a cap, and whether a qualifying stretch survives for a rule that protects free time somewhere inside a window. Name the window, the amount to keep free, and who the rule covers:
  • “For Dana Ruiz and Sam Okafor, keep at least one continuous unbooked 30-minute gap between 11:30 and 14:30 on every working day.”
  • “Leave an hour between onsite visits for travel.”
  • “Cap each technician at 6 booked hours a day.”
A rule that names technicians applies to those technicians only. When no slot on a day can satisfy the rule, Neo books a later day or another technician rather than taking the reserved time.

​
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), up to 90. Set it to 0 to count today only, from midnight in your timezone
  • 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)
    • All open tickets (no time window) — open tickets count however long ago they were touched
Neo lists each technician’s workload as one row per ticket: the ticket number, status, board or queue, the hours when your criteria uses hours, and the title, followed by the totals. Neo counts open tickets that had the selected activity within your chosen time period, whatever their board. Two kinds are never counted: tickets your PSA reports as closed, and tickets whose status name contains Complete (for example Completed - Portal or Work Complete~), which many boards leave open for a survey or billing step. Every other status counts. 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.”Workload measures who is busy now, so the time period is capped at 90 days: a ticket nobody has touched for longer is not current work, and counting it means the technician with the most dormant tickets looks the busiest. Pick All open tickets when you want open tickets counted regardless of age. Neo reads no notes and no time entries for the count, and the ticket search carries no date, so it returns your whole open backlog instead of a recent slice. Neo’s ticket search reads a fixed number of pages, so a very large open backlog can reach that limit and the tickets past it are not counted. The limit applies to every workload setting, and removing the time window is what makes a backlog most likely to reach it.
  • 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 shows its parent ticket when it has one, so you can reference the relationship in custom instructions too.
  • Also show work already done in this window: Neo also reads the hours each technician logged and how many of their assigned tickets were closed in the same time period, with today’s figures on their own, so a technician who closes tickets fast does not look free. Neo looks back at most 7 days, and today only with All open tickets. Available for Autotask, ConnectWise and Halo. Say how to weigh the figures in custom instructions, for example: “Prefer the technician with the fewest hours logged today.”
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. To set them in Neo instead, with breaks, night shifts and time zones, put technicians on a schedule on the Technicians → Schedules tab: a schedule replaces the PSA hours for that technician. See Technician working hours.To keep the hours in your PSA, the setup 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. That holds both when Neo keeps re-picking the same rate-limited technician and when it finds no substitute your rules allow — either way the technician the cap blocked gets the ticket, because they already satisfied your rules.Neo won’t route around a rule you declared (for example “Escalation Team → do NOT downgrade to lower teams” or “Security Incidents → only the Security Squad”) to get past the limit. A ticket is left unassigned when no technician is admissible in the first place — everyone is off, out of hours, or excluded by your rules. Executions then shows “No technician recommendation found” along with the reason.With Human in the loop set to Ask only when unsure, Neo asks an approver instead, and the ticket waits for the answer. It asks when it found nobody to assign, and when every technician it re-picked is at the limit. When your rules allow only the rate-limited technician, Neo assigns them and asks nothing. The one exception is a ticket your custom instructions say to leave unassigned: Neo leaves it unassigned with no question, and Executions shows “Left unassigned by your custom instructions” with the instruction it followed.See Parallel Dispatch for the full behavior.
For a ticket that is not urgent, the SLA deadline is a soft limit. Neo first looks for a slot that ends before the deadline. When the technician has no free time before it, Neo books the first free slot after the deadline rather than leaving the ticket unassigned, and Executions records that it fell back. With Human in the loop set to Ask only when unsure, Neo asks an approver about that late slot instead.An urgent ticket (one whose priority is in Which priorities can jump the queue?) is never booked after its SLA deadline; see the next question.
An urgent ticket must start within 24 hours and finish inside its SLA deadline, whichever comes first. When the ticket arrives outside working hours, the earliest free slot can be the next business morning, which is past that limit. No technician can take it, so Neo leaves it unassigned.Neo finishes the run and records why the ticket was not assigned, naming the ticket, the technician it tried, the slot it found and the limit that rejected it. That reason is in the run’s entry in Executions. To have it sent to you as well, add a Notify internal team action after Ticket Dispatch.To change this:
  • Narrow Which priorities can jump the queue? so fewer tickets carry the 24-hour limit.
  • Set Human in the loop to When unsure, which asks a technician to decide instead of leaving the ticket unassigned.
  • Add out-of-hours cover to the technician schedules Neo reads.
An urgent ticket is one whose priority is in Which priorities can jump the queue?.
  1. Your custom instructions decide first. A rule such as “Never assign a technician who is in an appointment” applies to urgent tickets too. To treat urgent tickets differently, say so in the instruction, for example “High and Critical tickets may go to a technician whose appointment title contains Office Hours.”
  2. Time off, sick days and vacations always rule a technician out. So does a public holiday, unless your custom instructions allow holiday work.
  3. Without guidance in your custom instructions, Neo picks a technician who is free soon: free now, or in an entry that ends within 60 minutes. When the ticket’s SLA respond-by time is less than 60 minutes away, the entry must end before that time. When Neo books a time, the booking starts when that entry ends. A technician whose entries keep them busy for longer than that counts as away.
  4. When every technician on shift is away, Neo picks the one who is free first today, and can double-book over a Tentative entry to do so. It does not hold an urgent ticket for the next business day while a technician is on shift.
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)
When your custom instructions allow extra technicians only in some cases (for example, “only assign secondary resources if explicitly requested”), Neo follows the instruction. This number is not a request for extra technicians.
Number of technicians to suggest setting

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.