Skip to main content

Ticket Escalation

The "Ticket Escalation" action evaluates a PSA ticket against predefined criteria to determine if it needs to be escalated, for example, by changing its status, reassigning it, or notifying a specific team. This helps ensure that tickets receive appropriate attention and are addressed in a timely manner according to your operational procedures.

Why is it useful?

This action is valuable for:

  • Preventing Stagnation: Automatically flags tickets that are not progressing or have been overlooked.
  • SLA Adherence: Helps in meeting response and resolution times by ensuring tickets are escalated when they breach certain time-based thresholds.
  • Prioritizing Critical Issues: Allows for custom logic to quickly escalate tickets based on content, urgency, or customer importance.
  • Automating Workflows: Reduces manual monitoring by systematically applying escalation rules.

What It Does​

The "Ticket Escalation" action performs the following key functions:

  • Evaluates a single PSA ticket based on the configured escalation_criteria.
  • Supports two main types of escalation logic:
    • Time-Based: Escalates if the ticket's status or owner (primary resource) has not changed within a specified timeframe (minutes_to_wait_before_escalation).
    • Custom Criteria: Uses AI to analyze the ticket's content against user-defined custom_instructions to decide if escalation is warranted.
  • If the ticket meets the escalation criteria:
    • It can optionally remove the current owner (primary resource) from the ticket if remove_owner_from_ticket_if_escalated is enabled.
    • It can optionally set a new status for the ticket, as specified in status_to_set_when_escalated.
  • Controls workflow progression based on the continue_workflow_only_if_escalated setting. If true (default) and the ticket is not escalated, subsequent actions in the workflow are skipped.
  • Outputs messages detailing the escalation decision and any fields that were updated.

How It Works​

The action follows a structured process to determine if a ticket requires escalation:

1. Input Data​

The action processes a single PsaTicket. The core logic is driven by the escalation_criteria field, which dictates whether to use time-based or AI-driven custom criteria. Other inputs like custom_instructions, escalation_settings, status_to_set_when_escalated, and remove_owner_from_ticket_if_escalated further refine its behavior.

2. Escalation Logic Evaluation​

Based on the selected escalation_criteria:

  • Time-Based Escalation (ESCALATE_WHEN_TIME_IS_UP):

    1. Neo notes the ticket's current status and owner (primary resource) when the action begins.
    2. It then waits for the duration specified in escalation_settings.minutes_to_wait_before_escalation.
    3. During this period, Neo periodically (e.g., every minute) re-checks the ticket's status and owner in your PSA.
    4. If, after the full waiting duration, the ticket's status and owner have remained unchanged from their initial values, the ticket is flagged for escalation.
    5. If either the status or the owner changes during the waiting period, the time-based escalation is aborted, and the ticket is not escalated under this criterion.

  • Custom Criteria Escalation (CUSTOM_CRITERIA):

    1. Neo gathers the full content of the ticket, including its summary, description, and notes.
    2. This ticket information, along with the custom_instructions you provide, is sent to an AI model.
    3. The AI model analyzes the ticket against the rules and conditions defined in your custom_instructions.
    4. Based on this analysis, the AI determines whether the ticket should be escalated and provides reasoning for its decision.

3. Post-Escalation Field Updates (If Escalated)​

If the evaluation (either time-based or custom) determines that the ticket requires escalation:

  • If remove_owner_from_ticket_if_escalated is set to True, Neo prepares an update to clear the ticket's current owner (primary resource).
  • If a status_to_set_when_escalated is provided, Neo prepares an update to change the ticket's status to this new value.
  • These intended changes are included in the default_fields_to_update output field.

4. Output and Workflow Control​

  • The action generates EscalateTicketOutput. This includes:
    • default_messages_for_msp: Contains messages detailing the reasoning behind the escalation decision. This list is populated only if escalation was actually required.
    • default_fields_to_update: Lists any prepared field changes (owner, status).
    • default_messages_for_dashboard: Provides a summary for the Event History.
  • The continue_workflow_only_if_escalated setting (defaulting to True) dictates further workflow behavior:
    • If True and the ticket was not escalated, the workflow execution stops, and subsequent actions are skipped. A message indicating why escalation was skipped will be logged.
    • If True and the ticket was escalated, the workflow proceeds to the next action.
    • If False, the workflow always proceeds to the next action, regardless of the escalation outcome.

Configuration Fields​

When you add the "Ticket Escalation" action to a workflow, you'll configure the following:

default_data​

The PSA ticket that Neo should evaluate for escalation.

escalation_criteria​

Determines the method used for escalation. Choose from:

  • Escalate when time is up: Escalates if the ticket's status and owner remain unchanged for a defined period.
  • Custom criteria: Uses AI and your specific instructions to decide on escalation.

continue_workflow_only_if_escalated​

(default: True) If enabled, the workflow will only proceed to subsequent actions if this "Ticket Escalation" action actually escalates the ticket. If False, the workflow continues regardless of the escalation outcome.

custom_instructions​

(optional) Available if escalation_criteria is set to Custom criteria. Provide detailed text-based instructions for the AI to evaluate the ticket. Clearly define the conditions under which a ticket should be escalated.

remove_owner_from_ticket_if_escalated​

(default: False) If enabled, and the ticket is escalated, the current owner (primary resource) of the ticket will be removed.

status_to_set_when_escalated​

(optional) If the ticket is escalated, its status will be changed to the PSA status selected here. If left blank, the status will not be changed by this action.

escalation_settings​

(optional) Available if escalation_criteria is set to Escalate when time is up. This field groups settings related to time-based escalation:

  • minutes_to_wait_before_escalation​

    (default: 10, maximum: 60) The number of minutes Neo should wait. If the ticket's status and owner do not change during this period, the ticket will be escalated.

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 escalation decision and the reasoning behind it. These are suitable for internal notes or notifications. This list is only populated if escalation was determined to be necessary.

default_fields_to_update​

A list of field update objects. If escalation occurred and remove_owner_from_ticket_if_escalated was true or status_to_set_when_escalated was provided, this list will contain the necessary updates for the ticket's owner and/or status. This output can be used by a subsequent "Update Ticket Fields" action.

default_messages_for_dashboard​

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

Use Cases​

1. Time-Based SLA Breach Warning​

  • Trigger: Ticket status is updated to "In Progress - Tier 1".
  • Action: "Ticket Escalation" with escalation_criteria = Escalate when time is up, minutes_to_wait_before_escalation = 120 (2 hours), status_to_set_when_escalated = "Tier 1 - SLA Risk", continue_workflow_only_if_escalated = True.
  • Next Action: "Notify Internal Team" (e.g., Tier 1 Team Lead).
  • Goal: Automatically flag and notify if a Tier 1 ticket shows no owner or status change for 2 hours, indicating potential stagnation.

2. Custom Escalation for Urgent Keywords​

  • Trigger: New ticket created.
  • Action: "Ticket Escalation" with escalation_criteria = Custom criteria, custom_instructions = "Escalate if the ticket summary or description contains 'system down', 'outage', 'cannot work', or if priority is 'Critical'.", status_to_set_when_escalated = "Urgent - Immediate Attention Required", remove_owner_from_ticket_if_escalated = False.
  • Next Action: "Assign Ticket to Technician" (to a dedicated urgent response team/technician).
  • Goal: Rapidly escalate tickets that indicate severe, widespread, or business-critical issues based on their content.

3. Escalate Unactioned "Awaiting Customer" Tickets​

  • Trigger: Ticket status changed to "Awaiting Customer Response".
  • Action: "Ticket Escalation" with escalation_criteria = Escalate when time is up, escalation_settings.minutes_to_wait_before_escalation = 7200 (5 days), status_to_set_when_escalated = "Follow-up Required/Close", continue_workflow_only_if_escalated = True.
  • Next Action: "Chase Customer" action, or "Notify Internal Team" to manually review and close.
  • Goal: Proactively manage tickets waiting on customer input for an extended period, moving them towards resolution or closure.

Best Practices​

  • Specificity in Custom Instructions: When using CUSTOM_CRITERIA, make your custom_instructions as precise and unambiguous as possible. Clearly outline conditions, keywords, and scenarios. Test thoroughly with different ticket examples.
  • Appropriate Timeouts: For ESCALATE_WHEN_TIME_IS_UP, select a minutes_to_wait_before_escalation value that aligns with your SLAs and operational capacity. Very short timeouts might lead to unnecessary escalations.
  • Status/Owner Change Focus: Remember that time-based escalation specifically monitors changes to the ticket's status and owner (primary resource). Other activities, like adding a note without changing status or owner, will not prevent a time-based escalation.
  • Workflow Synergy: Use "Ticket Escalation" in conjunction with actions like "Notify Internal Team," "Assign Ticket to Technician," or "Update Ticket Fields" to create comprehensive automated escalation processes.
  • Strategic Use of continue_workflow_only_if_escalated:
    • Keep it True (default) if subsequent actions (e.g., notifying an escalation team) should only occur if the ticket was actually escalated.
    • Set it to False if you want subsequent actions (e.g., logging the check) to run regardless of whether an escalation took place.
  • Monitor Event History: Regularly review the Neo Dashboard Event History to see how the "Ticket Escalation" action is performing. The default_messages_for_dashboard and default_messages_for_msp provide insights into why decisions were made, helping you refine your configurations.
  • Valid PSA Statuses: Ensure that any status name provided in status_to_set_when_escalated matches an existing, valid status in your PSA.