15 Statuses to Rev Up MSP Service Delivery
I remember once writing “Statuses seems like a light subject, but let’s jump in and see what we get." But now it’s nowhere to be found. I feel like I should make a sign (or at least a catchy graphic) that says, “If the article is found, please return it to its rightful owner.” With that being said, let’s give Statuses a go and see what we can uncover... For the Technician and Service Coordinator dashboards to be fully functional, a status review is mandatory. Too many of the dashboards rely on Status to be set up correctly. Others need new statuses created to leverage working from a single dashboard as opposed to surfing all over the PSA software to get your work done. Then there are the times when a Status is needed just to get the Tickets On-Hold out of my face.
Recommended Statuses & When to Use Them
Here is the list of recommended Statuses we feel are the most useful, as well as tips on when to use them: [su_note note_color="#fffe39" text_color="#0a0808"]To download a spreadsheet of the complete list, along with Widget, SLA Event, SLA clock, Workflow Rule, and notifications information per Status, click here. [/su_note]
NEW:
By default, the PSA software creates all tickets with the status ‘New’. All New tickets show up in both the Triage and Next SLA Triage widgets. The status New does not trigger any SLA event. As a safety net, a WFR should move all Tickets with status New to the Triage Queue with no notifications.
Request for Information:
In the Triage process it may be realized that not all the information needed to prepare the request for engagement is in the Ticket. If the missing information is not available to the Service Coordinator and is needed from the Customer, putting the ticket in status Request for Information moves the ticket to the Waiting Customer Widget. It then sets the First Response SLA, pauses the SLA Clocks, and a Workflow Rule sends a pre-formatted notification to the Service Coordinator. The Service Coordinator edits the notification asking for the missing information and forwards the notification to the Customer.
Ready to Resolve:
This status moves the ticket to the Level 1 Queue and to the assigned Resource Ready to Be Resolved widget. It sets the First Response SLA without pausing the SLA clocks. A Ready to Resolve workflow rule moves the ticket to the level 1 queue without any notifications.
Dispatched – Remote:
Dispatched – Remote indicates to everyone that a Service Call has been scheduled, but the work is being done from the office, not on-site. Which may mean, if the Customer responds to a Waiting Customer ticket, the response from the Tech may be delayed - but they will get to it. It also means you will find the Ticket in the Scheduled Service Calls widget. The Customer will be sent an acknowledgment notification at the time of scheduling with the detailed information and then, if it’s more than 7 days in the future, a reminder will go out 5 business days before the scheduled engagement. This status meets the First Response SLA.
Dispatched – On-Site:
Dispatched – On-Site indicates to everyone that a Service Call has been scheduled, and the work is on-site. Which may mean - if the Customer responds to a Waiting Customer ticket, the response from the Tech will be delayed. Letting the Customer know they are Out-of-Office and when the Customer can expect a response goes a long way to providing a better Customer experience. It also means you will find the Ticket in the Scheduled Service Calls widget. The Customer will be sent an acknowledgment notification at the time of scheduling with the detailed information and then, if it’s more than 7 days in the future, a reminder will go out 5 business days before the scheduled engagement. This status meets the First Response SLA.
Customer Note Added:
Customer Note Added is the trigger to let the Tech know the Customer has responded to the Waiting Customer request for information. The Status change will flag the Open Ticket widget that a Customer has responded to a Waiting Customer ticket. The alert will be both in the My Customer Responded sub-widget for the assigned Tech, and All Customer Responded To sub-widget. A WFR will move the ticket to the top of the Ready to Be Resolved widget. No further notification will be sent, to the Tech or anyone else. The expectation is that someone will see the sub-widget indication and respond the next time they go “Periscope UP.”
In Progress:
In Progress is the indication that the Tech has started or is continuing the engagement. Shortly after changing the status to In Progress, the Tech is expected to call the Customer, let them know what they are engaging on, what information they have available to them, and find out if there is any other information needed to complete the engagement. In Progress meets the Resolution Plan SLA. There are no WFR or Notifications associated with this status change.
rvice Coordinator puts the ticket back In Progress, and adds a note with the required information. No WFRs, Notifications, or wasted time.
On Hold:
On Hold is used only when the Customer is needed for the engagement, they are not available until sometime in the future, and the exact date and time of their availability is unknown. Putting the ticket in status On Hold removes it from the Techs view until the due date is reached, then WFR puts it back In Progress, which moves it to the Ready to Be Resolved widget. When the status is changed to On Hold, the due date is in the past, therefore, the initiating Resource is notified via WFR and an On Hold with Past Due Date notification. A weekly live report is sent to the Service Coordinator, so someone is aware of all the tickets On Hold, and out of view of the Techs.
Escalate:
What happens when someone puts a ticket in status Escalate depends on the culture of the organization.
If the person to which it is to be escalated is known, then WFRs can change the assignment and queue when the status is changed to Escalate. No notifications go out.
If not, WFRs may assign the ticket to the Service Coordinator and move the Ticket into the Triage Queue. No notifications go out.
If the Tech knows who he wants the ticket escalated to, he may add them as a Secondary Resource, add a note as to why they are escalating, what they are expecting, and when the ticket is to be returned to them. Notifications may or may not go out depending on the Company’s SOP.
Note: In all three scenarios, the original Tech should remain the Primary Resource to retain Responsibility, Customer Relationship, and Awareness of where the request is in the engagement process.
Waiting Customer, Waiting Materials, or Waiting Vendor:
All these statuses move the ticket to the Waiting widget. The SLA clock is paused. No WFR or Notifications go out. The Widget is sorted by Last Activity Date. After 3-4 days of inactivity, either the Tech or the Service Coordinator should follow up and see if they can move the request along towards completion. Note: The Waiting Customer notification is sent by the Tech as part of their disengagement process.
Customer Verification Requested:
This is the first of three automated Customer communication processes, giving the Customer an opportunity to verify or request additional engagement time. When the Tech believes the engagement has been completed, they put it in this status. This removes it from view and puts it in an automated Customer communication closing process. The WFR and notification is Customer Verification Requested, and the Resolved SLA is met. Expect no response from the Customer at this stage.
Pending Close:
48 hours after the Customer Verification Requested notification goes out, it is followed up with, “We have not heard from you, so we assume the engagement is complete. If we do not hear from you in 24 hours, we will automatically complete the request.” WFR changes the status and sends out the Pending Closed notification.
Complete:
24 hours later, WFR changes the status to complete and sends the Customer the completion notification “We have not heard from you since our last notification, so we believe this request has been completed, and have closed out the request. If we did this prematurely, please let us know, as we would be happy to reopen and continue the engagement.”
Reopen:
Reopen is not a status but a ticket User Defined Field (UDF). The UDF is a dropdown list of Yes or No. If the status is changed from Complete to any other status, WFR sets the UDF to Yes. Live Reports can track the number of times the tickets are being reopened, along with who completed the request the first time and who reopened it. [su_note note_color="#fffe39" text_color="#0a0808"]To download a spreadsheet of the complete list, along with Widget, SLA Event, SLA clock, Workflow Rule, and notifications information per Status, click here. [/su_note]