Client Response Timer Workflow Example

This Workflow article will help ticketing administrators to create a workflow and process to help automate the management of "ghosted" tickets. The user must have the following settings enabled within the Security Role: Must be a global admin or app admin in the desired ticketing application. 

Overview

There are times in the course of IT service delivery where submitted tickets go cold and the requester becomes unresponsive to inquiries for more information or requests for action on their part to bring the request to completion.   In short the client "ghosts" the service delivery team.   This is a common occurance when a requester submits a request for support around an issue that self resolves or is solved with simple action (e.g., restarting a laptop) and they no longer have the need and thus forget the original request.  When this happens it can be frustrating as well as a waste of resource time to continually monitor the ticket, send follow up notifications, and ultimately close the ticket due to inaction.  This example shows a way you can utilize some specific settings in TeamDynamix in conjunction with a workflow to allow the system to send necessary reminders to the requester and ultimately close the ticket if it truly has been abandoned by the requester.  This can also be helpful in reporting how often this occurs and if there are repeat offenders. 

Building a Client Response Timer

This example includes a look at the workflow itself, some related settings, and how this process could be applied:

Workflow Design

1. Navigate to administration section for the ticketing application where this process is to be applied:
   • Global Admins: TDAdmin> Applications> Ticketing App> Workflows
   • App Admins: TDNext> Application Menu> Ticketing App> Click on the Gear Icon on the upper right> Admin> Workflows
2. On the workflows page select the green + New from the top of the page
3. Provide a name; remember this is the name your technicians will use to identify it when engaged, 
4. If desired add a Description or Purpose to give greater context
5. Save the workflow
6. Select the new workflows name from the workflow list to open it
7. Click the green "View Builder" to open the workflow builder screen
8. This example workflow uses 9 steps:
   1. Click the New Step button to create a timer step
      1. Name the step (e.g., "Wait 3 Days")
         • NOTE: This is an optional amount of time.  In this example we are going to wait 3 operational days.  You may choose longer or shorter.
      2. In the Type drop down select "Timer"
      3. Add a description if desired
      4. Set the duration value of "3" Days (or whatever amount you want that matches the name defined on the step)
      5. Check the box to use operational hours to ensure it only counts against active organizational time
      6. Click Save then close the popup
      7. Repeat steps under 8.1 above 3 times to create three identical timers
         • The timers should look like this: 
   2. Click the New Step button to create a condition step
      1. Name the step (e.g.,"Status Check")
      2. In the Type drop down select "Condition"
      3. Add a description if desired
      4. In the first Conditions column drop down select "Status
      5. Leave or set the operator value as "is one of"
      6. Select the Value of "On Hold"
         • NOTE: You may want to create custom statuses to call out that a ticket is waiting on the requester such as "Waiting on Client".  If you do want this, make sure to create an status with an 'on hold' status class  in the statuses section of your ticketing admin.  Remember you cannot delete statuses once created; only deactivate. For more info on statuses see this article: Ticket Statuses
      7. Click Save then close the popup
      8. Repeat steps under 8.2 above 3 times to create three identical condition steps
         • The conditions should look like this: 
   3. Click the New Step button to create a Notification Step
      1. Name the notification (e.g., "Notify Requestor of Need for Response")
      2. Add a description if desired
      3. Because this is going to be used on many different tickets with different requestors we will skip the defined "Recipients(s)" value and instead move to the "Recipient Role(s)" field;  Choose "Requestor"  for the role.
      4. Define who will be the fallback for the Recipient Role; this value is only used if there is a data gap on a ticket
      5. Define the subject of the email message
         • EXAMPLE:  IT Dept - Your Ticket needs your response
      6. Define the HTML Body of the message
         • This can be a simple text string or something more complex.  Attached to this KB example code you can use. 
         • Please note the example has a logo URL baked in.  If you are not familiar with editing HTML to change that logo you may want to start after line 6 which says "</table>"
         • See the .txt file in the attachment section on the right column named: "Response Request Notification HTML" to find instructions and the code
         • Click Generate Preview as often as you like to see an example of how your current design will display in an email
      7. Click Save and close the popup
      8. Repeat the steps under 8.3 above 2 times.  You only need 2 of these.  The final notification will look different. 
         • Your notification should look something like this: 
         • If you do use the attached HTML code the preview will look something like this: 
   4. Click the New Step button to create your final notification step
      1. Name the notification (e.g., "Final Notification to Requestor")
      2. Add a description if desired
      3. Because this is going to be used on many different tickets with different requestors we will skip the defined "Recipients(s)" value and instead move to the "Recipient Role(s)" field;  Choose "Requestor"  for the role.
      4. Define who will be the fallback for the Recipient Role; this value is only used if there is a data gap on a ticket
      5. Define the subject of the email message
         • EXAMPLE:  Ticket Closure Notification
      6. Define the HTML Body of the message
         • This can be a simple text string or something more complex.  Attached to this KB example code you can use. 
         • Please note the example has a logo URL baked in.  If you are not familiar with editing HTML to change that logo you may want to start after line 6 which says "</table>"
         • Please note the example also has a URL string for the client portal service catalog currently pointed at https://solutions.teamdynamix.com.  You will want to change that URL to match your client portal resources.
         • See the .txt file in the attachment section on the right column named: "Final Notification HTML" to find instructions and the code
         • Click Generate Preview as often as you like to see an example of how your current design will display in an email
      7. Click Save and close the popup; you will not need to replicate this step
         • Your final notification step should look something like this: 
         • If you use the attached "Final Notification" HTML code your preview will look something like this: 
9. At this point all nine steps should be created and visible on your workflow builder; use the "four-arrow" handle button to move the the step blocks around the screen
10. Move the Reject and Approve exit blocks to the far right
11. Stack the other steps in three columns with a timer at the top, a condition below that and a notification below that
12. The "Final notification to requestor" block should be the last step at the bottom of the last column
13. If the top left timer is not blue with the play icon next to its name click on the gear icon for that step and select "Mark as Start"
14. Click on the word "Complete" in that first timer and drag to draw a connector to the condition directly below it
15. Click on the "Condition Not Met" on that second step condition and drag all the way to the "Reject" ending block to draw a connection to it
16. Click on the "Condition Met" on that second step condition block and drag to the Notification below it to draw a connection
17. Click on the "Complete" on that notification and drag to draw a line up to the timer at the top of the second column
18. Repeat the connection steps in 14-16 to finish the connections
19. The last "Complete" on the "Final Notification to Requestor" will be connected to the "Approve" ending block
    • Your workflow should look like this now: 
20. To finish the workflow design click on the Workflow dropdown from the top menu bar and choose "Details"
21. On the Details popup Feel free to rename or add/adjust the description if desired
22. Click on the dropdown under Approval Status and choose "Closed"
    • NOTE: You may want to create custom statuses to call out that this closure is not standard, such as "Inactive Closure".  If you do want this, make sure to create a status with a 'completed' status class in the statuses section of your ticketing admin.  You will likely still want credit as a "completed" ticket when reporting; not cancelled.  Remember you cannot delete statuses once created; only deactivate. For more info on statuses see this article: Ticket Statuses
23. Leave the Rejection Status as blank; this will allow the workflow to stop after a client response and not make any changes to the status
24. Click save 
25. Open the File dropdown from the top menu and choose "Save and Check In" to complete the design
26. If you are ready return to the workflow page in TDAdmin> Applications> Ticketing App> Workflows select the workflow and choose the green Activate button at the top to make the workflow available; you can always return and activate later if you do not have all the settings prepared

 

Ticketing Application Settings

1. There are additional settings that will support this process; while you could manually change the status of the tickets to allow the workflow to have an accurate condition check relating to if the requestor has responded, that is not a very practical process and does not add to the automated value of this workflows function
2. Navigate to TDAdmin> Applications> Ticketing Application> Settings
3. On the settings page in the top "General" section locate the On Hold Options
4. Check the box to Automatically take tickets off hold when they are commented on
   • This setting will allow the ticket to move off of the on hold class of status when a requestor responds back to the ticket
5. Optionally you can define the desired status in the dropdown under the Automatic Off Hold Status setting just under that check box setting
   • If you do define this, likely you would want something like in process or possibly a custom status
   • If you do not choose a value here the ticket will simply move from the on hold class status back to the last status before it was put on hold
6. Click Save
   • Remember this is only for this one application if you have multiple ticketing applications this will not impact other applications

How to Apply this Process

1. When you are ready to apply this process to your tickets you will want to start by making sure the workflow is active at TDAdmin> Applications> Ticketing App> Workflows
2. The first thing a technician would do is comment to the requestor asking for the desired action/information; this could be as a stand alone comment on the feed or as part of an update
   •  It is important to make sure you notify the client and leave the comment as public so it can be viewed by the requestor if they look at the ticket in the client portal
3. After the comment is made in the feed or as part of the comment on an update set the tickets status to the "On Hold" status used in the condition check on your workflow
4. Now that the client has been notified, the comment is confirmed as public, and the ticket status is On Hold the workflow can be started
5. Click on the ticket Action button> Assign Workflow
6. Select the Client Response Timer workflow in the dropdown and click Save
   1. If the client responds back
      1. the status will automatically drop off of On Hold (based upon the Ticket Application Setting)
      2. When the workflow checks the status it will find the ticket no longer on hold and move to the "reject ending" of the workflow closing the workflow and making no further change to the ticket
      3. If a technician gets back to the ticket before the workflow checks the status they can:
         1. Leave the workflow to stop itself in time
         2. Manually stop the work flow with Actions> Remove Workflow
         3. If further communication has been requested from the requestor use Actions> Reassign Workflow to restart the workflow 
   2. If the client does not respond to the ticket via email or by making a comment on the ticket through the client portal
      1. The workflow will wait the defined timer periods and send notifications ultimately sending the final notification and moving to the "approved ending" of the workflow and closing the ticket to the defined complete status set in the workflow builder

 

Gotchas and Pitfalls

• Make sure your workflow is marked as Active to allow technicians the ability to utilize it
• Custom statuses can add value to visible definitions on the tickets (custom on hold and custom closure) as well as statistics but remember you cannot delete statuses so use discretion when creating new statuses
• The automatic off hold setting is needed to drive the most value from this process; it could be managed manually by technicians but may result in automatic notifications being sent on tickets that have already been responded to by the requestor
• Remember that only 1 workflow can be active on a ticket at a time; you would not want to plan to run this on tickets that already have workflows in play
• This must be activated on a ticket either by the technician (as described in the process above) or could be assigned via an automation rule if a ticket needed to carry this function immediately at creation