Parallel Dispatch is rolling out to clients in waves. Newly created dispatch workflows pick it up automatically as the rollout reaches your account; existing workflows continue to work unchanged. No action is required from you to enable it.
What it does
When a Ticket Dispatch action runs with scheduling enabled, Parallel Dispatch quietly:- Reserves the chosen calendar slot the moment the AI picks it, so two simultaneous dispatches can’t both grab the same time on the same technician.
- Asks the AI to pick again if the slot was reserved by a peer dispatch a moment ago, telling it which slot was lost. The conversation continues, so the AI keeps all the context it already had and your routing rules stay in force.
- Hands the slot straight back when the ticket ends up not being booked — somebody claimed it while Neo was deciding, for example. That technician stays available for the next ticket instead of looking busy until the reservation lapses.
- Holds the slot while a ticket waits for approval, because that exact technician and hour are the ones being approved. Another ticket dispatched during the wait is offered a different technician or time, so two approvals can’t be granted for the same slot. The hold lasts ten minutes. If nobody answers the card in that time the slot is released, and if the approval arrives later and the slot has since gone, Neo says so on the ticket and retries before asking again.
- Tells the AI which other dispatches are deciding at the same moment, and where this one sits among them, so a workflow whose rules need to separate simultaneous tickets has something to separate them by.
- Names the technician a concurrent dispatch has just assigned, so a later run does not repeat a choice whose record has not been written yet (see Seeing what a concurrent dispatch just did).
- Re-reads the technician’s live calendar before it settles on the slot (when the workflow has an Assign Ticket action to book the slot), to find a booking made outside Neo while it was deciding that ticket: a technician who booked their own time, or one of your own automations that created a service call. The reservation covers other Neo runs. When the slot is now taken, 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, such as one your instructions allow Neo to double-book, does not count. 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.
Why it matters
No more silent double-bookings
Concurrent dispatches that pick overlapping slots used to fail quietly — both tickets ended up on the same technician’s calendar at the same time. Parallel Dispatch makes that impossible.
Burst-day throughput
A Monday-morning burst of 30 new tickets dispatches in the time it takes to process the slowest single one, not 30 in a row.
Conflicts recover in place
When the AI’s first pick loses the slot, Neo Agent tells it which slot went and asks for another in the same conversation. No context is lost and the ticket is not sent back to the queue.
Zero workflow changes
Existing dispatch workflows benefit automatically once your account is on the new behavior. Your settings, custom instructions, and pool sources continue to work as-is.
Per-technician burst limit
Alongside the calendar-slot safety net, Neo Agent limits how much work a single technician can be handed in one burst: up to three assignments per rolling five minutes, counted per technician across all dispatches running concurrently for your account. This is a fairness guard, not a capacity rule. Without it, a burst of thirty tickets that all look like the same person’s speciality can land entirely on that person, because each dispatch reads the workload snapshot before any of the others have finished writing to it. The window is five minutes because a dispatch takes minutes to decide. A shorter window than one decision cannot see two assignments at once, so the limit never applies. Unlike calendar-slot reservation, this limit applies to every dispatch workflow — including those that only assign a technician without booking a calendar entry.What happens when the limit is reached
Neo asks the AI to pick again, and the retry keeps your routing rules intact:- A different technician your custom instructions still allow. Within the allowed set Neo will take a slightly worse fit rather than pile onto one person.
- If every remaining candidate is outside your rules, Neo assigns the rate-limited technician it proposed last. Neo will not route around a restriction you declared — a named team (“Security Incidents → only the Security Squad”), a named owner (“VIP accounts → only their account manager”), or a queue/tier rule (“Escalation queue → do not downgrade to lower teams”) — just to get past the limit. That technician already satisfied those rules, so Neo lets them through instead of leaving the ticket for a human.
- If the AI keeps proposing rate-limited technicians, after several attempts Neo allows the last one it proposed through rather than failing the dispatch. The limit is a guard, not a hard stop.
The limit is not configurable today, and there’s no toggle in the workflow editor. If your dispatch is tier- or team-restricted and morning bursts regularly concentrate on a small group of technicians, reach out to support — we can look at the pattern with you.
Seeing what a concurrent dispatch just did
Assignment counts come from Neo’s own dispatch record, which a run writes when it finishes. A dispatch spends a few minutes deciding, so a run that started shortly before could read counts that were already out of date. Two changes widen what each run sees:- The counts are read immediately before the AI decides, not at the start of the run. Any dispatch that finished while Neo was gathering context is included.
- A technician’s in-flight assignments are listed by name. A dispatch registers its choice the moment the AI makes it, ahead of the record being written. A run reading the counts after that point sees the entry under that technician, marked as work already given but not yet counted, and treats it as part of their load.
What you see
In Executions, a dispatch that met this situation names it in its reasoning — for example: “Ryan Irwin holds 1 assignment from a concurrent dispatch (#895292) on top of 2 today; Charlie Mathena has 1 and is on shift, so this ticket goes to Charlie.”Tickets that arrive at the same moment are not covered by what a run can read. Dispatches that start within seconds of each other all reach the AI before any of them has decided, so none of them can see the others’ choices. The per-technician burst limit is the guard for that case: it applies after each decision, so it catches the group that reading alone cannot.
When sequential dispatch is still the right choice
Parallel Dispatch replaces most uses of the Process Entities Sequentially workflow setting, but not all of them. Keep it on when:Your dispatch workflow doesn't book calendar slots
Your dispatch workflow doesn't book calendar slots
Sequential mode is still the right answer for dispatch workflows that only assign a technician without adding a scheduled entry. There’s no slot to reserve in that case, so the parallelization safety net doesn’t apply.
You want predictable, one-at-a-time processing for non-dispatch actions
You want predictable, one-at-a-time processing for non-dispatch actions
Sequential mode also covers actions like Find Ticket to Merge With and Trigger Another Workflow, where order matters across tickets. Parallel Dispatch only addresses the calendar-collision case.
Your volume is low and you don't see throughput pressure
Your volume is low and you don't see throughput pressure
For workflows that fire a handful of times per day, sequential mode’s simpler semantics are still a reasonable choice. There’s no harm in leaving it on — Parallel Dispatch will treat sequential workflows as a no-op (the one-at-a-time guarantee already prevents the race).
Migrating an existing sequential dispatch workflow
If you have a dispatch workflow currently running with Process Entities Sequentially enabled, you can safely turn it off once Parallel Dispatch is active on your account:1
Confirm the workflow books calendar slots
Open the workflow’s Ticket Dispatch action settings. Under Scheduling options, verify that calendar booking is enabled. If it isn’t, leave sequential mode on — Parallel Dispatch only protects scheduled dispatches.
2
Turn off Process Entities Sequentially
In the workflow’s general settings, uncheck Process Entities Sequentially.
3
Save and let it run on real traffic
Save the workflow. The next burst of tickets will dispatch in parallel. Calendar collisions remain impossible — the safety net catches what serialization used to prevent.
4
Check Executions after the first busy day
Open the workflow’s executions after a high-volume window. You should see dispatches finishing concurrently rather than queuing one-by-one. If a dispatch’s reasoning mentions falling back to a different technician, that’s Parallel Dispatch’s conflict recovery working as designed.
Expected throughput improvement
The improvement depends on how many tickets the workflow processes in a typical burst:
For workflows that handle scheduled dispatches with frequent multi-ticket bursts (after-hours backlogs, Monday-morning queues, post-outage cleanup), the practical effect is “the queue is gone.”
Frequently asked questions
Do I need to enable anything in the workflow editor?
Do I need to enable anything in the workflow editor?
No. Parallel Dispatch runs underneath the existing Ticket Dispatch action automatically whenever the action has calendar booking enabled. There’s no checkbox to toggle.
What happens if every alternative technician is also busy?
What happens if every alternative technician is also busy?
Neo asks the AI for another pick a limited number of times. If each one also loses its slot, the ticket is left unassigned for manual triage rather than double-booked, and Executions names the slots that were lost. This is rare in practice; it needs several dispatches competing for the same window and the same technicians at once.
What if the replacement slot clashes with something else?
What if the replacement slot clashes with something else?
Neo checks the replacement the same way it checks a first pick — against time off, the technician’s existing appointments, the SLA deadline and your urgent-priority rules. If it finds a problem, Neo hands the slot back so other tickets can use it, tells the AI every problem it found, and asks for another pick. The ticket is only left unassigned once those attempts run out.
Will it change the AI's technician selection?
Will it change the AI's technician selection?
It can, in one direction: the AI now sees what concurrent dispatches have just assigned, so it can move a ticket off a technician who was picked seconds ago by a peer. Your custom instructions, pool source and routing rules are applied exactly as before — a substitution is only ever made from the candidates your rules already allow.
Does it affect Round Robin dispatch?
Does it affect Round Robin dispatch?
Yes — Round Robin dispatch also benefits when scheduling is enabled. The same slot-claiming safety net applies whether the chosen technician came from the AI or from Round Robin rotation.
Can I see how often conflicts happen?
Can I see how often conflicts happen?
Conflict and fallback events are tracked in observability dashboards on the Neo Agent side. If you want a per-workflow report, reach out to support — we can pull the rate for any workflow you’re piloting the migration on.