Tech Support Howto - Revision history

Paulm: /* Accounts */

2012-10-09T17:30:22Z

Accounts

2012-10-09T17:27:35Z

Accounts

2010-01-31T00:33:11Z

2010-01-30T23:36:45Z

Tools

2010-01-30T22:16:52Z

Various procedures and policies

2010-01-30T22:15:20Z

Class Rejects

2010-01-30T22:13:26Z

2010-01-30T21:53:45Z

Walk-ins

2010-01-30T21:49:34Z

Voicemail

2010-01-30T21:41:10Z

Phones

@@ Line 6: / Line 6: @@
 * Wiki -- Techs need a wiki account because part of their job is to update the Tech support knowledge base.
 * Talon (application server) -- This allows them to log in to their own account on the terminals, and provides a place for them to store files. (accounts on request only, we don't really use this anymore)
+* Checkmarkable.com -- has our checklists
 When setting up these accounts, go over their use with the tech, and make sure that general guidelines are understood.

@@ Line 5: / Line 5: @@
 * Database -- Also necessary.  Find the techs volunteer contact info and edit it, check "Can login", check "tech support" and have the tech fill out a username, email and password.  If the tech is not in the database yet, create the contact and save it before trying to set up the login, do not try to do it all in one step.
 * Wiki -- Techs need a wiki account because part of their job is to update the Tech support knowledge base.
-* Claws (application server) -- This allows them to log in to their own account on the terminals, and provides a place for them to store files.
+* Talon (application server) -- This allows them to log in to their own account on the terminals, and provides a place for them to store files. (accounts on request only, we don't really use this anymore)
 When setting up these accounts, go over their use with the tech, and make sure that general guidelines are understood.

@@ Line 53: / Line 53: @@
 *[[Support boundary guidelines]]
 *[[Freekbox support policy]]
 ==Tips==

@@ Line 1: / Line 1: @@
 ==Tools==
 For the admin:  Several accounts should be created for each support tech
 * RT -- This is the main one all support techs '''must''' have.  Generally by the time a tech starts, his or her email is already in RT as a user.  Find the email, change the username from the email to something suitable, give the account privileges, have the tech put in a password.  Then once the account is privileged, add it to the fgcore group.
@@ Line 7: / Line 8: @@
 When setting up these accounts, go over their use with the tech, and make sure that general guidelines are understood.
 ==Process  (for the techs)==

@@ Line 52: / Line 52: @@
 *[[Handling class rejects]]
 *[[Support boundary guidelines]]
 ==Tips==

@@ Line 48: / Line 48: @@
 *  If the box gets left for any length of time, make sure the client gets an RT ticket number.
-===Class Rejects===
+===Various procedures and policies===
 *[[Handling class rejects]]
 ==Tips==

@@ Line 45: / Line 45: @@
 *  Make sure there is a work order immediately
 *  Talk to the client and determine the nature of the problem
-*  Triage -- If the problem is a short fix, work on it right away and get the issue resolved.  If it is a longer issue, put it in the queue with the other boxes.  Explain how long you think it will take.
+*  Triage -- If the problem is a short fix, work on it right away and get the issue resolved.  If it is a longer issue, put it in the queue with the other boxes.  Explain how long you think it will take.  Clearly this will depend on workload.
 *  If the box gets left for any length of time, make sure the client gets an RT ticket number.
 ==Tips==

@@ Line 25: / Line 25: @@
 ===Voicemail===
-*  Check voicemail at the start of the shift, on all phones
+*  Check voicemail at the start of the shift, on all phones.  Check again regularly through your shift.
 *  Record each voicemail in separate RT ticket  (look for tickets documenting previous calls but don't spend a lot of time on that)
 *  the subject should include VM and the caller's name

@@ Line 14: / Line 14: @@
 *  Documentation -- Every call should get an RT ticket.  Try to have a ticket number by the end of the call so you can give it to the caller.
 *  Get the person's name, and a call back number if possible.
 *  Troubleshoot
 **  Find out early if it is a supported system