Hi Tim, Thanks so much for sharing your organization's "Support Group" structure. It sounds like a good way to go, however, I believe I have come to a conclusion with my dilemma. I have found that I can give limited access to the support groups' team leads to be able to add and remove members on their own. So, with this access:
* There is no concern about me being available to add or remove support group members on the fly * The incidents will remain assigned to the appropriate support group, which is part of the reporting requirements. * The support groups will only consist of the primary and secondary support persons, plus the team leads * The number of notification messages will decrease substantially. I have learned a lot from the information you and others have shared with me. I truly appreciate it. Thanks again, Susan Champagne From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Timothy Powell Sent: July-09-14 12:05 PM To: arslist@ARSLIST.ORG Subject: Re: Support Groups: Best Practice? ** Oh...and this greatly reduced our data management workload. If something changed in ref to people and the group he/she is in, all I now have to do is management membership for the specific local group and the master group (vs. having to adjust 35 groups in your potential situation). Tim From: Timothy Powell [mailto:timothy.pow...@pbs-consulting.com] Sent: Wednesday, July 09, 2014 12:02 PM To: 'arslist@ARSLIST.ORG' Subject: RE: Support Groups: Best Practice? 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 5:24 PM To: arslist@ARSLIST.ORG<mailto: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<mailto: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<mailto: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_ _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. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
