Structural 1st Line vs. 2nd Line Escalation

[Kraleemil]

I also had a thought about how escalations are handled. Right now, moving a ticket often just means reassigning it to a different team or queue. I think there is an opportunity to introduce a more structured ITIL approach.

True Escalation: Instead of just changing the "Assigned To" field, there could be a dedicated "Escalate" button. Hitting this actually changes the ticket's state from a "1st Line" ticket to a "2nd Line" ticket.

Dynamic Changes: Once it crosses that threshold into 2nd Line, the rules could shift. SLA timers could adjust automatically (since deep engineering work takes longer than a service desk fix), or new technical fields could become mandatory.

De-escalation: If the 2nd Line team gets a ticket that should have been an easy fix for the service desk, they can hit "De-escalate." This bounces it back to the 1st Line queue, maintaining clear boundaries and accountability between the tiers.

I think this would really help teams keep their workflows clean as they scale up!

[Kraleemil]

Hi

I thought about maybe having the possibility to assign a task to a team, it could be when escalating a ticket.

Eg. the helpdesk team doesn't know who in infrastructure does x and y.
And then infrastructure can dispatch the ticket from the team queue to an person.

It could be also be used for a default recipient/team of tasks, like when x form is filled out then set recipient/team to y based on z.

[edmozley]

Hi,

I am looking at this now - here's where my thinking is currently at:

https://github.com/edmozley/freeitsm/wiki/Team-Assignment-and-Escalation

[edmozley]

Hi @Kraleemil,

Good news - the assign-to-team part of your comment is built and on main now. A ticket can be handed to a team as well as to a person, the two are independent so neither one clears the other, everyone in the receiving team gets a bell notification, and you can group the ticket folders by team. You can set the team from the ticket itself, from the right-click menu in the list, in bulk across a selection, or from a workflow that raises a ticket straight into a queue. If your install has no teams, none of it appears.

If you want it now you can pull main - just run System - Verify database afterwards, as there is a new column on tickets, and take a backup first since this is unreleased code. Otherwise it will be in 1.6.0.

What 1.6.0 will add on top: the Escalate and De-escalate buttons from your original post, a default team set by a form, and assigning tasks to a team rather than only tickets.

I have not committed to the rest of the original post yet - SLA timers that change on escalation, and fields that become mandatory at 2nd line. Both are real, but they need more thought than the queue itself did, and I would rather not half-do them. My current thinking on all of it, including what I have deliberately left out and why, is here:

https://github.com/edmozley/freeitsm/wiki/Team-Assignment-and-Escalation

Thanks for the detail in the original post - the tier boundary framing is what made the team queue obviously the right first piece.