CA Service Management

Is there any documentation on best practices on implementing support tiering in SDM? Up until now we only had a single tier support structure with groups assigned for each individual application/service support team. We are now rolling out a new Customer Support team that is intended to operate as Tier 1 support across all applications/services and the existing support teams will operate as Tier 2. We want the Tier 1 team to own the customer communication through the entire lifecycle of the issue even when the issue may have been transitioned to Tier 2. Creating a new group for Tier 1 does not seem to be the right answer because if issues are transferred to Tier 2, Tier 1 would no longer have a clear line of sight into the issues they need to be monitoring and reporting back progress on to the customers. Is there a way for Tier 1 to continue to "own" the issue even if the resolving group is different?

I'd like to understand your requirement better. Is this a single Tier 1 group and multiple Tier 2 groups? Or are there multiple Tier 1 groups as well?

Hi Lindsay,

For now we just have one Tier 1 team but multiple Tier 2 teams. I want Tier 1 to retain ownership and visibility into all issues throughout their lifecycle.

Okay. So all tickets, whether they have been transferred to a Tier 2 group or not, still need to be seen by the Tier 1 group.

Can the Tier 1 group not see all tickets today? If yes, then you could simply give them a scoreboard node showing all unresolved tickets. If no, have you implemented some data partition that prevents them from seeing the tickets if they are not a member of the group to which the ticket is assigned?

There are some other non-Support groups that use Service Desk as a ticketing system. Tickets opened by them are not relevant to Tier 1. Ideally what we want is to have tickets that originate in Tier 1 to stay visible to them even as they move along to Tier 2 groups so that Tier 1 can do follow-ups with customers on resolution status. 

It sounds like you want the ability for a ticket to be "owned" by up to two groups at the same time; (1) the group that is working on the ticket and, optionally, (2) the Tier 1 group. I can imagine a couple of approaches to this and both require adding a custom field.

1. If I wanted to just identify that the Tier 1 group was associated to some Tier 2 group, I would add an attribute to the cnt object (for example, zTier_1 as an SREL to cnt) and expose that as a field on the detail_cnt.htmpl file for updating. Once I had updated those Tier 2 groups with the association to the Tier 1 group, I would create a query and scoreboard node to show all the tickets that belonged to a group that is associated with Tier 1.
2. If I wanted to control this on a ticket by ticket level, I would add an attribute to the cr object (for example, zTier_1 as an SREL to cnt) and expose that as a field on the detail_cr/in/pr.htmpl file for updating. The important thing here would be to train my Tier 1 people to put their group in zTier_1 before they transferred the ticket to a Tier 2 group. I would also have to create a query and scoreboard node to list those tickets.