Writing a helpdesk operations manual.

0 Votes

Writing a helpdesk operations manual.

I'm one of the few starting the in-house helpdesk for Guaranty Bank, and I need some advice on writing an operations manual.
Any Advice?
0 Votes

Determine the contents of the manual.
Have one person responsible for updating the manual, after all the contributions have been made. Use revision numbers in the footer and turn on tracking in word.
Will it be only for first level support?
Work done after hours and on weekends - does that have other duties not usually done?
Have contributions from other areas provided to you via a mailbox set up for the task.
Be specific about the time-lines duties need to be completed for the week and after hours. Specify the priority and emergency contacts if needed.
Provide instructions that are specific about how they are done, so anyone can do them, especially new people.

Hope this helps.

0 Votes

Get to know your audience both Help Desk and Customers/Clients. What skill level are at, What is your goal/purpose,
Include the HD in the assessment process. The HD have hands-on experience into the customer. USE IT!! Tap into that knowledgebase.

Develop a format that is appropriate that you want your KB articles to look like. Provide an EXAMPLE of a published manual- to include the detail, use the proper terminology (Click on start button, select the All Programs Menu, Select the Accessories Menu, Select the System Tools Menu, then select Disk Defragmenter. Click on Analyze button to determine if the disk needs to be defraged. If so click on the Defragment button.) Since we all know that there is 3 ways or more to do the same thing, footnote with another way you can kick off defrag without using the menu, like start, run defrag.

Task your current HD people with creating some of the articles and allow them off the phone do so even if it is a few hours a week. And give them credit for doing so. A sense of accomplishment will go a long way with keeping them, and we all also know how helpful it is when we get an escalated case that is properly documented and troubleshot.

Use screenshots if necessary, especially if it comes to using the command line or modifying files like an ini, , ica, or a config file.

DON?T ASSUME ANYTHING!!! Someone may know how to write html or java but never learned how to rename a pc or join to a domain.

TEST, TEST TEST!!! Allow the articles to be used when they are ?Work in Progress? to ensure that all the deviances are covered. (eliminating rare error messages, problems with user rights, ect) this will improve the accuracy of the article. If an article is a MUST USE it needs to be accurate each and every time. Otherwise it will loose its value.

And provide a medium for the HD To provide suggestions not just a suggestion box but truly follow up with the suggestions if they find an error or a better way of doing the task.

Hope this helps

Desktop Tech/Trainer

0 Votes

As any Operational Manual is a living document we have links to documents for bigger tasks to keep the manual down to a manageable size thus allowing these to be updated without revamping the entire document. In addition, maintain a printed copy for disaster recovery in the event the worst does happen and you do not have access to the electronic format.

0 Votes

I did this, when I came into a new IT position, created...and virtually created all the procedures / documents. My advice..

1) Keep it simple. Not everyone understands / thinks the way you do. Write as if you were writing to a non-technical person.

2) Cover every aspect. Look at all the aspects, and try to anticipate questions. Speak with former employees and find out what problems / questions they frequently run into.

3) Create an INDEX. INDEX. INDEX.

4) Do not talk down to people, this is the difficult part of being in an IT position.

5) Proof-Read, Proof-Read, Proof-Read. Have someone else then Proof-Read for you. Proof-Read once more.

6)Use steps much like I did here...I recommend this format..

Three main parts to any "guide"..

List (Step Name). <-- Easy way to refer to problem.
List(Step Description) <-- details as if non-technical person.
List(Next Step Action)<--What to do if it works doens't work.

Use that formula and it creates something like this...

Problem: My PC will not turn on.

Step 1: Ask Bla Bla if he / she can locate the power button, (explain in detail as if this is a non-technical person)
Step 2: Recommend Bla Bla push button (If This works, end question. If this does not work, try step 3)
Step 3: Suggest Bla Bla check the Power Cord, (explain about Power Cord Location, How to Check etc)(If Power Cord is lose, and is now secure, and power works, end question, If Cord was Secure and still does not work, move to Step 4)

and so forth and so need to be very explanatory, very detailed, and understanding.

Thats the formula I used, so if somone had to walk into my position, they could instantly know what they are doing.