Ticket escalation is the process of transferring ownership of a ticket or requesting assistance from another agent, support group, or escalation level to help resolve a customer issue more effectively.

Escalation is typically to ensure that complex, urgent, or unresolved customer issues are reviewed by the appropriate agent, support group, or escalation level.

Effective escalation helps support teams:

• Route tickets to the most appropriate team or specialist.
• Prevent potential SLA breaches.
• Address critical customer issues more quickly.
• Improve collaboration across support teams.
• Ensure unresolved issues receive the attention they need.

This article explains when to escalate a ticket, how to perform an effective escalation in BoldDesk, and the best practices for ensuring a smooth handoff between support teams.

Prerequisites

Before escalating a ticket, review the following:

• The customer’s latest message.
• Previous public replies and private notes.
• Ticket status, priority, category, assigned agent, and assigned group.
• SLA timers such as:
  • First Response Due
  • Next Response Due
  • Resolution Due
• Attachments, screenshots, logs, and recordings.
• Related tickets or previous issues from the same customer.

Escalation Checklist

Before escalating a ticket, ensure that you have:

• Reviewed the ticket history.
• Reviewed previous private notes.
• Evaluated customer impact and urgency.
• Checked applicable SLA timers.
• Documented troubleshooting already performed.
• Identified the correct agent or group.
• Defined the required next action.
• Determined whether a customer update is required.

Escalate a Ticket to Another Agent or Group

To manually escalate a ticket:

1. Open the ticket that requires escalation.
2. Review the complete conversation, ticket properties, and internal notes.
3. Add a private note documenting the escalation details.
4. Update the Assigned Agent if ownership should be transferred to a specific agent.
5. Update the Assigned Group if another support team should handle the ticket.
6. Update the Priority if the customer impact or urgency has changed.
7. Update the Status according to your organization’s escalation workflow.
8. Save the ticket.

Add an Escalation Note

Before reassigning the ticket, add a private note explaining the escalation.

A good escalation note should include:

• Reason for escalation.
• Issue summary.
• Troubleshooting already completed.
• Customer impact or urgency.
• Required action from the next agent or group.
• Relevant ticket IDs, links, screenshots, or logs.

Example Escalation Note

Reason:
Requires database team investigation.

Issue Summary:
Customer reports intermittent login failures.

Actions Completed:
- Verified account status.
- Cleared authentication cache.
- Reviewed application logs.

Customer Impact:
Users are unable to access a production account.

Required Action:
Database team to review authentication records and investigate login failures.

Attachments:
Relevant application logs attached.

Notify the Customer When Required

If the escalation may affect the response or resolution timeline, send a public reply to keep the customer informed.

The update should:

• Acknowledge the issue.
• Inform the customer that the appropriate team is reviewing it.
• Set expectations for next steps.
• Avoid exposing internal escalation details.

Escalate Tickets Based on SLA Risk

Tickets approaching an SLA breach often require immediate review and escalation.

When evaluating SLA-related tickets, review:

• First Response Due.
• Next Response Due.
• Resolution Due.
• Ticket Priority.
• Assigned Agent.
• Assigned Group.
• Current Status.

If the ticket requires urgent attention:

1. Review the SLA timer.
2. Add a private note describing the SLA risk.
3. Reassign the ticket to the appropriate agent or group.
4. Update the priority if necessary.
5. Notify the customer if delays are expected.

Use Status and Priority During Escalation

Depending on your organization’s workflow, ticket fields such as Status and Priority may be used to indicate escalation.

Examples:

• Change Priority from Medium to High when urgency increases.
• Change Status to an escalation-related status configured in your workspace.
• Change Assigned Group to a specialist or second-level support team.

Ownership After Escalation

Follow your organization’s support process to determine ownership after escalation.

Depending on your workflow:

• Ownership may transfer to the new agent or group.
• The original agent may remain responsible for customer communication.
• Multiple teams may collaborate using private notes and mentions.

Always ensure ownership responsibilities are clearly understood after escalation.

What Happens After Escalation

After a ticket is escalated:

• The ticket is assigned to the selected agent or group.
• The new owner can review the ticket history and private notes.
• The ticket continues to follow its configured SLA policy.
• The customer can continue communicating through the same ticket.
• Internal teams can collaborate using private notes and mentions.

Best Practices for Ticket Escalation

Follow these best practices when escalating tickets:

• Escalate only after reviewing the ticket history.
• Add a detailed private note before reassigning the ticket.
• Include troubleshooting steps already completed.
• Document customer impact and urgency.
• Assign the ticket to the correct group or specialist.
• Clearly state the required next action.
• Notify customers if escalation may delay resolution.
• Review SLA timers before updating the ticket.
• Avoid resolving or closing tickets prematurely.
• Confirm ownership responsibilities after escalation.

Troubleshooting

The Escalated Agent Cannot Access the Ticket

Possible causes

• The agent does not have access to the assigned brand.
• The agent is not part of the required group.
• The ticket is restricted by permission or visibility rules.

Resolution

• Assign the ticket to a group that has access to the ticket.
• Contact an administrator to review the agent’s role, group, brand, and ticket access permissions.

The Ticket Was Escalated Without Enough Context

Possible causes

• No private note was added.
• Troubleshooting steps were not summarized.
• The customer impact was not documented.

Resolution

• Add a private note with the issue summary, completed checks, and required next action.
• Mention the next agent or group if immediate attention is required.

The Ticket Still Breached SLA After Escalation

Possible causes

• The ticket was escalated too late.
• SLA timers were already close to breach.
• The escalated group did not receive enough context.
• The ticket remained in a status where SLA continued running.

Resolution

• Review the SLA timer before escalation.
• Add an SLA risk note during escalation.
• Confirm that the ticket is assigned to the correct group.
• Follow your organization’s SLA handling process.

Frequently Asked Questions

1. Can agents manually escalate tickets in BoldDesk?
   Yes. Agents can escalate tickets by reassigning the ticket to another agent or group, updating priority or status, and adding a private note with the escalation details.

2. Should I add a private note before escalating a ticket?
   Yes. Add a private note before escalation so the next agent or group understands the issue, previous troubleshooting, and required next action.

3. Does escalating a ticket notify the customer?
   Reassigning or updating a ticket does not replace the need for a customer update. If the escalation affects the response or resolution timeline, send a public reply to keep the customer informed.

4. Does escalation affect SLA timers?
   The ticket continues to follow the SLA policy configured for the ticket. Review the SLA timer before escalating and follow your organization’s SLA process.

5. What should I include in an escalation note?
   Include the reason for escalation, issue summary, troubleshooting completed, customer impact, and the action required from the next agent or group.

Related Articles

1. How to Create SLA Policies in BoldDesk
2. How to Send Ticket Reminders and Escalation Emails Using SLA
3. How to Automate Ticket Escalation Across L1, L2, and L3