Option 1: Forward emails

Simply forwarding emails to your ServiceNow email address may be the simplest option but ServiceNow will receive the email as sent from the person that forwarded it.

This means the original sender for the ticket will not be recorded as the caller of the ticket and will not receive a notification about it until a Servicedesk agent modifies the ticket and provides an update.

Option 2: Redirect emails

Unlike forwarding , with mailbox redirection emails are automatically transferred as-is from one email mailbox to another.

Mailbox redirection can be set by your email administrator and doesn’t require sharing of passwords nor any change in ServiceNow. Here is how it works:

1. End-users send support emails to your official support email address (e.g. [email protected]).

2. Your email server receives the emails sent to the helpdesk and redirects them to your ServiceNow’s instance email.

3. ServiceNow receives the emails sent from the end users as if they were sent directly to ServiceNow and creates new tickets on behalf of the senders.

This simple solution strikes through most requirements, letting you leverage the benefits of using ServiceNow’s built-in instance email and also not change the email address that you have communicated to your end users. You can also:

• Configure your mailbox to keep a backup copy of each email received before redirecting it to ServiceNow;

• Set up filters in your mailbox so that emails that match certain conditions are not redirected to ServiceNow.

Also, if you have more than one support email addresses that you would like to receive as tickets in ServiceNow (e.g., [email protected] and [email protected]) you can set up mailbox redirection on them also so that they too automatically redirect all incoming emails to ServiceNow.

At Al Jazeera, the teams in New York, London, and Instanbul had their mailboxes automatically redirected to ServiceNow as described above. For the Servicedesk team in Doha however we had to devise another setup.

Option 3: Drag and drop emails

Despite the possibility of filtering out emails with specific filters both in your email mailbox and in ServiceNow some teams resist the idea of having all their emails automatically redirected to ServiceNow.

They want to manually pick which emails end up in ServiceNow and which to keep in their inbox. Once they decide that a certain email should become a ticket in ServiceNow you can have the ticket automatically created in ServiceNow by simply moving the email to a folder in their mailbox dedicated to ServiceNow. Here is how it works:

1. Create a new email address (e.g., [email protected]) and on it set up automatic mailbox redirection as described in Option 2.

2. Make the mailbox visible with write-only access and add it as an additional mailbox for your team.

3. To create a ticket in ServiceNow from a received email drag and drop the email into the additional mailbox in your email client.

4. Once dropped into the mailbox it will be immediately redirected to ServiceNow and a ticket will be created.

Unlike forwarding emails (Option 1) moving emails to the mail folder that redirects email to ServiceNow will preserve the email headers and so ServiceNow will log the ticket as if it were sent from the caller directly.

Option 4: Manually log tickets in ServiceNow

If none of the above options work for your Servicedesk they are basically left to logging tickets on their own in ServiceNow. But then there is the risk that tickets are not logged in at all because of the additional manual labor involved in logging.

As so many ITSM champions will testify many teams start out excited about adopting the best service management practices and using ServiceNow only for that initial enthusiasm to fade away with time and people sticking with what they are already used to.

Having emails automatically redirected for them can be critical to ensure sustained commitment to using ServiceNow.

Loggging tickets manually about received emails also introduces human error where information and attachments in the received email are lost in translation and are not included in the ticket opened. Tickets may also be logged some time later.

At Al Jazeera most teams have their support email addresses automatically redirect emails to ServiceNow (Option 2) while the Servicedesk in Doha logs tickets manually (Option 4) or uses the drag and drop option (Option 3).

An increasing number of end users now also log tickets through the portal (Chapter 6) but it would be an overstatement to say that many do it.

Reply chains

When receiving an email reply ServiceNow attempts to extract the reply part leaving out the email trail. But this may not work with your email client especially if dealing with international customers and does not work with legal disclaimers often appended to corporate emails.

If not dealt with, your ticket message details become easily unreadable and practically threaten the adoption of ServiceNow. It just becomes too ugly to deal with the ticket both over email and in the ticket itself.

To deal with this, ServiceNow lets you define what text, if found, will be cropped in an incoming email reply. You can add your disclaimer in there as well as the reply separators used in the emails that you receive. By default, ServiceNow looks for the following text strings:

-----Original Message-----

_____

From:

You may have also noticed that in the emails that you receive from the customer service of online websites you will often see that they start with something like:

## In replies all text above this line is added to the ticket ##

They do this so that they can always crop email replies to their tickets regardless of the email client or language of the customer. You may be in a situation where such a solution suits you as well.

At Al Jazeera we have an automatic email signature (Figure 4-1) and legal disclaimer appended to every email sent, and in ServiceNow we crop email chains from the signature onwards.

Figure 4-1. Email signature and disclaimer automatically appended to outgoing emails from Al Jazeera.

Reply duplicates

As tickets started to pour in automatically in ServiceNow from emails sent by unassuming colleagues all over the channel at Al Jazeera we soon observed an issue: people were receiving duplicate copies of the same ticket. It seemed like every new email reply received spawned a new ticket instead of updating the first one.

Upon investigation we realized what the issue was: Reply all. Reply-alls to the original email that was sent to ServiceNow triggered new tickets. Here is how it can happen for you as well:

1. The service desk email address redirects to ServiceNow automatically.

2. Carla emails the service desk and her line manager Imad with a support request.

3. ServiceNow automatically opens a ticket for Carla’s email and emails her a receipt notice.

4. Imad replies to Carla’s email and to the service desk (reply all).

5. ServiceNow receives Imad’s email. Eventhough the email is a reply there is no ticket number mentioned in the email and so ServiceNow opens a new ticket for Imad.

6. The issue repeats with each reply to the service desk email address but doesn’t have a ticket number in the email trail.

So unless the email is a reply to a ServiceNow notification the email will be processed in ServiceNow as a new Incident ticket generating many confusing duplicate tickets and notifications.

From a system perspective it makes sense. How could ServiceNow tell if the new email is a reply to an existing ticket or a new ticket if there is no ticket number in it?

To deal with the issue you could go in either of these two directions:

1. Ignore email replies that don’t contain a ticket number. This way Imad’s message would be received by Carla but wouldn’t reflect in ServiceNow and won’t trigger any duplicate email.

2. Attempt to match email subject lines with the short description of open tickets.

Ignoring the email reply may not be sensible unless you also include a mechanism for the service desk to review those ignored email replies (there may be an approval or instruction for the service desk). You could tie this in with the Feedback list mentioned later in this chapter.

You could also send an auto-reply to Imad alerting him that because he replied to an email without a ticket number the email was ignored and invite him to email again in a new email instead if he wants to communicate with the service desk. But that’s just too cumbersome and confusing, isn’t it?

At Al Jazeera we went with the second option so that even email replies that don’t contain a ticket number will update the most recent open ticket as long as the following conditions match:

1. The ticket has the same short description as the subject line of the email reply (after trimming reply prefixes and trailining spaces).

2. The sender of the email or at least one of the people to whom the email is also sent is also in the ticket’s watch list. In other words, the email and the ticket have at least one person in common.

3. If there is more than one ticket matching the above criteria, update the most recently updated open ticket.

This solution only comes into play after ServiceNow's default workflow gives up on processing the incoming email as a ticket update. So it doesn’t impact the reply’s processing logic. It does however place itself before the logic for creating new incidents .

If you also implement this, carefully test the creation of new incidents from email and monitor that no reply ends up matching wrong tickets.

This procedure has been in place at Al Jazeera for years and works as expected. It doesn't solve the issue entirely, especially when email groups are involved and so a common denominator is not found (second condition). But for most cases updating the right ticket instead of creating new tickets works. When it fails it creates a new ticket, which would have happened anyway.

To be sure that emails are not incorrectly matched with other tickets that have the same subject line (e.g., “I need help”), you could also either:

• Record the first short description set for a ticket in a hidden field so that even if the service desk changes the short description of the ticket, the matching will occur against the original subject line the ticket was created with. We do this at Al Jazeera.

• Make a ticket’s short description unchangeable. As it was received so it remains.

Missed replies

When a new ticket is received ServiceNow will trigger a notification about the new ticket (see Chapter 5) but until the ticket is assigned to someone any further update by the caller will not trigger any notification to anyone. The customer updates will be silently posted to the ticket with no one alerted.

This may be ideal in theory, assuming teams regularly check their tickets queue and process each ticket in it diligently. In practice however it can lead to certain ticket updates being missed for some time and growing customer dissatisfaction .

This is even more so in the beginning when teams may have officially been on-boarded to ServiceNow but in reality they still have not entirely shifted their workflows. In such cases it is even more likely that unless new email notifications are received tickets will remain neglected in ServiceNow.

To avoid this situation at least as teams get accustomed to checking and processing tickets in ServiceNow you may establish that every new ticket update made by a customer is in turn delivered to someone to take care of.

At Al Jazeera, until the ticket is assigned to an individual new customer updates are shared with the entire assignment group of the ticket. This is to prompt someone from the team to assign the ticket and reply to the customer.

I've also been told of other ServiceNow customers that instead of delivering the customer update to the to the entire group they deliver it to the group's manager .

Thank you issue

When our central Servicedesk at Al Jazeera shifted to ServiceNow a funny and totally unexpected issue got continuously reported and came to be known as the “thank you issue ”!

As said above if a customer writes an update to a ticket a notification would only be delivered to the assignee.

But in many cases the assigneen would have left for the shift and so the only way to know about the update would be an angry call from the customer wondering why it is taking so long to process her update normally to a marked-resolved ticket .

So the following workflow was introduced:

1. Email replies to resolved tickets are shown as feedback in a special home page gauge visible to the service desk.

2. The service desk reviews the latest customer message on the ticket and based on it either:

   • Re-opens the ticket and resets the assignment as appropriate in the current shift or

   • Marks the ticket’s feedback as noted to clear it from the list.

This feedback list on the ServiceNow home page (Figure 4-2) made sure our service desk was on top of all ticket replies to closed tickets from customer, regardless of the team the ticket was assigned to.

Figure 4-2. Feedback list on the service desk home page shows resolved tickets to which new comments have been added.

This allowed the service desk to help ensure appropriate action is taken to all customer messages.

As a side note, the reason this became known as the Thank you issue was because we had set every reply to a closed ticket to automatically re-open the ticket and also re-assign it to the service desk, who in turn would assign the ticket after checking the availability and load of support teams on shift.

In the beginning the Servicedesk was the only team fully-vested in ServiceNow and so to maintain operational fluency additional oversight was needed from service desk over the tickets assigned to other teams.

But this soon led to the issue that came to be known as the Thank you issue. So many times customers would reply to the closure notification, re-opening the ticket with “Thank you”! It would happen like this:

• Service desk writes a message and resolves the ticket.

• Caller and others in the watch list receive the notification.

• Caller replies to the received message with “Thank you.”

• The ticket is automatically re-opened with the received message.

• In order to close the ticket the service desk has to write another message.

• Prompted by the caller’s thank you, others in the watch list also post their thank you reply, again re-opening the ticket!

This funny situation kept on happening so often until we introduced the feedback list solution described above.

Internal replies

ServiceNow by default processes email replies to ticket notifications and posts all of them to the user-visible ticket comments. This in turn triggers the appropriate notifications for the agents or the end users (depending on who wrote the update).

But this processes also applies to email replies to internal notifications such as Assigned to me and Assigned to your group.

To avoid internal recipients from replying to those emails with internal replies (like “Why did I get this assigned?”) you could include a warning in the email notifications clarifying that replies will be sent to the caller directly (not to the person that just made the assignment).

Alternatively you may want to enable an internal communication thread for each ticket. As such email replies to assignment emails are posted to the ticket’s work notes and are not customer-visible . This is discussed in context in Chapter 10.