Skip to main content

Ticket Dispatch (Suggest Technician)

The "Ticket Dispatch (Suggest Technician)" action intelligently recommends the most suitable technician(s) to handle a given PSA ticket or a list of tickets. It analyzes various factors including technician availability, workload, expertise, and more, to provide an optimal suggestion.

This action suggests a technician; to perform the actual assignment in your PSA, you should use the "Assign Ticket to Technician" action later in your workflow.

Why is it useful?

This action helps streamline your ticket assignment process by:

  • Saving Time: Automating the initial decision-making for technician assignment.
  • Improving Efficiency: Ensuring tickets are routed to technicians who are available and capable.
  • Balancing Workload: Helping distribute tickets more evenly based on current assignments and configured workload criteria.
  • Matching Expertise: Suggesting technicians whose skills and experience align with the ticket's requirements.
Tip for Sequential Processing

When many tickets arrive simultaneously (e.g., during an outage or from an RMM alert storm), processing them sequentially ensures the dispatch logic has the most up-to-date information about technician workload from previous assignments in the same batch. This prevents scenarios where multiple tickets might be assigned to the same technician simply because the system hasn't yet registered the first few assignments.

To enable this, check the Process Entities Sequentially option in your workflow's trigger configuration settings.

What It Does​

The "Ticket Dispatch (Suggest Technician)" action performs the following key functions:

  • Analyzes one or more PSA tickets that need assignment.
  • Evaluates a provided pool of technicians against various configurable criteria.
  • Considers technician availability by checking their calendars for existing appointments, out-of-office bookings, working hours, holidays, and weekends, if consider_technician_calendar is enabled.
  • Assesses technician workload based on metrics like the number of currently assigned tickets or estimated hours, according to settings in dispatch_workload_settings, if consider_technician_workload is enabled.
  • Leverages technician profiles (if consider_technician_profile is enabled) to match expertise with the ticket's needs.
  • Optionally checks for company continuity by seeing if technicians have recently worked on tickets for the same company, or are scheduled to be on-site, if consider_company_continuity and related sub-settings are enabled.
  • Can be guided by special conditions defined in dispatch_special_conditions to avoid dispatching (e.g., if the ticket was created by its owner).
  • If configured via dispatch_calendar_settings (specifically add_schedule_entry and scheduled_entry_settings), suggests a schedule entry time slot for the recommended technician.
  • If schedule creation is enabled and allow_update_existing_tentative_scheduled_entries (within scheduled_entry_settings) is active, it can also identify and suggest modifications to existing 'Tentative' schedule entries to make space.
  • Outputs the suggested technician(s) and other relevant information for use in subsequent workflow actions.

How It Works​

The action follows a sophisticated process to determine the best technician(s):

1. Input Data​

The action takes a list of PSA tickets and a pool of technicians as primary input. Its decision-making is guided by several configurable settings, including top-level flags (like consider_technician_calendar, consider_technician_workload, consider_technician_profile, consider_company_continuity, consider_special_conditions, configure_message_settings) and their corresponding detailed settings objects (e.g., dispatch_calendar_settings, dispatch_workload_settings, dispatch_company_continuity_settings, dispatch_special_conditions, dispatch_message_settings). If more than 30 tickets are provided in a single execution, the action will process only the oldest 30 and log a message.

2. Pre-Dispatch Checks​

Before attempting to find a technician, Neo checks several conditions based on your settings in dispatch_special_conditions (if consider_special_conditions is enabled):

  • Ticket Ownership: It may skip dispatch if the ticket was recently created by its current owner (do_not_dispatch_if_owner_is_the_creator is true) or if the ticket was created with an owner already assigned (do_not_dispatch_if_ticket_created_with_owner is true).
  • Existing Schedule Entries: It may skip dispatch if the ticket already has a scheduled entry (do_not_dispatch_if_scheduled_entry_exists is true).

3. Context Gathering & Technician Evaluation​

For each technician in the provided pool, Neo gathers comprehensive context:

  • Availability: If consider_technician_calendar is enabled, Neo checks the technician's calendar for their working hours, existing appointments, out-of-office (OOO) periods, holidays, and weekends. The look-ahead period for scheduling is determined by dispatch_calendar_settings.scheduled_entry_settings.days_in_the_future (if scheduling is enabled).
  • Expertise: If consider_technician_profile is enabled, Neo retrieves and considers the technician's skill profile. If a profile is missing, Neo may initiate a background sync for that technician's profile and will note this in its output.
  • Workload: If consider_technician_workload is enabled, Neo analyzes the technician's current workload based on the criteria defined in dispatch_workload_settings (e.g., number of open tickets, estimated hours). This includes tickets actively worked on recently.
  • Company Continuity: If consider_company_continuity is enabled, Neo looks at whether the technician has recently handled other tickets for the same company. If dispatch_company_continuity_settings.consider_technician_on_site is also enabled, Neo checks if the technician is currently or scheduled to be at the ticket's company location.
  • SLA Considerations (ConnectWise Only): If consider_technician_calendar and dispatch_calendar_settings.add_schedule_entry are enabled, and dispatch_calendar_settings.scheduled_entry_settings.sla_events are specified, Neo considers these SLA deadlines when suggesting a schedule.

4. AI-Powered Recommendation​

Neo compiles all the gathered information—ticket details, technician contexts (availability, expertise, workload, company continuity, etc.), SLA information (if applicable), and any custom_instructions you provide—into a comprehensive overview. This overview is then processed by an AI model to:

  • Recommend the most suitable technician(s) from the pool, up to the number specified in dispatch_message_settings.number_of_technicians_to_suggest (if configure_message_settings is enabled).
  • If consider_technician_calendar is enabled and dispatch_calendar_settings.add_schedule_entry is true, suggest an appropriate time slot for the primary recommended technician, chosen from dispatch_calendar_settings.scheduled_entry_settings.allowed_time_slots. Furthermore, if dispatch_calendar_settings.scheduled_entry_settings.allow_update_existing_tentative_scheduled_entries is also enabled, Neo will analyze the technician's calendar for 'Tentative' entries that might conflict with the new 'Firm' ticket. If such conflicts are found, Neo may propose adjustments to these 'Tentative' entries (e.g., moving them to a later time) to ensure the new ticket can be scheduled appropriately.

5. Output Structure​

The action outputs the DispatchTicketOutput, which includes:

  • The suggested technician(s) and the reasoning behind the suggestion.
  • Messages suitable for internal MSP use and for the Neo Dashboard Event History.
  • Field updates that can be applied to the ticket (e.g., assigning the suggested technician).
  • Schedule entries that can be created in the technician's calendar if scheduling was requested.
  • Tentative Schedule entries that can be moved in the technician's calendar to open up space for the new ticket.

Custom instructions provided in the custom_instructions field heavily influence the AI's decision-making process, allowing you to tailor the dispatch logic to your specific needs.

Configuration Fields​

When you add the "Ticket Dispatch (Suggest Technician)" action to a workflow, you'll configure the following:

default_data​

The list of PSA tickets that require technician assignment.

technicians​

A list of technicians that Neo should consider for dispatching the ticket(s). You select these from your available PSA resources.

use_custom_instructions​

Enable this to provide specific instructions to the AI for selecting a technician. (default: False)

custom_instructions​

(Optional) Text-based instructions that guide the AI's decision-making process. This is where you can specify unique dispatch preferences or criteria not covered by other settings. This field is available if use_custom_instructions is true.

consider_technician_calendar​

If enabled, Neo checks the technician's calendar for availability, considering working hours, existing appointments, and OOO entries. (default: True)

dispatch_calendar_settings​

(This group of settings is available if consider_technician_calendar is True) Configures calendar-related dispatch logic.

  • consider_us_holidays: If True, Neo will NOT assign the ticket on US holidays. Tip: If you want to consider any other holidays, you can define them in Custom Instructions. (default: False)
  • add_schedule_entry: If enabled, Neo will attempt to find and suggest a schedule entry for the recommended technician in their calendar. (default: False)
  • scheduled_entry_settings: (Available if add_schedule_entry is True) Configures how Neo creates schedule entries:
    • allowed_time_slots: A set of predefined durations (e.g., "15 minutes", "30 minutes") that Neo can select for the schedule entry, based on its assessment of the ticket. (default: empty set)
    • days_in_the_future: How many days ahead Neo should look to schedule the entry. '0' means Neo will only schedule for the current day. (default: 0)
    • sla_events: [ConnectWise Only] A set of SLA event types (e.g., "Respond", "Plan", "Resolve") that Neo should consider. Neo will try to schedule the entry before these SLA deadlines. (default: empty set)
    • urgent_priorities: A list of PSA priority names that are considered urgent. When assigning a ticket with one of these priorities, Neo may schedule it for a technician even if it means overlapping with lower-priority existing work. (default: empty set)
    • scheduled_entry_status: The status to apply to the newly created schedule entry (e.g., "Firm", "Tentative"). (default: Firm)
    • scheduled_entry_location: (Optional) The location to set for the newly created schedule entry (e.g., "On-Site", "Remote", or a specific service location from your PSA). (default: None)
    • allow_update_existing_tentative_scheduled_entries: If enabled, Neo can adjust existing 'Tentative' schedule entries in the technician's calendar to make space for the new ticket. This is particularly useful when the new ticket requires a 'Firm' schedule entry and might conflict with less critical, tentative bookings. (default: False)

consider_technician_workload​

If enabled, Neo assesses the technician's current workload based on the criteria in dispatch_workload_settings (see below). (default: True)

dispatch_workload_settings​

(This group of settings is available if consider_technician_workload is True) Configures how Neo measures and uses technician workload:

  • criteria: The primary metric for workload calculation (e.g., "Number of tickets assigned", "Tickets estimated hours", "Tickets remaining hours (Estimated Hours - Hours Worked)"). (default: Number of tickets assigned)
  • include_tickets_worked_in_last_n_days: Neo considers tickets actively worked on within this number of past days for workload analysis. Activity is determined by criteria_for_considering_tickets. (default: 2)
  • workload_difference_threshold: If criteria is "Number of tickets assigned", and the difference in ticket count between the least busy and second-least busy technician exceeds this value, the ticket is automatically suggested for the least busy one. (default: 3)
  • criteria_for_considering_tickets: Defines what constitutes "worked on" for the include_tickets_worked_in_last_n_days setting (e.g., "Ticket last update", "Last ticket time entry", "Last ticket note or time entry"). (default: Ticket last update)

consider_company_continuity​

If enabled, Neo gives preference to technicians who have recently worked on tickets for the same company, or considers if they are on-site. (default: False)

dispatch_company_continuity_settings​

(This group of settings is available if consider_company_continuity is True) Configures settings related to company and technician continuity.

  • consider_technician_on_site: If enabled, Neo prioritizes technicians who are currently at, or scheduled to be at, the ticket's company location today. (default: False)

consider_technician_profile​

If enabled, Neo uses technician skill profiles to match expertise with the ticket's requirements. (default: True)

consider_special_conditions​

If enabled, Neo will check pre-defined conditions to determine if the ticket should be dispatched. (default: False)

dispatch_special_conditions​

(This group of settings is available if consider_special_conditions is True) Configures special conditions under which dispatch might be altered or skipped.

  • do_not_dispatch_if_owner_is_the_creator: If enabled, Neo will not suggest a new technician if the ticket was recently created by its current owner. (default: False)
  • do_not_dispatch_if_ticket_created_with_owner: If enabled, Neo will not suggest a new technician if the ticket was initially created with an owner already assigned. (default: False)
  • do_not_dispatch_if_scheduled_entry_exists: If enabled, Neo will not suggest a new technician if the ticket already has a scheduled entry (e.g., an appointment). (default: False)

configure_message_settings​

If enabled, allows configuration of output message content and technician suggestion count. (default: False)

dispatch_message_settings​

(This group of settings is available if configure_message_settings is True) Configures aspects of the output messages and suggestions.

  • include_ticket_summary_in_message: If enabled, the output messages from this action will include a summary of the ticket's conversation. (default: False)
  • include_reasoning_in_message: If enabled, Neo will include the reasoning (justification) in the output messages. (default: True)
  • number_of_technicians_to_suggest: The maximum number of technicians Neo should suggest. If subsequent actions (like "Assign Ticket to Technician") use this output, typically only the first technician in the list is considered. (default: 1)

Output Fields​

This action makes the following information available to subsequent actions in the workflow:

default_messages_for_msp​

A list of messages detailing the dispatch suggestion and reasoning, suitable for internal notes or notifications. Each message object in the list corresponds to a ticket processed.

default_messages_for_dashboard​

A list of strings, where each string is a summary of the dispatch action for a ticket, intended for display in the Neo Dashboard Event History.

default_fields_to_update​

A list of field update objects. This typically includes the suggested technician for the resource field of the ticket. This can be used by the "Update Ticket Fields" action.

default_schedule_entries_to_create​

A list of schedule entry objects that Neo suggests creating. This is populated if add_schedule_entry was enabled in the input. This can be used by the "Assign Ticket to Technician" action to create the actual entries in the PSA.

default_schedule_entries_to_update​

A list of schedule entry update objects. This is populated if add_schedule_entry and allow_update_existing_tentative_scheduled_entries were enabled in the input, and Neo identified existing 'Tentative' entries that should be rescheduled to accommodate the new, typically 'Firm', ticket. This output can be used by actions like "Assign Ticket to Technician" to apply the suggested updates to schedule entries in the PSA.

Example Output Message​

The following image shows an example of the kind of detailed notification that can be generated by this action, suitable for platforms like Microsoft Teams. It illustrates how Neo communicates its dispatch suggestion, including the comprehensive reasoning that considers factors like current date, weekends, holidays, technician availability, existing commitments, and the ability to adjust tentative schedule entries.

Example of a Ticket Dispatch notification in Microsoft Teams, showing the suggested technician and detailed reasoning including scheduling considerations like current date, holidays, and calendar modifications.

Use Cases​

1. Standard New Ticket Dispatch​

  • Trigger: New ticket created.
  • Action: "Ticket Dispatch (Suggest Technician)" configured to consider availability, workload (number of tickets), and expertise.
  • Next Action: "Assign Ticket to Technician" to apply the suggestion.
  • Goal: Quickly assign new tickets to the best available and qualified technician.

2. Dispatch with Automatic Scheduling​

  • Trigger: New ticket created with "High" priority.
  • Action: "Ticket Dispatch (Suggest Technician)" with add_schedule_entry enabled, allowed_time_slots defined, and urgent_priorities including "High".
  • Next Action: "Assign Ticket to Technician" (which will also create the schedule entry).
  • Goal: Not only suggest a technician but also proactively book time in their calendar.

3. On-Site Technician Prioritization​

  • Trigger: New ticket requiring on-site assistance (identified by a previous "Categorize Ticket" action, for example).
  • Action: "Ticket Dispatch (Suggest Technician)" with consider_technician_on_site enabled.
  • Goal: Prioritize technicians already at or scheduled to be at the client's location.

Best Practices​

  • Technician Profiles: For optimal expertise-based dispatch (consider_technician_profile enabled), ensure technician profiles in Neo are kept up-to-date with their skills and specializations. If profiles are missing, Neo might initiate a sync, and this can be noted in the output.
  • Custom Instructions: Use the custom_instructions field for company-specific or nuanced dispatch logic that isn't covered by standard settings. Be clear and concise in your instructions.
  • Workload Configuration: If using consider_technician_workload, carefully configure the fields within dispatch_workload_settings (criteria, thresholds, recency) to match how your team defines and measures workload.
  • Scheduling Settings: If consider_technician_calendar and dispatch_calendar_settings.add_schedule_entry are enabled, thoroughly configure dispatch_calendar_settings.scheduled_entry_settings, especially allowed_time_slots and sla_events (for ConnectWise), to align with your operational procedures.
  • Review Event History: Regularly check the Event History in the Neo Dashboard to monitor dispatch decisions, understand the reasoning, and fine-tune configurations as needed.
  • Combine with "Assign Ticket": Remember that this action only suggests. You need to follow it with the "Assign Ticket to Technician" action to make the actual assignment and create any suggested schedule entries in your PSA.
  • Input Ticket Limit: Be aware that if you pass a large number of tickets (more than 30) to this action simultaneously, it will process only the oldest 30 tickets from the input list.
  • Leverage Tentative Entry Adjustments: When using dispatch_calendar_settings.add_schedule_entry for firm bookings, consider enabling dispatch_calendar_settings.scheduled_entry_settings.allow_update_existing_tentative_scheduled_entries. This allows Neo to intelligently reschedule existing 'Tentative' commitments, making it easier to find slots for important new tickets and improving technician calendar optimization.
  • Sequential Processing for Accuracy: When dealing with a batch of tickets arriving at the same time (e.g., multiple alerts from a system outage), enabling "Process Entities Sequentially" in your workflow's trigger settings is highly recommended. This ensures that each dispatch decision is made with the latest workload information, reflecting assignments from preceding tickets in the batch, thus preventing overloading a single technician.