Understanding Escalations vs Forwarding in Ticket Routing Rules
In Rocketship, one of the core modules is Ticket Routing. With Ticket Routing, you define a set of skills for each team and then build a ruleset of how tickets “route” between those teams.
For example, you may have a Ticket Routing Rule “NOC Backups” with the teams: NOC Tier 1 and NOC Tier 2. NOC Tier 1 should get all initial tickets, and, when they hit a stopping point, they should escalate to NOC Tier 2.
Escalations
When Escalating a ticket, a ticket from a lower “tier” will escalate to the resource in the Escalation Path you define in the Ticket Routing Rule. This is most common in situations where lower tiers are time-constrained in how much time they can dedicate to a ticket, or where a lower tier may not have the same permissions as a higher-level tier. Learn more about Escalation Rules here.
Forwarding (Overriding Rocketship)
There are times however you want to push a ticket down to a lower tier or sideways within the same tier. For example, a lower tier may escalate a ticket up to have a higher tier tech made modifications/changes that only the higher tier can do, but then the ticket should be “de-escalated” back to the original tech so they can complete their work.
In that situation, you will use Forwarding. With Forwarding, you continue to use the Ticket Routing module, but you override the decision-making of the module and instead specify the exact team and resource you want to be assigned the ticket. Note, Forwarding still supports automated scheduling (optionally) as well as data collection from the tech via a form.
In the screenshot below, you can see that a ticket is being Forwarded to another team/resource directly. Notice that it is optional whether the newly assigned tech will be scheduled work.