3 Things You Must Consider When Automating Your Service Desk

Many organizations already know the benefits of service desk automation – cost savings, improved efficiency and throughput, and increased customer satisfaction are all well documented outcomes of taking the time to automate. If your organization is considering an automation initiative, be sure to honestly assess these three areas before you start.


IT Tooling

Although not essential, the existence of a service catalog is a good indicator that your organization is ready for automation. Having standardized, well understood service offerings shows that your group is equipped to effectively implement automation

Automating the most common service desk interactions is clearly going to be the best place to begin your efforts.

Automating responses to service desk incidents, changes, or requests can be done through scripting or other automation methods; however, IT process automation (or orchestration) solutions are much more scalable and reliable tools to use for this type of automation. Consider whether the automation solution you’re considering has the appropriate adapters or connectivity to be able to integrate with all the systems that are required to automate your service desk process.

Use Cases – Where should you start?

The service desk is usually pretty good about categorizing and reporting on interactions with end users, whether through incidents, changes, or service requests. Look for the top ten most common requests that come in, and determine which of them are good candidates for automation.

For each candidate, assess the complexity of the automation that is required. If it’s an overly complicated process, pick a less complex one and get some early wins before you tackle the more complex items. If you are like most organizations, you will discover that a few (usually about 20%) types of service requests tend to take up the majority (usually about 80%) of your IT teams’ time.

Once you select a use case to automate, make sure you fully understand and document the existing process to handle the use case. It’s important to understand the “before automation” and “after automation” picture, so include information about the time and people that would previously have to be involved with manually handling a use case.

Do you have the right team?

IT process automation products are sophisticated toolsets that are typically owned and managed by IT operations. A different team often owns the service desk. A successful service desk automation project requires good cooperation and coordination between the service desk and IT operations teams.

The following people typically need to be involved with each automated process:

  • The service desk owner responsible for defining service offerings and understands the processes that need to be automated
  • The technical owner/expert who can administer and configure the service desk solution
  • The IT operations team that owns the IT process automation tool
  • The expert who understands how to configure and administer the IT process automation tool and can write the required workflows
  • Experts in any technical systems or applications that will interact with the IT process automation tool

Only with a team of people with the required knowledge and good level of collaboration will service desk automation projects be successful.

While most of the items I mentioned above are considered common sense, many automation efforts run into trouble mid-project due to overlooking one or more of these basic steps. Time spent walking through these three categories ahead of time can be the key to a smooth and successful automation project.


Service Desk Automation for the Digital Enterprise

Atrium Orchestrator provides end-to-end IT process automation across your entire service management environment.

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

Share This Post

Anthony Bryce

Anthony Bryce

Anthony has 20 years of experience in the IT Service Management space working in a variety of roles from software consultant to solutions architect. For the last 10 years, he has been focused on product management and marketing, working on strategic projects, delivering detailed market analysis, and identifying new product opportunities and bringing them to market.