Ok, we had a similar situation with our desktop support people. Here is what we did.
We created separate desktop groups for each location (in your case for each specific app). So for example: Desktop-Orlando, Desktop-Charlotte, etc. In your case it might look like Support-App1, Support-App2, etc. Each of these specific groups only contained the people in that specific location. In your case, they would only contain the people specifically responsible for that application. We then created a "master" group. Call it Desktop-Master. In your case it might be Application-Master. We added all members to the Master group. We added the overall manager to ALL groups as an associate member and marked them unavailable for assignment. We did this so that the manager could go in to any group at any time and reassign the ticket from a specific group to the master group for just the reasons you indicate. In case the specific group members were unavailable for whatever reason. This reduced the overall number of notifications, gave us some specific data for reporting and still allowed for maximum coverage as needed. We also built our assignment rules so that the specific groups were auto-assigned tickets based on location (in your case by specific app) and made sure they appeared as the first pick in the list if somebody clicked the Auto-Assign link. We then configured the assignment rules so that the master group acted as an auto-assignment "catch all" group and made sure they appeared 2nd in the list if somebody clicked the Auto-Assign link, thus establishing a manual assignment hierarchy. HTH, Tim From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Champagne, Susan Sent: Tuesday, July 08, 2014 1:59 PM To: arslist@ARSLIST.ORG Subject: Re: Support Groups: Best Practice? ** Hi Shawn, Yes, you are correct, each application does have a primary and secondary support person. The reason I was asked to add all members of the main group to each individual support group was to ensure coverage in the event that the 2 actual support people for the application happened to be away at the same time. This way, another support person would step in and do what they could with the request. Otherwise, I would be expected to add members to support groups on-demand, and that would not be reasonable, since I am alone, supporting Remedy in our organization. Thank you for your input. Susan Champagne From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Pierson, Shawn Sent: July-08-14 1:40 PM To: arslist@ARSLIST.ORG Subject: Re: Support Groups: Best Practice? ** While what you are saying mostly makes sense, 35 groups for 30 people is very excessive, especially if all 30 people are in all 35 groups with only one enabled and 29 "offline" for that group. It's not practical for 30 people to support 35 applications with everyone covering each other as backups, purely from a work perspective. My guess is that there is probably a primary and secondary person for each app, or they are grouped according to purpose, or something. There has to be some way to build logical support groups that are smaller. I'd guess that you could get them down to 3 - 5 support groups, even though everyone would need to be added to all of those groups with the tertiary support staff as offline members of that group. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Champagne, Susan Sent: Tuesday, July 08, 2014 12:34 PM To: arslist@ARSLIST.ORG Subject: Re: Support Groups: Best Practice? ** Thank you again Terje. In answer to your question, yes, every support person, in each of the support groups, in this discussion, must have the ability to work on any of the assignments to any of the groups they are members of. Our service desk personnel create most tickets and assign to the appropriate support group, in some cases, or to the appropriate individual in other cases. We do not have any assignment automation configured at this time. Thank you again Terje; your input is much appreciated. Susan Champagne From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Terje Moglestue Sent: July-08-14 1:14 PM To: arslist@ARSLIST.ORG Subject: Re: Support Groups: Best Practice? ** Susan, I find it difficult to understand why you want all support user should be member of all teams. If the support staff got unlimited access - they can still search all tickets. A support engineer can only modify tickets assigned to a group where he is a member. Is this the reason why you want all support members to member of all groups? Are every support engineer working and updating the tickets across all the support groups? A support group performance is normally done based on all the ticket assigned to their groups and how quickly the close these tickets. OLA agreements can be made to measure the group or individual performance. Reporting can be done on any criteria you want. Product Name, Region, Customer, Support Group... Are ticket manually assigned to individuals or are you the round-robin or capacity assignment using auto assignment to individuals? Who creates the tickets? Are they created by the customer using the SRD? Or are they manually created and manually assigned by a dispatcher? There are so many alternatives - and so difficult to give any useful advice. How advanced or mature is your help desk? Are all the agent working within the same time zone? Are you working as teams? - It is very common to allow the assignment engine auto assigned the ticket to different groups - no individual assignment. - Every member of the group is then monitoring unassigned tickets within their console / groups. The support engineer then picks up unassigned tickets. The first thing they do is to assign the ticket to themselves - before the start working on the ticket. Every member or the group is then taking their turn. - You could have an "incoming support group" or a front line. Tickets are then auto assign to this group. Tickets are then manually reassigned to groups / individual as they start working on the ticket. Everyone is then member of the "incoming support group" but they work in different teams and reassign the ticket to their group based on skill set, product, location or something. With this set up I am really struggling to understand why need to be member of all the groups? We got the shift functionality and more. I think I stop there - it is getting late in London. Good luck! ~ Terje From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Champagne, Susan Sent: Tuesday, July 08, 2014 5:24 PM To: arslist@ARSLIST.ORG Subject: Re: Support Groups: Best Practice? ** Hi Tim, The end goal, from the requester's view, is to eliminate the currently set process of "Assignment to Individuals". I am in total agreement of getting to this end result; it's just that I feel we could/should accomplish this end result in a different manner. The manager of the group wants to have the ability for his users to be able to filter the Overview Console, to show only incidents assigned to the groups they select. As I mentioned earlier, each individual (30 people) will be in each support group (35 groups). I really hoped I could convince them to use the Product Name as a sorting option in the Overview Console, instead. The reporting could also be done on the Product Name. Susan Champagne From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Timothy Powell Sent: July-08-14 12:06 PM To: arslist@ARSLIST.ORG Subject: Re: Support Groups: Best Practice? ** What is the end goal of this request? WHY are they wanting 35 groups? Knowing the desired result might help guide some of our thoughts and responses. Tim From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Champagne, Susan Sent: Tuesday, July 08, 2014 10:19 AM To: arslist@ARSLIST.ORG Subject: Support Groups: Best Practice? ** Hi folks, I'm looking to get some advice on what the best practice is regarding Remedy support groups. I have a group of 30 support staff members, who support many different applications, and many individual modules in some applications. They are asking that I create individual support groups for each area of support. This would be 35 support groups. Originally, when we built the system in 2009 (7.0.03), we had one support group for these people, but we used the "Assign to Individual" practice, which is becoming increasingly more difficult as the group grows and as their support model grows. We are now at 7.6.04. I am looking at suggesting that we leave them in one support group, and I would add the "Product Name" field to the assignment notification message, allowing them to determine if the assignment is for them or not. My dilemma is on how to convince them that this would be the best way to proceed. Your input on this matter would be most appreciated. Thank you, Susan Champagne **************************************************************** The information contained in this e-mail and document(s) attached are for the exclusive use of the addressee and may contain confidential, privileged and non-disclosable information. If the recipient of this e-mail is not the addressee, such recipient is strictly prohibited from reading, photocopying, distributing or otherwise using this e-mail or its content in any way. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ **************************************************************** The information contained in this e-mail and document(s) attached are for the exclusive use of the addressee and may contain confidential, privileged and non-disclosable information. If the recipient of this e-mail is not the addressee, such recipient is strictly prohibited from reading, photocopying, distributing or otherwise using this e-mail or its content in any way. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ **************************************************************** The information contained in this e-mail and document(s) attached are for the exclusive use of the addressee and may contain confidential, privileged and non-disclosable information. If the recipient of this e-mail is not the addressee, such recipient is strictly prohibited from reading, photocopying, distributing or otherwise using this e-mail or its content in any way. _ARSlist: "Where the Answers Are" and have been for 20 years_ Private and confidential as detailed here <http://www.energytransfer.com/mail_disclaimer.aspx> . If you cannot access hyperlink, please e-mail sender. _ARSlist: "Where the Answers Are" and have been for 20 years_ **************************************************************** The information contained in this e-mail and document(s) attached are for the exclusive use of the addressee and may contain confidential, privileged and non-disclosable information. If the recipient of this e-mail is not the addressee, such recipient is strictly prohibited from reading, photocopying, distributing or otherwise using this e-mail or its content in any way. _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
