| Author |
Message |
|
|
Brian Martin wrote:How about running a report for the amount of tickets opened / closed for those administrators and then sending the team leader those reports?
This won't give you up-to-the-minute updates of new and closed tickets for the admins but you will be able to see all their work progress, at say the end of the week.
We already do this. Thanks everyone for the ideas, but I'll just put a more picky transport rule on my exchange server and then add a filter on the user's mailbox. By the time she is replaced, we may be able to just buy admin licenses with less discretion.
|
|
|
The 2nd option basically provides the same level of consistency as our current work-around. No dice 
|
|
|
|
It seems I can't escalate to an end user. The notifications are limited to sysaid admins, and the team lead is not an admin. I'll try the other option and report back.
|
|
|
I'll try that out and report back.
edit: the escalation I'll try out.
|
|
|
In that case, let me explain why I need this ability.
We have 10 sysaid admins, and a few of them are low-level employees who are just here to complete tasks and get a paycheck. They have no real incentive to go above and beyond, and the business gives them no sole authority on the tasks they perform.
Due to the nature of that business decision, I created rules on our email server to CC their team leader anytime the admin(s) receive an email with "service request #" in the subject line. Their team leader is then able to verify and validate their work-flow based off those copies.
If the sysaid admin doesn't receive a notification when they close a service request, the team lead isn't notified that they have completed the request. But since the admin receives notifications on any new tickets routed to them, the team lead gets all of those emails. This makes it seem like the sysaid admins are not closing their tickets, which is why it becomes harder to validate their work-flow.
Of course, once the team lead logs into SysAid and checks open or closed tickets, everything shows that her employees are working their requests properly. But between those times where she logs in, she cannot validate workflow.
So...... Can we get another checkbox on the preferences -> helpdesk settings -> general settings tab to turn admin notifications on or off even if you are the person making the change to the service request?
Or, can I send validation alerts to End Users? In this example, the end user being the team lead, who is not a sysaid admin or sysaid manager.
|
|
|
"Please note that administrators who insert or save the Service Request will not receive the above defined Administrator's notifications."
Previously, administrators received the notifications when they saved a SR. How do I regain this functionality on the new version? 6.0.04.
Thanks,
RobG
|
|
|
We're rolling out Vista only on an as-needed basis. Basically, we stopped using downgrade rights on new hardware about a year ago after running a live-test environment with 1 poor lab rat per department. Some software we just run as administrator, but most of our stuff works fine with Vista. So far, we're about 40% Vista and about 60% XP. Group Policies to control UAC behavior fix about 90% of the Vista complaints, and another 9% of Vista complaints are actually Office 2007 complaints. 1% are the developers who still want to change code directly in %systemroot%, don't like having to edit their hosts file in their user profile folders and copy it back to their etc folder, and hate having to use ctrl+shift+enter to open a cmd prompt as admin.
People holding out for some dramatic change with Windows 7 are going to be disappointed, since it's going to be the same underlying system, probably with a few cosmetic changes so win 7 people will have a better OOBE with UAC without having to create group policies to control it.
|
|
|
Stewart wrote:i have run into the same issues here, although it is getting better. whenever someone emails me with a request, I always direct them to open an SR so I can track it in the system and update our knowledge base with the solution. I also tell them if they email just me and I am out of the office or not at my desk for an extended period of time, then the other two guys who work with me won't be able to fix their problem - if the open a SR, all three of us will get it. If I get stopped in the hallway, I just tell them to open a SR or I will forget 2 minutes from now.
it's been a long haul and continues to be  , but it is going in the right direction. 
And it will always be a haul as you will always have new employees who don't understand the process even if they signed something that says they understand it during their hiring process. Your users continually change, so you always have to be on edge enough that you don't let anything "slip through the cracks" or "just this one time for the new guy" or "he's an exec who is used to special treatment, no reason to track his requests."
If someone asks me in person for help, I respond with "the faster you submit it in SysAid, the faster I'll be able to fix it." True emergencies should be defined ahead of time so you have something on paper to show them if they think its an emergency and you know better. "Sorry, that's not an emergency. You have to follow the helpdesk process." It only works if you've defined what an emergency is, otherwise abuse will be rampant. Leverage management to define emergencies and get them to sign off on the agreed-upon definition so you have full confidence that they will back you when you tell an employee they are wrong.
As Stewart said, I explain that submitting a ticket means their request won't fall through the cracks, and alternates are set up so if I'm out on vacation or sick, their request will still be handled by someone else. In addition, since I'm using LDAP authentication and have mail for exchange on my phone, I also use the "I may not be at my desk, or in the network room, or in a meeting, or on site. If you submit a request, I will be notified immediately on my phone and can go directly from where I am to where you are without you having to track me down."
For certain execs who think they are so special they don't have to follow the rules, I tell them I can help them out right now and we can go look at the issue together, then as they turn to head to their office I turn to my computer and start to fill out a ticket for them. They're smart, and they quickly get the picture that it would be just as fast if THEY submitted the request.
My biggest weak spot is when someone asks for help from their desk as I'm walking the halls. I always have to tell myself, "don't fix it unless they submit a ticket" 5 times in a row. The nice way of handling this is to ask what they need, and if its something you can fix right away, ask them to submit a ticket right there on their computer before you perform the fix. Once its submitted, fix the problem and everyone is happy.
But there is no end to educating people about processes. You will always have to do that as a primary helpdesk contact. The only way you'll be able to stop educating people about how to contact the helpdesk properly is to leave the helpdesk.
|
|
|
|
|
