Highlighted
Absent Member.
Absent Member.
497 views

Service Catalog Query

Jump to solution

Dear All,

 

We are running on HPSM 9.32, I have a query on the OOB service catalog module.. Can we customize the flow of the service catalog module? Has our customer wants to minimize the number of clicks basically taken to order an item from the catalog.

 

It takes more than 6 to 7 clicks to order an item, need to get this clicks reduced to certain level by making some customizations.

 

Meanwhile, tried adding a button on a service catalog svcCatalo.select(i.e. order from catalog page) on a web client, but the button was not shown. Any advice??

 

Regards,
Madhu
"Every Help is highly appreciated with kudos"

 

0 Likes
1 Solution

Accepted Solutions
Highlighted
Admiral Admiral
Admiral

Which version of the SRC are you using? The one which comes default OOB in the ESS web client or the new "pretty" 9.31 SRC?

1: For your main question, this will be difficult for us to answer and for you to design a solution that meets your customer's needs without some specifics.

I assume based on your button question that you are not using the new SRC. I'm not sure if there is a huge "click difference", but if there is a measureable difference then using that SRC might be an option.

The deeper your categories and items go, the more clicks will be involved. In theory, the customer could reduce the number of clicks by only having one top-level bucket and EVERYTHING offered could be in there, but that's poor categorization to begin with and you'll run into click problems anyway with having to navigate through multiple pages of offerings. You could possibly leverage bundles to reduce clicks, but if there are lots of things which need to be offered alone, that won't help much.

In theory, you might be able to shave a few clicks here and there by having the user go directly from the catalog screen to submitting the order (rather than viewing the cart), or skipping the item details, or skipping the cart functionality altogether and when clicking on an item then they go right to a submit screen. But all those would require a decent chunk of tailoring, and there's a lot of interdependency in the SRC which you run the risk of breaking, as well as in general throwing away a lot of the functionality of the product.

Perhaps a more apropos question would be What is the business need which is driving this focus on "no more than * clicks"? In general, users making catalog requests is low-priority stuff. If we're talking about users who need a new office phone, they shouldn't be in a huge hurry to get their order in. If we're talking about service desk agents who have someone on the line asking for Word to be installed, that interaction is not in a time crunch and shouldn't be bound by clicking through a catalog as fast as possible. If someone is on the line reporting a P1 incident for a down server, that's a time-sensitive interaction but it's not an SRC ticket. I would find out why they want to minimize SRC clicks, and if their expected benefit from throwing away the catalog functionality isn't worth the loss, then stress to them the power of SM's catalog. 😉


2: As for your button, the issue is likely not a difference necessarily between web client and thick client. Did you create a display option for this button and then specify the display option number in the control properties of the button?

View solution in original post

1 Reply
Highlighted
Admiral Admiral
Admiral

Which version of the SRC are you using? The one which comes default OOB in the ESS web client or the new "pretty" 9.31 SRC?

1: For your main question, this will be difficult for us to answer and for you to design a solution that meets your customer's needs without some specifics.

I assume based on your button question that you are not using the new SRC. I'm not sure if there is a huge "click difference", but if there is a measureable difference then using that SRC might be an option.

The deeper your categories and items go, the more clicks will be involved. In theory, the customer could reduce the number of clicks by only having one top-level bucket and EVERYTHING offered could be in there, but that's poor categorization to begin with and you'll run into click problems anyway with having to navigate through multiple pages of offerings. You could possibly leverage bundles to reduce clicks, but if there are lots of things which need to be offered alone, that won't help much.

In theory, you might be able to shave a few clicks here and there by having the user go directly from the catalog screen to submitting the order (rather than viewing the cart), or skipping the item details, or skipping the cart functionality altogether and when clicking on an item then they go right to a submit screen. But all those would require a decent chunk of tailoring, and there's a lot of interdependency in the SRC which you run the risk of breaking, as well as in general throwing away a lot of the functionality of the product.

Perhaps a more apropos question would be What is the business need which is driving this focus on "no more than * clicks"? In general, users making catalog requests is low-priority stuff. If we're talking about users who need a new office phone, they shouldn't be in a huge hurry to get their order in. If we're talking about service desk agents who have someone on the line asking for Word to be installed, that interaction is not in a time crunch and shouldn't be bound by clicking through a catalog as fast as possible. If someone is on the line reporting a P1 incident for a down server, that's a time-sensitive interaction but it's not an SRC ticket. I would find out why they want to minimize SRC clicks, and if their expected benefit from throwing away the catalog functionality isn't worth the loss, then stress to them the power of SM's catalog. 😉


2: As for your button, the issue is likely not a difference necessarily between web client and thick client. Did you create a display option for this button and then specify the display option number in the control properties of the button?

View solution in original post

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.