Susan, LJ is correct.
BMC ITSM is known to send out too many notifications. The last thing you want to do is to notify support staff incorrectly. Most support staff I have worked with will then quickly just ignore notification sent my BMC. Auto assignments are one on the best figures with BMC ITSM. There is no need for a one-to-one relationship between products and support group. One group might support only one product, anther group might support ten products. Look at how the teams are working. Create your support groups based on team names, regions, shifts, product groups, technology, or something else. 35 teams might be correct! You might end up with 20 or 40 teams? Create the support groups based on how the support staff is organized. Configure your assignments where you map ticket/requests details with support group. Then put you engine too work. At times it is useful with a “Microsoft Office 1line”, “Microsoft Office 2line” and “Microsoft Office 3line”. The first line are responding to and solving as many tickets they can. If they cannot resolve – they manually to 2line. If I am member of 2nd and 3rd line there are no need for me to be notified for everything coming into 1st line. Personally “I hate notifications”;. as a BMC Remedy developer / consultant I do whatever I can to reduce the of notifications sent out. Mass notifications are just pissing people of. The email/notification are not getting read. If you got the group balance right (number of groups), group membership right (support staff member of different group) your notifications should then be more targeted to the correct people. This is what you want! You might also want to look at other methods of notifications. Reading and responding to email are often not the best way of creating and efficient helpdesk. ~ Terje From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of LJ LongWing Sent: Tuesday, July 08, 2014 3:37 PM To: [email protected] Subject: Re: Support Groups: Best Practice? ** Susan, I can't speak specifically to ITSM Support Groups, because I don't run ITSM....but sometimes what is best for the user is not best for the administrator. From what you have described, they want 35 support groups for better granularity of responsibilities, and of course, not all 30 members would be in all groups. As a user, I can tell you that receiving emails that are of no relevance to me, that force me to look at them to figure out if it applies is a pain....but then again...the users could create rules to auto-delete the ones that don't apply to them....I don't know...it's truly up to you...but the more granular groups may allow for better end reporting of issues :) On Tue, Jul 8, 2014 at 8:18 AM, Champagne, Susan <[email protected]<mailto:[email protected]>> wrote: ** 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_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
