I’m in the process of revamping the service catalog, but looking for ideas of what others might have out there…. How granular do you get when creating service items?
Ours is pretty high level, so sometimes requesters use the wrong ticket for the wrong things. I know that we will never be able to 100% fix this problem, but the goal would be to make it easy for users to look at the service catalog and know exactly which ticket type they needed and, on top of that, provide all the information we (IT) need on the backend so as to limit the back and forth.
Would anyone be willing to share screenshots of what they have in their service catalog or any thoughts/advice?
Thanks in advance!
I think avoiding granularity is a good instinct - we also strive to keep things simple. A few ways we have achieved this in our Service Catalogue:
Catch all Service Item that lets them select the corresponding agent group and a free text field for subject and description. Nice way to filter non-standard requests and assess whether they warrant their own service item. Nice to have the ticket default to ‘Type: Service Request” for adding items and approvals when required.
Business Rules for Forms
When you do need to capture specific information from the end user, I would always recommend using business rules to create a guided experience. Simply hiding fields until earlier relevant fields are populated should make the form less daunting and prevent users from trying to circumvent filling it out.
Bundle Items & Portal Customization
We use the option to bundle items in some of our forms such as New User, Additional Hardware & Software. This helps to keep things tidy and we like to contain these to the one ticket for simplicity as well. We found that the FreshService default of exposing all active service items in the portal does not work for us, however. We have put majority of our Service Items in another category and then hid the folders in the portal. We show 9 Service Items to our end users and hide the other 20 odd items (some are for bundles/some triggered by API’s in specific workflows).
We don’t have a large requirement for many service items in my current organisation though I have worked at other places with upwards of 80 service items with complicated workflows underpinning them. There’s a point where the level of granularity can land up creating more room for error and/or create an administrative burden that ruins the user experience. I recommend in your project to revamp the portal, try and challenge yourself to see how much you can reduce things without losing the must haves!
I would agree, try to keep it as simple as possible and try to tailor the experience for the customers needs.