General basic questions for new Service Management user

Em16
Kilo Explorer

Hello,

First post and a very new user. Using ServiceManagementSuite - Production.
This is a series of general basic questions. Unsure if I'm in the correct Forum/Topic.
Company is starting to integrate ServiceNow but we are having some difficulty with the employees (team assigned to learn + train is small):

What can we do to resolve the following, besides "more training?"
Are there paths that we can implement?

 

Any and all tips and suggestions are welcome!

 

1. Incidents raised without proper templates and consumers group leading to incorrect distribution of incidents within the group.
Users don't provide proper input so there are also multiple reassignments going back and forth. Want to create a permanent fix to bring down the INCs per day.

2. Permanent fixes tracking for every data quality issue, tactical scripts, etc.
Currently keeping track of all incidents and Root Cause Analysis being worked on. Is there a cleaner way to keep track of it all? I saw some posts on Aging Incidents but don't think that's what I need.

3. Incidents with insufficient information.
Lots of Incorrect Posting (largely due to Missing Data from Source)

4. Email follow ups.
Users using email as follow up instead of using ServiceNow updates.

5. User education related incidents.
Is there a way we can measure last year vs this year and establish a target? Want to use percentage instead of volume.

 

Thank You!

1 REPLY 1

johnfeist
Mega Sage
Mega Sage

Hi Em,

Here are my suggestions:

  1. If you are having users creating incidents via a record producer(s) you need to consider creating one "super item" that has sufficient intelligence to capture what you need for creating your incidents.  If you give the user options around "what kind of incident" a certain percentage will always get it wrong.  You also need to consider how much information you need to properly route an incident.
  2. We track things like this via the values in the Closure Information tab.  These should be entered by your fulfillers so you have a higher probability of getting accurate data.  You might need to add a field or two or adjust the OOTB values in the existing items.
  3. This relates back to your item 1.  If you accept an incident where all the information being entered via a record producer is "my computer is broken", you need to consider what you accept as free text and what needs to be structured data.  While we all wish our end users understood that the better the information they give us the faster we can resolve their issue, many don't or can't be bothered.
  4. You are limited here.  I know that some very large organizations don't accept emails in these contexts.  You might also look at your inbound actions.  Replies to emails from ServiceNow should automatically be attached to the "sending" ServiceNow object.  From there, a notification can be sent to the assigned to or assignment group. We don't expose the assignee on a given incident specifically to avoid end users going directly to that person.  When we first started, I had to add some inbound actions to handle cases where there is something like Incident INC0000001 in the subject.  I believe that is now handled OOTB.  Your only other alternative is to capture as many of the "offending" emails in a mailbox that will send back a reply saying "you've sent mail to an unattended mailbox.  If you are asking a question about an existing incident please go to the service portal"  or similar.
  5. If you are looking to see how many incidents were cases that required user education, the best place would be in the closure information mentioned in item 2 or in the categorization structure for the incident.

These are some thoughts based on our experience.  Every organization is different so some of the above may not work for you.

Hope that helps.

:{)

Helpful and Correct tags are appreciated and help others to find information faster

Hope that helps.

:{)

Helpful and Correct tags are appreciated and help others to find information faster