Desktop

Ask something
Discussion Locked

End User/Desktop Support - Processes & Best Practices

0 helpful
11 replies

by jengianfrancesco

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

I'm looking to pull together a list of best practices or processes that should be implemented and documented for an IT team of desktop support specialists.

Any suggestions. The few that I already have are:

Local Admin PW resets
Network Account Creation in AD
Creating PC images

11 replies

by hayward.johnson

Make sure that client/company management is onboard with your best practices policies and procedures (P&P), assurring that end users WILL experience consequences for not following them. The best P&P in the world offers nothing if it isn't enforced.

Might want to also detail whose purview is what. "THIS is an end user obligation. THAT is a management obligation. THE OTHER a support obligation." Like that.

That way, if anyone gripes about some support performance issue, you can say, "Well, first, has everyone else held up their ends of the bargain? If so, then, yes, it's a support issue I have to look into. If not, then it's a management issue someone else needs to look into."

by theprofessordan

Service Level Agreements help in setting a realistic expectation for end users as well as helping a desktop support person to prioritize their workload.

It's also a good idea to bring the end users in when developing the SLAs. First off, it helps to establish a good working relationship with the end users. Second, if the end user is part of the process of deciding what levels are reasonable, the are more likely to be tolerant with the desktop staff when it comes to responding to trouble tickets.

Finally, when you develop the SLAs, make it the goal of the desktop staff to exceed the SLAs on every call. If the SLA says that you have to respond to medium tickets within an hour of the ticket being placed, make the team goal thirty minutes. I find that if you consistently exceed your SLAs, you get more leeway when things occur that are beyond your control that cause you to miss your SLAs.

by bit - twiddler

An important consideration is what, if any, ticket creation and tracking tools you will need.

I work on a leveraged help desk (after-hours), and we support about 15 different (Large/Enterprise) clients here, each with their own special needs when it comes to creating and monitoring the incident tickets.

We use several different versions of both Remedy and Peregrine Service Center for this.

Also consider basic tasks related to MS Office, we do get a lot of calls from all clients with regards to "How do I do XXX in MS Outlook / Word / Excel / Powerpoint / Access / IE / Windows?".

This raises yet another concern....are you going to be break-fix support, or will you include user training. Even though we are "strictly" a break/fix desk and not a training desk, we usually try to assist with "best effort" when we can.

By Far MS Outlook issues top the list of MS related inquiries(PST's, OWA, creating accounts/profiles on different workstations, general usage), but also basic things (basic to an IT pro)like mapping drives in Windows, or file management and folder permissions, along with missing *.DLL's and installing printers.

Remember the "smart ones generally don't call the help desk, they know how to either fix it themselves or find a solution on the net, and implement it successfully".

At least when the more seasoned user's call it usually is a "legitimate" issue, both interesting and challenging, as opposed to just hand-holding. (but they both pay the bills!)

For more windows oriented ideas, try reviewing some online syllabus's (syllabi?) for MCDST, there are sure to be some things covered in the MCDST materials that you will run into which I have not mentioned.

That of course assumes you are not supporting a *Nix enviroment, or some other proprietary s/w.

Also VPN issues are big here(especially "after-hours"), network connectivity (both at work and at home), and Wifi is coming on strong these days.

Interestingly enough, for some clients we DO support one thing or another, but for other clients we DO NOT support the same thing.

I strongly suggest you spend some time to clearly define EXACTLY what is supported in (and out of) your environment. Do you support Wifi? Does this include in the home?

It also wouldn't hurt to consider alternatives to provide your client(s) in the cases where you do not support it. (IE: "I'm sorry, we do NOT support WiFi networks in the home, have you tried contacting the manufacturer of the router or your ISP"?) In other words, if you don't support it, you should be able to direct the client to whoever does.

Believe me, there is plenty of room for "grey areas" in conflicting policies, which can leave the support personnel frustrated between a rock and a hard place.

Case in point, for one client that has a fairly strict "do NOT support Wifi" policy, coupled with a fairly lenient after-hours
"VPN support" policy (iow- "best effort"), what then, do you do, with a caller who is trying to connect using VPN at a hotel that ONLY has Wifi available?

Another important process that should not be overlooked or underestimated is server outages.

These are usually the highest priority, will generate a lot of calls (typically), can have the greatest impact on the clients productivity, and involve the most "support streams & teams" in resolving.

On a smaller scale, how will you handle a user's PC that won't boot into windows.(hardware support).

I get the sense this is an in-house operation, in which case some sort of SLA is not a pre-requisite, but may be worth considering if only as a guideline on policy and procedure.

Also I have found lots of great insights within the Tech Republic site, so spend some time surfing around, and I'm sure you will also find some as well. (Happy Hunting!)

Hope this helps.

by pat.lynch

It is invariable that someone will call and request solutions for problems that don't exist, service and training requests are an intricate part of most major IT service providers offerings. Answering these requests (no matter how inane) with a helpful attitutde, friendly response, and an educated (not degrading) answer is the difference between good organizations and word class ones. I've participated in the procurement and recommendation of 10's of millions of dollars in IT equipment and when all things being equal, very often the rationale and decision as to who to buy from hinges on the quality of their first response services.

by charliespencer

I don't care how long it takes you to acknowledge my problem. I want to know how long it takes to FIX it. I've seen '15 minute acknowledgement' become two weeks to resolve. All 'resolve time' measures is how many people are working the phones or monitoring the intranet.

by theprofessordan

Though I do agree that it should not be the end all of end all for metrics, I do feel that this is an important goal to hit. It's a good place to start. Letting the user know that you are aware of their issue and that you are working goes a long way in establishing confidence in the IT department. Obviously if you quickly call them and then ignore the issue it doesn't matter how quickly your initial response time was but making your goal a quick initla response is an important part of the process.

I guess I sort of equate it to saying that how your settle your feet in the batter's box doesn't matter if you don't follow through on your swing. Your batting stance like your initial response time is all part of the process that leads to success. All parts are important.

by pat.lynch

TAT or TTR (Time to Repair) are the SLA Metrics used by most major IT service providers. Ideally the Service desk will maintain TTO (total ticket ownership) by having the service desk maintain the lifecycle of the incident you are able to reassure the customer user while freeing the desktop support technician to resolve the incident.

This discussion is closed to new replies.