Issuetrak has several types of business rules that allow you to automatically update issues in various ways to keep their progress moving forward. In this article, we will discuss examples of how you can utilize combinations of business rules that will work together to save you time and effort.
Before we get started, it's a good idea to familiarize yourself with the mechanisms at play here:
Understanding the Clock
Issuetrak provides two time measurements the moment an issue is submitted: "Total Time Open" and "Response Time". These are determined by your Hours of Operation and business rules.
|Total Time Open||Adjusted Time Open|
|This is the entire amount of time that an issue has been open including the times that the clock was paused.||This is the amount of time an issue has been open excluding the amount of time the issue was paused.|
The Adjusted Time Open also provides users with the timeframe that the owner of the issue is responsible for.
Why is this Important?Time waiting on a response counts against you. Many businesses and organizations like to measure how long it takes for something to happen. This is often used as a performance metric. Avoiding issue stagnation keeps issues moving to closure. Automated processes keep the issue moving forward and make it clear where accountability lies. Waiting on a response from a user can allow issues to stagnate. Using Escalation Rules to progress the issue to closure allows for open communication. Substatuses are set automatically to show where the responsibility of the issue lies. This allows the issue owner to attend to other issues without having to babysit issues that need another user's response. Implementing business rules allows you to determine when an issue was opened, versus how long the 'ball' has been with you and your team. The Adjusted Time Open clock for any given issue is paused by any rule that is applied to the issue that has the Pause Clock option toggled.
Analyze the Process
There are a few things you will want to consider before creating or adjusting business rules:
- Who should be responsible for the pending action? The responsible user should become aware that they are now in charge of moving the issue forward.
- How long do you want to wait for a response? The escalation rules will fire at a time you configure. Determine how much time you are willing to let the issue sit before an automated action is made to keep the issue moving forward.
- Name your substatus with a good naming convention. The substatuses will inform the users of where in the process the issue is and therefore the substatuses need to be clear and easily understandable at a glance.
- Make a flowchart of your process (Process Document/flow).
We developed a process in the Issuetrak Support site that we've been using to automate our correspondence with customers to keep issues moving forward. We use a combination of Substatus Rules and Escalation Rules to:
- Pause the clock so that time waiting on a user response is not counted against us.
- Quickly ascertain where the responsibility for that issue currently lies.
- Ensure that an issue doesn't stay unattended for a certain amount of time.
Our support team uses Business Rules as a way to respond to our clients consistently, progress their issues along, and make sure that they have been fully satisfied with the resolution. This also ensures that time waiting on the submitter to respond will not count against our Service Level Agreements or affect the reporting of team metrics.
We started with creating substatuses that easily indicate the responsibility and progress of that issue. A good naming convention is important here as this field will indicate many things about an issue. Six substatuses were created to facilitate this process. Your organization may choose to use fewer or more substatuses based on your needs. Issuetrak can be customized to match your workflow and processes very easily.
Substatuses will drive this entire process since all of the automation is triggered by which substatus is on the issue. They need to be clear, descriptive, and easily understandable at a glance.
|Substatus Name||Clock Status||Description|
|Customer response received||Unpaused||
|Pending Customer Response 1||Paused||
|Pending Customer Response 2||Paused||
|Pending Customer Response 3||Paused||
As you can see above, we have configured four of the substatuses to pause the clock since we will be waiting on a response from the submitter when issues are in these substatuses. Pending Customer Response 1 Pending Customer Response 2 Pending Customer Response 3 Pending Closure
Now that we have our foundation of substatuses, it is time to automate them with substatus rules and escalation rules. These rules will look at the substatus in order to determine what actions to take. Our biggest goal is to be able to respond back to submitters as soon as we can. In order to accomplish this, we will create a substatus rule to set the substatus to Customer Response Received every time the submitter added a note to an issue. This will allow us to easily see that immediate attention is needed. Also, the Customer Response Received substatus will now unpause the clock, if it was paused, and put ownership clearly back to the assignee.
Define Substatus Rules
Let's look at the substatus rules we made to reduce our workload:
Issue Event = Note Added by anyone in Submitter's Organization - We use this Issue Event because we have Organizations that contain many users. We wanted to allow other users from that Organization to be able to respond to issues and have the Substatus rule fire. There are other note-added events available that may work better for your needs.
When Substatus = Any Value - This allows the substatus rule to fire any time the submitter responds to an issue which is invaluable when your goal is to respond to issues as quickly as possible.
Set substatus to = Customer Response Received - This substatus is what we use at Issuetrak Support to focus our attention on every day. This substatus means that the submitter has responded and the issue needs our immediate attention.
Now it is time to automate the process further with Escalation Rules. The escalation rules are time-triggered events that fire off after a predetermined amount of time has passed. This keeps the issues moving forward by performing an action on the issues. Escalation rules are used to inform the responsible party that their attention is needed and that the issue has sat too long without action taken.
Here are the Escalation rules we configured:
|Pending Customer Response 1||2 Days after last activity||Substatus = Pending Customer Response 1||
|Pending Customer Response 3||2 Days after last activity||Substatus = Pending Customer Response 3||
|Pending Closure||2 Days after last activity||Substatus = Pending Closure||
Now that the automation is configured you can use the Issue Hub or Dashboard to easily view issue substatuses and monitor the progress of issues. This is valuable information to managers and agents since they can immediately see which issues need attention and which issues are waiting for a response from the submitter. Sorting by substatuses is a technique used to create a worklist and prioritize your issues so that a timely response can occur.
If you have any questions or would like the assistance of our product experts, please do not hesitate to contact us with any questions.