Workflow Rules That Apply to All Tickets
Incident IQ has several automation rules that we have put in place to ensure efficient ticket handling and communication. These rules apply to all staff working tickets and help streamline escalations, follow-ups, and ticket closures.
1. Ticket Assignment and Routing Logic
The system uses three primary data points to determine which technician or team receives a ticket. If a ticket is not appearing in the correct queue, verify these fields:
Location: The system routes based on the Location field dropdown. Ensure this reflects the physical location of the user or device, rather than just mentioning the location in the description or comments.
Issue Type: This is the most effective tool for routing. Updating the Issue Type will often trigger a background rule to reassign the ticket to a specialized team or individual automatically.
User Role (Submitted By / On Behalf Of): The system identifies whether the requestor is campus-based or district-based. Using the "On Behalf Of" feature correctly ensures the ticket follows the requester's specific routing path.
Initial Assignment:
By default, tickets submitted by staff at a campus are automatically assigned to that building’s Campus Technology Contact for first-level support.
Tickets submitted by staff at the district-level are automatically assigned to there first-level support team.
If a Campus Technology Contact submits a ticket themselves, the system identifies them as a technician and automatically escalates the ticket to the District Network Technician assigned to that campus. No manual status change is required.
2. Escalation Procedures
There are two ways a ticket is moved from a campus level to a district or specialized level:
Automatic Escalation
If a Campus Technology Contact submits a ticket themselves, the system identifies them as a technician and automatically escalates the ticket to the District Network Technician assigned to that campus. No manual status change is required.
Manual Escalation (Status Change)
Users with permission to update ticket statuses can escalate any ticket by changing the status to “Escalated to District Network Tech”. When this status is applied, the system routes the ticket based on the following logic:
District Staff: If the requestor is a District-level employee, the ticket is assigned to their specific designated support person.
Specialized Issues: If the Issue Type is updated to the correct category, the ticket is automatically assigned to the specialist, regardless of the location.
Campus Based Issues: For all other campus-based requests, the ticket is routed to the District Network Technician assigned to that campus.
3. Automated Follow-Up and Inactivity Rules
To maintain an efficient queue, the system manages communication for tickets set to “Waiting on Requestor” status.
3-Day Mark: If there is no activity for 3 days, the system sends an email reminder to the requestor and other followers. The ticket status is updated to Follow-Up Sent – Closes in 5 days.
5-Day Mark: If there is no response within 2 days of the follow-up notification (5 days total), the system automatically closes the ticket with the status Closed – Due to No Reply.
An internal comment is added to the ticket history to document that the closure was due to a lack of response.
4. Reopening Tickets and Time Limits
Even after a ticket is closed, users have a limited window to resume the conversation:
7-Day Reopen Rule: A user can reply to a ticket notification email or add a comment to the ticket to automatically change the status back to Reopened. This is only possible within 7 days of the ticket's closure date.
Permanent Closure: After 7 days, the ticket is locked. Any further communication from the user will not reopen the ticket, and a new request must be submitted.
Handling Unrelated Issues (Different Issue Tag)
If a requestor replies to an existing or recently closed ticket with a new, unrelated problem, technicians should not continue work within that ticket.
Procedure:
Navigate to the ticket’s Info section.
Add the tag: Different Issue.
Result: The system will automatically change the status to Completed and send an email to the requestor. This email explains that the current ticket has been closed and provides instructions on how to submit a new ticket for their unrelated request. This ensures that technician metrics and ticket history remain accurate.
Troubleshooting: Why didn't the ticket route?
If a ticket is sitting in the wrong queue or did not escalate as expected, check for these common items:
Location mismatch: Verify that the Location field is correctly set to a specific campus. If a ticket is set to the wrong location, it will not know which Campus Tech or Network Tech to assign.
Missing "On Behalf Of" Information: If you are a technician submitting a ticket for a staff member, the system will route based on your permissions unless you use the On Behalf Of field. Always ensure the end-user is correctly identified in this field.
General vs. Specific Issue Types: If an Issue Type is too broad (e.g., "Hardware"), the system may default the assignment to the wrong level. Selecting a specific Issue Type (e.g., "Can’t Connect to Wi-Fi" etc.) is the most reliable way to trigger specialized routing.
Best Practices
To make the most of these automation rules, keep the following in mind:
Update the Issue Type Early: If you realize a ticket belongs to a different department or specialist, change the Issue Type immediately.
Use "Waiting on Requestor" for Accuracy: Do not keep tickets in an "Open" or "In Progress" status if you are waiting to hear back from the user. Moving them to Waiting on Requestor status ensures the 3-day and 5-day automated reminders keep the ticket moving without your manual intervention.
Standardizing the "Different Issue" Tag: Only use the Different Issue tag if the requestor is asking for something completely unrelated to the original problem. If the new request is related to the current troubleshooting, it is better to continue within the same ticket to maintain a clear history.