Troubleshooting Strategies for deskside support.

Enviado por Oz el 2005, Abril 22 - 3:37pm.
Grupos: Toolbox

This document is a work in progress. You (yes, you!) are encouraged to make improvements.

A Generic Computer Troubleshooting Process

  1. Problem appears.
  2. User requests support.
  3. Tech repeats back his understanding of the problem.
  4. Tech attempts to recreate problem.
  5. Upon replicating problem, tech records what caused problem to appear.
  6. Tech records error message(s), if any.
  7. Tech reviews appropriate log file (such as the Windows Event Viewer) and notes information of interest.
  8. If error messages are not obviously meaningful, tech researches them using appropriate resource. Google Groups, EventID.net, the vendor's knowledgebase are the best places to start.
  9. Using information gleaned from the Web, Tech solves problem.
  10. Tech confirms problem resolved with user.
  11. Tech documents problem in knowledge base and indexes problem under users request and tech interpretation.

Contributors:

Zac Mutrux: created page

‹ Support and Documentationarriba
versión para impresión | Inicie sesión o regístrese para enviar comentarios

What this is for

Imagen de zac
Enviado por zac el 2005, Abril 22 - 3:40pm.

Many times I am able to solve technical problems not because I immediately know the answer, but because I know where to look for the answers. Information about a troubleshooting process like this could be useful to accidental techies, who are usually capable of solving problems they are afraid to tackle.

A process document like this could also help a consultant to improve his or her own troubleshooting process. I would like to see others add/rearrange steps to help develop this document over time.

I consider this little more than a very rough draft. What do you think I've left out?

Zac

Zac Mutrux
Consultant and Commonist
CompuMentor

Inicie sesión o regístrese para enviar comentarios

include assumptions

Enviado por eleland el 2005, Abril 26 - 8:19am.

Great start :)

Would be great to frame this troubleshooting in context, or provide alternatives for different contexts. Is this a completely new client calling for support? In this case, the troubleshooter would need a set of instant audit questions to move through before troubleshooting. Is this a current client, where we provided the system/documentation?

Also it is good to find out what the client expectations are for a solution. Often when a printer does not work, what they want at the moment is one critical print to go through ASAP, not necessarily the whole machine fixed. Knowing their expectations up front for the urgency of the solution and the exact nature of the solution can help a tech support person meet the needs with less stress.

- Eric

Inicie sesión o regístrese para enviar comentarios

Toolbox

Techonology tools and resources

Toolbox

  • Debe loguearse o registrarse para contribuir a este grupo.

Navegación

Inicio de sesión de usuario