Escalating Your Tickets With Groups

Have more questions? Submit a request


  • Matthieu ETIENNE
    Comment actions Permalink


    we want to provide to an agent from a Group X the possibility to assign a ticket receieved on this group to  another Group Y,  without having visibility to the tickets already assigned in the Group Y.

    Anyway to do this? 

  • Alex Culligan
    Comment actions Permalink

    Hi Matthieu,

    I see you already have a ticket with us and an Advocate is helping you get this done. I will let the Advocate continue working with you on that ticket, but let us know if you have other questions.

  • info
    Comment actions Permalink

    Hello Support team.

    It would have been nice if previous Support agent would have published the solution either way... because now i have to create a new ticket for the solution of that escalating problem with the assignment to a higher group - wich doesn't work.

    so please tell me - when a agent is assigning the ticket to the higher group with no particular agent but only the group - it changes back... (e.g Level1 to Level 2.... but changes back to Level 1!)



  • Jessie Schutz
    Comment actions Permalink

    Hey info,

    Most of the time when this happens, it's because there's a trigger that's causing the group assignment to revert when the ticket is submitted. That's the first place I'd recommend you check!

  • HCC Support Admin
    Comment actions Permalink

    I have a group and one agent under it. We have an organization and selected a group for that organization. Is it correct to say that the tickets of that organization will automatically assign to the agent? (We don't have any other active triggers set for that org). Does it automatically assign to the agent if the system identifies there is only one agent in that group?

    The reason why I asked this is that we have marked other organization to other groups with multiple agents but it only assigns to the group and not to an agent.

  • Jessie Schutz
    Comment actions Permalink

    Hey there!

    You are absolutely right. If a group only has one agent in it, Zendesk will skip the middle man and assign directly to that agent. If there are multiple agents, it just assigns to the group so you can select which agent should get it.

  • uday
    Comment actions Permalink

    I want a 3 level support system. 
    Level 1 - Assign All the tickets coming from a particular organization to an agent responsible to handle tickets at Level 1

    Level 2 - An agent within level 1 can escalate the ticket to an agent within Level 2. An agent within Level 1 must be able to view the progress on the ticket escalated to an agent within Level 2.

    Level 3 - An agent within level 2 can escalate the ticket to an agent within Level 3. An agents within Level 2 and Level 1(if the ticket was escalated from Level 1) must be able to view the progress on the ticket escalated to an agent within Level 3.

    I have bought 3 agents subscription and i have 1 organization. level 1 should be able to view all the tickets for this organization and level 2 and Level 3 support is provided by ourselves.So, basically Level 1 will can escalate a ticket to Level 2 and an follow this ticket.

    1. Level 1 can access tickets that belongs to the organization, even if they escalated them to Level 2. 
    2. Level 2 can access tickets those are escalated to level 2 only. 
    3. level 3 can view all the tickets irrespective of Level 1 and level 2. 
    4. When a ticket is escalated to level 2 from level 1 then reply on the ticket from level 2 may or may not go directly to end user. Level 2 may just want to reply to level 1 but not to end user.

    is this type of workflow possible through Zendesk?

  • Nicole - Community Manager
    Comment actions Permalink

    Hi Uday,

    Yes, this kind of workflow is exactly what Zendesk is set up to do, and is, in fact, how we run our support operation.

    Here’s how it would work:

    1. You would have a trigger set up to automatically assign tickets coming from organization X to your level 1 agent.

    2. When the L1 agent needs to escalate to L2, they would reassign to the L2 agent (this could also be a group of agents if your teams expand in the future). You could also create a macro that your L1 agent would apply to the ticket to escalate it to T2.

    The L1 agent would need to cc them selves (or you could have the macro automatically cc them) so that they can continue to follow the ticket.

    1. The L2 agent would use a similar process to escalate to L3.

    To meet the needs of your restrictions, you would need to create groups for your agents to manage ticket visibility. For point #4, the L2 agent would simply use an internal note to communicate with the L1 agent, which is a part of the ticketing system.

    Here are some additional resources and references on ticket escalation:

    Tip of the week: escalating tickets

    The art of the ticket escalation process

    Escalating your tickets with groups

    Hopefully that gets you pointed in the right direction, but feel free to let us know if you have additional questions!

  • Pregan
    Comment actions Permalink


    Our escalation process is as follows:

    1. Tier 1 agents requests the relevant info
    2. Tier 1 responds to the customer with a public note, confirming that the ticket has been escalated
    3. Tier 1 escalates to Tier 2 via macro (Private note)
    4. Tier 2 responds to Tier 1 via private note(Macro)
    5. Tier 1 delivers a resolution to the customer and resolves the ticket

    How do we track the first reply time of Tier 2 across these tickets and how do we get a live dashboard in play to reflect current Tier 2 SLA clocks (like you would see in a view for Tier 1 First Response SLA about to breach)?

    Tier 2 only ever communicates with Tier 1 via Private note.


  • Brett - Community Manager
    Comment actions Permalink

    Hi Pregan,

    This would most likely require a custom metric on your end using Insights. you'll want to take a look at the following article on how to report on the duration between two or more ticket events in minutes.

    Additionally, the FRT SLA looks at the time from when a ticket has been created to the first public response sent by an agent. This would not factor in when escalating a ticket to your T2 team unfortunately. The closest target you could use is the Periodic Update as mentioned in the following article: Defining and using SLA policies (Professional and Enterprise)

    You may also want to take a look at our App Marketplace to see if there's a 3rd party integration that can accomplish what you're looking for. Specifically the SLA Management app. Keep in mind that if you do have questions regarding the integration, you'll want to reach out to the developers of the app directly.



Please sign in to leave a comment.

Powered by Zendesk