When I started with my company in 2017, we had a two-person service desk, and we were using a low-cost incident logging system. Trying to pull any trending data out of it was nearly impossible. We knew that it would not scale with our aggressive growth strategy.
We set out to find a more flexible and scalable solution, which we introduced in 2018. After bringing in a third-party company to assist with its setup and launch, all work was transitioned to our internal Application Development team for additional enhancements and maintenance.
In our company, nearly every department (HR, Payroll, Accounting and more) now uses the ITSM solution for restaurants to contact them for assistance. This provides a one-stop shop for our restaurants to communicate with the corporate office, provides better accountability to the corporate teams to make sure that nothing is missed (they used to use shared departmental mailboxes) and provides transparency for the restaurants as they can see the status of each of their “tickets” at any time using the service portal.
Unfortunately, with so many different groups using the same system, this also created a huge development/enhancement backlog that continues to this day. Many of the efficiencies I’m trying to gain through the new system haven’t been realized.
Here are some of my top requests:
- Direct integrations to commonly used vendors: We communicate with many of our IT vendors by either logging incidents in their portal or via e-mail back and forth. This adds greatly to incident handle time and tends to cause confusion, especially with email sent to them direct from the agent’s email if the incident is ever reassigned on our end. I visualize a section on our incident form that will allow us to initially send over details to a vendor that will immediately open a request in their system and return that request number to us. Thereafter, updates from either side are captured in both systems. Once complete, the vendor closes out their request and the incident stays open on our end, pending customer verification of resolution. Another benefit of this arrangement is that the complete lifecycle of the incident is captured in one place.
- Measuring Incident Handle Time: I want to measure the minutes that an agent is actually working on an incident (not the amount of time that it is open). I don’t want to rush agents through incidents, so I’m not as concerned at measuring this on an individual level as I am at the group level. So many efficiency improvements that I want to implement are tied to reducing Incident Handle Time, allowing the team to work more incidents in the same amount of time. I need to be able to successfully measure the “before” and “after” changes are implemented to be able to justify continued application development on overall efficiency initiatives.
- Putting contact information for all users into the ITSM tool: Whether we need to find a restaurant’s phone number or an area director, we have to search through multiple different systems to find information we need, leading to unnecessary extra handle time.
- An orchestration tool: Some of our incidents involve resetting a service on a POS terminal or server. To do that now, we have to remote into the system, switch over onto the Administrator profile, launch the Services window, locate the service and restart it. Then, we have to switch back to the restaurant’s profile before we disconnect. A better way to operate would be to leverage an orchestration tool to just execute a batch file to reset the service. The difference in handle time can be as much as five minutes per incident. Multiply that by the number of incidents where we do this each week, and we anticipate gaining back hours of productivity.
- Re-working our Configuration Management Database: Pulling data out of our ITSM solution should be just as important as putting it in. When we launched our new system in 2018, we used generic classifications for hardware (not a great idea). This has made it difficult to pinpoint hardware failures by serial number or even model number. As a result, making decisions on when to replace hardware is made difficult because we don’t have detailed failure data available for use. This will be a huge undertaking once we’re ready to explore it.
- Improved reporting: We report on key metrics to leadership in each of the restaurant brands that we support on a monthly basis. From looking at incident volume, top callers, top incidents, SLA attainment, we provide a detailed performance recap to the C-suite. However, the process of putting this reporting together takes like 20+ hours per month as the ITSM system reporting capabilities are limited out of the box. If we could streamline it, we can shave hours off of this task and we could potentially look at trends each week and react more quickly, if things are not going well. My plan is to export the data into a true reporting system so data can be better analyzed.
Whether your service desk is in the same situation as mine or is running perfectly, there are likely opportunities for gaining efficiency if you know where to look.
My recommendations:
- Challenge your agents to list out processes that are holding them back from success. Involving them in the change process now will more likely achieve buy-in later.
- Spend time either taking calls yourself or sitting behind your staff. Look for unnecessary keystrokes, rapid switching between multiple screens and programs and how and when agents collaborate with each other. Examine how escalations occur both within and outside of your ITSM.