One thing I love about my job is that I am constantly challenged by ideas from customers and different types of projects. One such example came from a customer who wanted to deflect tickets originating from user emails more effectively.
The Stock MSFT Exchange Connector works very well when you want to create tickets based solely on the subject and body of an email. It gets tricky when you want to do anything beyond that. How do you know if it is an incident? How do you know if it is a service request? Can we route the ticket based on information in the email? My scenario was a little different than these, but it uses the same solution: the SMLets Exchange Connector.
This is an open-source solution that was created by our very own Adam Dyzacky, product manager at Cireson. If you haven’t checked it out yet, I highly recommend visiting the site and reading the capabilities summary. There are a TON of really cool things you can do with this. Honestly, I had heard about this solution for several years, but I hadn’t read up on it (no offense Adam!). I just didn’t have projects that required this level of email processing functionality.
Where to start
I needed a way to respond to a user’s inbound email with relevant offerings and/or knowledge articles. There is built-in functionality that can do this in the SMLets Exchange Connector, but it is an all or nothing approach. My requirement needed a few tweaks. The brains of the SMLets Exchange Connector, written in PowerShell, contain empty functions that trigger based on certain points in inbound email processing. There are multiple stages where you can place your own logic. Here are just a few:
In my case, I added logic within the Invoke-AfterCreateAnyWorkItem function. To keep this at a high-level and in summary: we get an email with a subject and body. We look at all the words and phrases in the email to see if they match up to any request offerings or knowledge articles. You can set which offerings and knowledge articles are analyzed, which keywords to look for and how many word matches need to occur to qualify for a suggested response.
Example 1: Password Reset User Request
A business user is sending an email to the service desk to reset their password.
Password Reset Response
This response contains a knowledge article that highlights your AD Password Policy and a link to an offering that allows them to reset their AD Password.
Example 2: Printer Problem User Request
A business user is having issues with their printer.
Printer Problem Response
This response contains a link to some common printer troubleshooting steps.
The Best Action Plan: Self-Service
I see many organizations caught in this circular challenge: email gives users an easy way to contact the service desk, but it opens the door to noise and unnecessary tickets. If we turned the above solution on across all knowledge articles and request offerings, you would quickly see that you bit off more than you can chew. Users would get too many emails with suggested items that might not be relevant or make sense. What happens then? Over time, users lose trust and ignore your suggestions.
What can you do?
The goal is to drive users toward self-service to gain trust. Start by targeting your most common requests. The approach we walked through above allows you to slowly and strategically guide users in that direction.
You can pick up additional tips and tricks in the Cireson Community and during our Community Open Floor meetups.
