Starting Service Catalog Design, looking for best practices

[pat20]

Hi, we are starting project planning for the build of our service catalog. We have been live with ServiceNow for ITSM for six months. Can anyone provide words of wisdom, best practices and share their experiences? Please suggest any tools or resources that would provide value to us for the design and implementation. Any information would be very much appreciated!. Thank you.

[Pradeep Sharma]

Hi Patricia,

You may find the below blog helpful.

https://community.servicenow.com/community/blogs/blog/2014/08/14/13-service-catalog-best-practices

[Uncle Rob]

Remember who's supposed to ultimately benefit from the catalog:   the business.   If the catalog isn't making the business operationally faster, its really just a toy for IT.   To that end, remember two things:

1)   Your customer isn't IT, and they don't care about IT's reporting

2)   Your customer doesn't want to be on the portal in the first place.   They want to be doing their day job.

Practical design decisions stemming from that?

1)   Don't waste time building service taxonomies that nobody is going to click through.   If you're not fronting the operation with search, you're forcing your customer to think like IT.   Might as well make them access the portal with a dial up modem too.   Your search options are....

• Contextual Search - a decent OOB option that combines both KB and Catalog searches.
• OneSearch - a much more robust searching tool available on share, but requires keener dev chops to utilize.

2)   Don't overwhelm your users with questions.   A customer once described this to me like so:   "Got more questions than a mortgage application?   $%&# you.   I'm just going to email it to everyone's manager"

3)   Abstract out the Request layer.   Just operate with Requested Items and Catalog Tasks.   End users on Service Catalogs tend *not* to order multiple simultaneous things, which radically reduces the utility of an already confusing wrapper layer.   Requests also don't "roll up" any valuable info from the child records, so they're often meaningless to the users submitting them.

4)   You'll discover that many workflows in   your org transcend the silos we're trained to assume have their own services.   Its critical to catch these and bring the executing teams together under a single workflow.   Why?   Because otherwise you're asking your customers to submit multiples of the same requests so your back end teams can have their SiloSafetyBlanket^TM

5)   Did I mention the Search thing?   Because seriously.... $%&# categories.

6)   If you've been working mostly with Incidents for ticket work, put a little thought into how teams will manage multiple task types.   For this reason I usually create a "Work Management" menu with modules like "my work, my groups' work, and my groups' unassigned work".   These modules report off Task so I can get all my work in one click regardless of Task Type.

7)   Prepare for some Task confusion on multi-step workflows.   You may have a Catalog Item with three component tasks.   The data will be structured as one RITM record facing the user (if you followed item 3), and 3 sc_task records.   We know the teams that own the component tasks... but who owns the RITM?   I *usually* don't bother assigning the RITM to anyone, as it causes confusion.   You wan the RITM to close when the component tasks close, and I find too often people try to work the RITM instead of the component tasks.

I can probably think of a few more through the day, but does any of that help?

[Uncle Rob]

Also.... $%&# categories.

[JusCuz]

Nicely stated, your 'two things to remember' at the beginning of your reply.....it's always amazing to me how difficult it can be to get people to understand those two items.