Why do Services come before ticket type?

[mikehibbert]

With an ITSM tool, you would usually expect follow roughly this process to log a ticket;

• Choose whether you're logging an incident/change/problem/etc.
• Associate this ticket to the relevant service

This means you have a homepage with perhaps a button for each ticket type.

However, Hornbill seems to force you down this route to a log a ticket;

• Find which service you think might be affected by incident/change/problem/etc.
• Choose a request catalogue item within that service that is relevant depending whether it is an incident/change/problem/etc.

The "Hornbill way" leads to a more cluttered first screen (you need to display all of your services) and seems at odds with other tools I have used. I was just wondering why this is and if there is any plan to change it?

[James Ainsworth]

Hi Mike,

Are you referring to the experience an end user may have using the Service Portal?  You mention Problem records which isn't presented on the Service Portals so I wasn't sure exactly if it was the end user or the support person's experience that you are referring to.

Starting with a Service does help narrow down information for either the end user or support person.  Similar to an internet/media provider where you may have purchased services for Internet, TV, phone, they would tend to start by presenting these services to the customer when they visit their account page.   Services should be fairly high level items, with the Request Catalog that sits under them take up detailed areas where requests need to be raised.  We don't present request types to end users.  While support staff may be knowledgeable in ITIL terms, it may not mean much to an end user.  The end user is just presented with Request Catalog Items, of which you can call Incident or Request, or Change if you do want  them named in this way. 

Did you mange to see the webinar today on the new Employee Portal?

[mikehibbert]

Hi James,

Sorry for taking a while to get back to you.

Yes I was referring to the Service Portal. Apologies, I must have started typing ticket types and continued onto Problems without thinking!

To me, it just feels a bit counter-intuitive. As a worked example, we are currently re-designing our Service Catalogue (in the ITIL sense of the word "service") and will probably end up with 15 - 20 services. For incidents, in particular, it seems inefficient to have 20 services displayed on the portal, with each one having an incident request catalogue entry underneath it. Wouldn't it be easier to have one big "Something's wrong, help!" button on the Service Portal and then as part of the BPM it is linked to the relevant service? 

As a workaround at the moment we have a "Whats not working?" service, which is then linked to the service that is impact. However, that in itself causes a bit of a reporting headache as some ticket types are logged directly against a service and others are linked to a service.

Thanks,

Mike

 

[James Ainsworth]

Hi Mike,

With having 15 to 20 services as your goal, it sounds like you are right on track.   Providing too many choices to a user can end up not knowing which to select.

Behind the raising of any request we have two main components; the progressive capture and the business process.  Unique progressive captures and business processes can be applied to each service and the Request Catalog Items that sit under them.   A single button for ''Something's wrong'' may limit the questions that you can ask the user.  An HR service and an IT service are going to be asking very different things.  It may also be that these two services are being managed separately by different teams or departments.  Having a single starting point may not allow for the needed separation that these two departments work with.  I would also suspect that in progressive capture, if you didn't start with a Service, you would have to select the service in the first few questions so that the appropriate questions can be asked.

Your workaround in my opinion is not a workaround, but rather a very valid way of working.  There are many situations where a high level list of services are not required.  It might simply be that an organisation provides IT support and that is the only service that they need, and under that service the appropriate Request Catalog can be created that could contain just ''Something is broken'' or ''I need something'' type requests, or it could be a detailed request catalog with many other predefined requests.  

We are trying to approach this from a Service Catalog perspective, and the starting point for this is to list the services that the user is subscribed to and from there the user can select the service and see a list of requests that they can raise which related to that service. 

[mikehibbert]

Absolutely I take your point regarding HR and IT services requiring different questions. In this context I am talking purely about IT services. Perhaps what I deemed a workaround is a valid way of working after all in that case!