Revamping our Self Service Portal - our challenges and looking for advice

[samwoo]

Hi everyone,

We are currently looking at revamping our Self Service Portal, and one of the ideas that is currently gaining traction is to have a Catalog approach... but I don't mean in the way we have it currently set up:

Quote

Services
| _ _ _ Catalogs
| _ _ _ _ _ _ Progressive Capture

More like...

Quote

Request Type
| _ _ _Services
| _ _ _ _ _ _ Catalogs
| _ _ _ _ _ _ _ _ _ Progressive Capture

The goal is to declutter the IT Portal and group things based on whether they are Incidents or Service Requests.

So this is a high level of what looking for the following (please ignore the colours):
(For some reason the Hornbill forums is not allowing me to upload this image, which is 163kb. I get an error -200)

Quote

At the end of the meeting I explained that in order to use the system as it is at the moment with the idea they are aiming for, we would have to create the following Services
(in effect changing the Portal to be from 27 approx services to just 2 services):
1. Incidents
2. Service Requests

Following this the Catalogs will be under the above Services (there are some more to be discussed):
1. Applications / Software (SR / IN)
2. New Starter / Movers / Leavers (SR)
3. IT Equipment

Following the Catalogs there will be Progressive Captures with Dynamic Questions where applicable.

This is not ideal in their eyes.. and i've said if they want it in the way they actually envisioned it, we would either...
1. Need to have "Sub Catalogs" which is something that is not possible
2. Have the first screen of the Portal show the two Request Types which is also not possible.

I have also explained that we can use Service Categories but the business and the BA's do not find it very user friendly at all.

@Hornbill:
I would like to request the following:
1. Have a request type (toggleable for other Hornbill sites) page that appears before the list of services, which will filter the list of Services based on whether there are any SR or IN Catalogs active.
2. Ability to define Sub Catalogs within Catalogs.
3. Tabbed Service Categories instead of a dropdown
4. Or even better, instead of Tabbed Service Categories - the ability to filter the Portal by having Request Types as tabs.

We are happy to have a chat with one of your developers if you need to understand what we are looking for.

@All:
We would like to understand how others have come up with their Self Service Portal, what challenges you had to overcome and how their users have found it? If it helps we are currently using the Self Service Portal as it is designed in the way Hornbill presents it (Service Categories, Services, Catalogs and Progressive Capture) but it is under constant criticism as there are far too many Services on the main screen. We cannot use the Subscribers functinoality since all these Services are used by everyone.

We are happy to have a chat about your experience, and would be extremely grateful if you are able to show us what your portal looks like.

Thanks,

Samuel

(I used the quotes to break up the text above)

 

[samwoo]

Hi again,

Silly me I put this thread in the wrong part of the forum - should be in Collaboration.

Anyway I have finally been able to upload the image I wanted to upload earlier. The colours were added be myself for visual clarity.

Thanks,

Samuel

[Dan Munns]

We are trying to move away from the 'is it a request or an incident' and more into a 'what do you need'. All SD functions come down to what the user needs to do. They don't care that Outlook keeps crashing, they need to send an email. They don't care that you have to install a software package, they need to open a file. They don't care that you have to build them a laptop, they need to work remotely. 

So I am trying to push to have services like 'Finance' or 'IT' or 'Marketing' with all related CIs under that banner, no matter if it is an incident or a service request.

Again, the end user doesn't care if it is an IN or SR ticket. They just need something. Breaking down the catalog into Incident or Service Request may well make it seem more difficult to log a ticket and you find that people just call the desk (which I assume you don't want to happen).

At the moment we are kind of half way there. We have services called Finance Requests, Marketing Requests, IT Requests etc and the CIs within can be SR, IN or CH. The customer doesn't know which they are raising until they get the reference number in the confirmation email and I doubt they much care or even notice the prefixes change. 

We still have a way to go though.

I am also a great believer in minimising the amount of CIs where possible and would have an IT Request CI which presented the user with one form which, using the dynamic form options, allowed them to raise any CI request under the service (so they select the CI of 'Make an IT Request' or similar and then they fill out one form, which changes depending on the answers they provide, and then logs to correct request type, rather than have them select a specific CI for shared folder access for example) but I think we are quite a way from that (if they get there at all).

Try and have the request type set automatically based on what the user needs. Obviously you will have a CI for 'This doesn't work' rather than individual ones for each possible incident type, but for SRs and CH (if applicable) the CI should be dependant on what the end user is asking for. 

Service requests are just really low level pre approved changes so anything which involves a change to a users account or hardware would be an SR so make all the  requests of that type SRs. It doesnt matter if they are mixed in with the INs in the portal. The user wont see it and wont care and you can split them out in the SM view anyway. 

I have probably repeated myself a few times but I am currenly functioning on about 2 hours sleep and lots of coffee  

Edited March 20, 2019 by Dan Munns
Caffeine fuelled spelling...

[Dan Munns]

Maybe something like this would be the ideal (for me at least): 

[samwoo]

Hi @Dan MunnsMunns,

That is really helpful and insightful thank you for taking the time to respond. I will have a look properly in more detail when I get to my laptop at work.

Re. Our vision and your diagram they look very similar. I can imagine there will be challenges to overcome as one would have to likely have to configure a single Catalog BPM to cater for multiple different scenarios and that is a big piece of work in itself.

Do you have different things showing in the portal (what you are doing at the moment) to what you might have showing in Service Manager for your analysts?

Thanks,

Samuel

[Dan Munns]

@samwoo the service list on the portal and the list the analysts see are completely different to be fair. 

Obviously the internal guys have additional options when logging certain request types (they can select NT as an option for password resets for example, where as a user can't) but they also have access to log requests against services reserved for internal teams. 

Overall I think from a user perspective, the options need to be limited, but self explanatory. And moving away from 'IT speak' is the best way to do that. And if you think of everything in the terms of 'what do you need' rather than 'we do we have to do' you will go a long way to achieving what are setting out to do (assuming that you get the buy in from the relevant business owners)

I think a lot of IT people expect that users will know that an incident means something isn't working for example, as it is a common term within the IT world. However, as a business we have multiple incident processes and the definition varies depending on the business unit. Also, quite a lot of our users only ever use a computer at work. The closest they will get in their personal lives will be their mobile phone, which is designed to be as easy to navigate as possible. And whilst the 'younger generation' are obviously a lot more tech savvy than my parents for example, it is all subjective. Knowing how to configure an email app on an iPad or install an application on a laptop doesn't mean that they will understand any of the jargon around server configuration or service management terminology straight out of the ITIL handbook. 

So, stick to a small number of well designed services that will guide the user into providing the info you need to do the job and not have to worry about the back of house stuff. Add explanations to the ProCap, with images where needed, to remove any risk of confusion. This should enable you to correctly categorise and assign the requests automatically based on the answers given by the user and should make every ones lives a little easier, which is what its all about. 

[Daniel Dekel]

@samwoo, @Dan Munns,

We are doing great changes around the catalog area, in a few months you will find out.

I believe what you are looking for will be available within these changes.

 I suggest you to come to our next INSIGHTS event to hear it first ;-)

Daniel.

[Dan Munns]

@Daniel Dekel already booked with the overnight stay. See you there!