Is it possible to have 4 levels on C4C Service Categories for fault identification on a service ticket ?

[Suchita92]

Hi,

While I was trying to set up a Service category catalog in our C4C demo environment, I found that setting it up was quite similar to how the categorization schema set up was in CRM onPremise Web UI. So I was able to set the categories on different levels( nesting) in C4C admin center.

However, I do not see an option to tell the system that I want it in hierarchical manner etc. Moreover, while setting up the nested categories ( same level->next level->same level->next level kind of thing), for every next level, system took it as a 'Incident' type - That is still OK for the second level I guess but not for the further nesting in my case, still, I went ahead and maintain a 4 level categorization. Something like below:

A

         A1

               A11

                    A1111

          A2

                A21

                A22

                A23

                        A231

                        A232

                        A233

B

C

On service ticket, I expected that I will get 4 dropdowns list boxes for categorization ( similar to onPremise Service req. web ui )

Categorization 1 list dropdown will show option A, B, C.

If A is chosen then second list will show A1, A2. If A2 is chosen, then 3rd list will show A21, A22, A23 and if A23 is chosen then 4th list will show A231 to A233 option.

But in reality,

since all the first level goes as Process ( which is correct from service scenario point of view) & all the next level are by default go to type Incident ( which I am not happy about), I get a big list in Incident part of the ticket. I have an option to make the 4 levels as Process -> Incident->cause->resolution, because that is how C4C is asking me to set it up whereas my business scenario does not correspond that way and I need 4 levels of categorization to exactly locate the damage. ( so there is no point in putting cause and resolution categories in my case).

Is this expected behavior?

Also, If this is the case then will it not be a challange to integrate the C4C with an existing onPremise, where a customer may have 4 to 6 levels of categorization to identify a fault on the service ticket ?

Has anyone here faced similar problem Or Can propose a way to set up the categorization in the way suites to my scenario ?

Thank you for your time and looking forward to some interesting discussion here.

P.S. - I have already used the forum search to see if I can get some  meaningful info before posting this question.

Regards

Suchita

[Former Member · Accepted solution]

C4C Service Category management has a few "features" that make it very flexible

1. There are 5 different category types (service category, incident category, cause category, resolution category, object category) and you can make each type independent or dependent of each other

2. For each category type, it can be hierarchical (*with the limitation that while you can create a hierachy of catalog values and see it as an admin, there is no end-user hierarchical UI yet to display the category hierarchy in any of the Ticket UIs)

3. The service category catalog has a versioning feature so that you can create different versions of the catalog. There can only be one active version of the catalog at a point in time. When you do reporting, the Tickets datasource will know which category catalog version was active at the last save of the ticket so that your reporting will show the correct catalog values at that point in time

Given these capabilities, we have seen customers use the category feature in two ways:

Option 1- Each category type is a "level" in a 5 level hierarchy of categories, so that they are dependent of each other. You would model

Type Service Category -> Root Level

Type Incident Category -> Level 2

Type Object Category -> Level 3

Type Cause Category -> Level 4

Type Resolution Category -> Level 5

And then relabel to whatever you think the terminology should be to reflect these dependencies/levels (as clearly the standard "Incident Category" text would not mean it is a Level 2 category dependent of the Service Category...)

The Ticket UI will honor any dependencies, so if you choose a higher level category first, it will filter out the lower level categories. Also if you directly choose a lower level category, it will automatically fill in the higher level categories too.

Option 2- Each category type is unique and not dependent of each other. Each category type is a flat list of categories. Since the end user UI category list is not hierarchical it doesn't make sense to configure a hierarchy as it would be hard for the end-user to easily see the dependencies with the list without the hierarchical OVS UI control.

In both scenarios, I usually see customers start with a complex structure (usually a reflection of their previous CRM system) and then start experimenting with catalog versions to simplify categorization of tickets to minimize the complexity for the end user to improve ticket handling time. The more complex categorization you put in, it will increase the average handle time of the service transaction so you need to balance reporting requirements vs. speed.