Jay Rollins continues his help desk implementation saga. This week the goal was to get all the service levels and business rules implemented.


This week’s goal was to get all of the service levels and business rules implemented in both systems to see how easy or difficult it is.

Prior to spending a lot more time with both the Numara Footprints product and the Manage Engine Service Desk Plus product, we started getting pricing information. We found that there was a significant difference in price. The Numara Track-it application, which is the company’s entry-level product, was comparable to the enterprise (premium) version of Service Desk Plus with the Ops Manager monitoring plug-in package. Add the Numara Footprints package with all the ITIL bells and whistles and it more closely compares with the version of Service Desk Plus we tested but with a 3x price difference.

Given the price difference, we felt we could deal with the following in the Manage Engine product:

  1. The lack of many of the refinements that Footprints has from a user interface standpoint
  2. The lack of ITIL certification and the robust ITIL features and functions that Footprints has
  3. The lack of US-based support

Our rationale:

  • Although the interface wasn’t as intuitive, once you get used to playing with it, it grows on you and it doesn’t take that long to explore and understand all the features
  • The main focus for ITIL that we wanted to capture was the ability to transition a “Request” to a “Problem” and create tasks and time lines that are outside of Request SLAs
  • The support, although not US-based, was high quality. The support staff answered questions and were very helpful and stayed with us until the problem was resolved.
  • Price

Most other features, although maybe slightly less advanced, were comparable. So, with the decision made, we started inputting the data and setting up the rules. Last week we established the priority levels and the response plans for each level. This week, we started entering them into the Service Desk application. One of the things we had to figure out was how to address the various service levels. Service Desk has two options for SLA measurement. You are either 24×7 or you are some combination, but you can’t do both.

What we wanted to do was setup a M-F 8 a.m. to 5 p.m. operating time and a 24×7 on call. Setting these SLAs in Service Desk affects the request priorities. Basically, Level 1 and Level 2 issues are 24×7 and the rest are typically normal business day. In essence, if we set the operating hours to 24×7, then the four-hour SLA we have for Level 3 tickets, the clock starts ticking no matter what time the ticket gets entered. If we set the operating hours to 8×5, then the Level 1 and Level 2 tickets won’t escalate until the next business day.

We are working with support on this issue to see how the various business rules interact or cascade. Which ones take priority? The organization operating hours or the priority business rules?

Additionally, we tweaked our requirements for Level 3 requests. We needed to address the fact that communication regarding the ticket may cause us to blow the SLA for Level 3. We have historical information that a user may get back to us a day or two later, so we decided to add an interim step in the process. If we believe the issue has been resolved, but the user has not verified, we set the issue status to “Resolved” instead of closed.

Additionally, if the issue requires communication to get resolved, placing the ticket “On Hold” will stop the SLA clock. We then want to set up a business rule that if the user replies to the ticket, the status automatically changes back to “Opened” and starts the SLA clock again. We also trying to figure out how we can execute this business rule. I’ll update on this next week.

Aside from these issues, we have a few extra items that need to be done. Next week we will begin outlining mini-projects to get these accomplished. The items are:

  1. Refining “Request” to “Problem” process. The product is pretty flexible here, but we need to figure out the best way to transition requests into problems without adding a lot of overhead, but at the same time have the ability to track problem progress.
  2. Identifying monitoring best practices for our various systems. We know what we have, but what do we need from an alert standpoint to be proactive. We are looking for help from our data center service provider, our networking partner, and the Manage Engine OpsManager product. I would rather outsource to one of our partners that has a 24×7 NOC and expertise in monitoring versus doing it ourselves, so we have some evaluation tasks to perform regarding monitoring services. Update next week.
  3. Creating Standard Operating Procedures for Level 1 and Level 2 issues. This includes generating documentation, checklists, etc and incorporating them into the help desk knowledge base.
  4. Start looking at Change Management features in the application. Once we get the basics up and running, we want to start adding change management processes to the help desk and tie those change approvals to maintenance tasks within our maintenance window.
  5. Asset management review. We have been gathering inventory information and started adding the systems and software data to the service desk application. We need to review this and see how best to connect it to inbound requests.
  6. Contracts: We started using this feature this week. Very nice. We add out contracts to the system in PDF plus a little bit of metadata to include expiration dates. You can set alerts up to 90 days on contracts coming to an end. This is very helpful in preventing website issues from happening when your SSL certificate expires or preventing an automatic roll-over where you have the potential to renegotiate better terms.

There are a few others, but these are the big ones we’ll be focusing on over the next few weeks.