Troubleshooting Guidelines for Nearly Anything

Written by C. Douglas Mays Jr. https://community.spiceworks.com/how_to/109077-troubleshooting-guidelines-for-nearly-anything.

The following is a method I have refined in the course of my career and education, it is geared toward IT helpdesk or IT service company field technicians. It can however be modified to pretty much anything.

Troubleshooting is nothing more than the logical elimination of variables. This guide provides a systematic method of narrowing the scope of a problem and moving forward with resolution.

Many times over the phone the first 30-60 seconds are your chance to LISTEN intently and gather key information, there will be complaining and possibly hostility, move past it and remain objective.

The customer is in touch with you to get resolutions not excuses or apologies. Once they get to a stopping point now begin your Q&A go down the list below before starting any repair or forming a theory of resolution.

Some of the questions below will be answered right away if you were paying attention to the person’s description of the problem. A few of the below questions will be answered as or at least implied you should still run them past customer for verification/approval.

If you need to keep things brief due to time or backlog of cases, advise the customer that you have some questions for them and wherever possible pre-phrase them with statements like: “Yes or no” “How many days weeks or months has this been the case” “How many times do you suspect this has happened…”

Be sure and THANK the customer for their time in answering the interrogatories ahead of time let them know you are nearly done interviewing them. People with broken stuff are not usually very patient and most of us are busy regardless of equipment failure. (continued in step 3)

Who? & Where?
  • Do they have much time to discuss issue?
  • What is the best time to reach them in case of call back?
  • Is this an existing issue? Is there an existing work order or case #?
  • Name, Location of Problem, Phone Numbers, email address, company name. (Preferred method of contacting them?)
What? & When?
  • What is the affected device or resource?
  • Is there an inventory number or serial number that you may have on file to see previous case history?
  • Is the error or problem affecting 1 or more users?
What does the customer want?
  • Desired results?
  • Optional results?
  • Is a workaround acceptable if you cannot resolve immediately in their time frame?
  • If no workaround is possible is there a back out plan should the repair or troubleshooting make things worse?
When did this occur?
  • If recently were there any changes to environment/procedure/materials that may have at least helped cause error?
  • Is there a case history that shows the same pattern of error?
  • What was the previous resolution?
  • Does the previous resolution merely “Band-Aid” or fix the root cause?

At this stage, rephrase the customer’s problem using some of the keywords they used in the description so you can properly phrase your work order or case notes. This should ideally begin to frame the problem and possibly eliminate some variables. Usually at this point the customer doesn’t need to be kept any longer.

If the end user or customer asks you why this happened, it is premature to answer the question unless you are 100% certain what caused the problem, replace “I don’t know” with something else… My preferred go to phrase is: “I’ll need to review my documentation and the information at hand a bit longer before I can give an accurate answer.” “At this stage I would be guessing and I don’t like to guess on matters of this nature.”

Now begin looking into the issue on your own with the tools and training you have, this will ideally add to the case, eliminate variables, and insure you don’t perform unnecessary work. In many cases this can be done while you are asking the above questions or remotely to save time, if not advise the customer of the approximate time that you will need to run through the below diagnostics. Make sure to “under promise and over deliver” whenever you can, this will help establish trust and credibility.

For example if the below steps will take approximately 30 minutes to complete, advise the customer it will be about 45 minutes. This may sound dishonest but is really more geared towards driving satisfaction and managing the end user’s expectations.

  • What is broken?
  • Error messages?
  • Event logs?
  • Results of diagnostic utilities or websites? Examples in IT/Network troubleshooting (Ping, Tracert, Route Print, MXToolbox.com, Who IS Lookup….)
  • Manufacturer hardware diagnostic available? (Are there any error codes produced?)
  • Utilities to monitor performance of device or system?
  • Is error reproducible?
  • On other device with same user account/task/settings?
  • On this computer with different user account/task/settings?
  • Are security privileges an issue? (Example from IT: does user have local admin rights)
  • Does it happen with regular frequency? (if this happens with regularity again case or work order history is where you start your research)
  1. BACKUP ANY DATA THAT YOU MAY NEED LATER OR COULD BE AFFECTED BY REPAIRS. Do not take this for granted!
  2. Check and search your firm’s internal knowledge base and case history notes.
  3. Does your personal skills/experience provide a fix that you already know to be true and tested?
  4. Vendor knowledge base search: (Examples: Microsoft, QuickBooks, JD Edwards, EMC, Dell, HP, Adobe…)
  5. Contact vendor directly for support if available.
  6. Forums dedicated to your trade: (In my trade Spiceworks.com/SS64.com/TomsHardware.com are nice narrow places to begin looking for specific answers.)
  7. Google search: (Be careful not to jump at first resolution you find, try to find at least three similar sources with the identical fix/procedure before you begin working on the problem.)
  8. Inquire with colleagues in your shop for assistance if you are still stuck. Make sure to communicate what you have eliminated already as a possible cause, and what notes and key points you think are relevant. This will be most easily accomplished by taking detailed notes, make sure to attach diagnostic results to your case if possible for your peers to review.
  9. Follow up with supervisor or escalation authority if your company has one, even if the solution is obvious and should be simple if you are this deep into a problem they need to know to make sure that service level agreements are being met and that any other customer facing issues are being adequately covered.
  10. Communicate to customer what you intend to do to fix the issue (keep it simple), the project or procedure’s risk, and what the blackout plan is if the repair doesn’t work as well as where the blackout plan will leave things.
  1. Have customer test device or system and make sure the results are to their liking.
  2. Remove any workarounds or other “clutter” from any trial and error during repairs which could lead to confusing the customer after you’re done.
  3. If you saved a backup of any data, make sure the data is back in place to customer’s satisfaction.
  4. If neccessary, encrypt the backup you prepared in section 6 step 1 above, mark with case#, and leave with customer in case something was left out.
  5. Verify documentation is up to date, and easily discernible by the next person that may need it, have colleagues in your shop proof the “how to” docs.
  6. If documentation is required for customer, it must be easy to read, consider screenshots and or video with time stamps for when the key points are emphasized.
  7. Get customer to sign off on repair or project provided all criteria are met to their satisfaction.
  8. THANK THE CUSTOMER for their patience, time, and the opportunity they provided.
  9. Once matter is resolved:
Why? & How?
  • Why did the problem occur?
  • How can we prevent the problem from happening in the future?
  • Is the root cause a training issue for your shop or the customer?
  • Are there training resources available to sell to the customer or give them for free as an added value?

At this point forward suggestions/findings to appropriate supervisors and/or quality assurance people referencing your case number or info specific to any affected departments. Changes to procedure or customer environment may need to be documented in a separate change order or internal case.

The method above is my usual approach to solving most technical and even non technical problems. Often times it is helpful to have such a checklist so that I can make sure I covered all possible variables and solutions.

I hope you find this helpful.

References Original document:

The following is a method I have refined in the course of my career and education, it is geared toward IT helpdesk or IT service company field technicians. It can however be modified to pretty much anything.

Troubleshooting is nothing more than the logical elimination of variables. This guide provides a systematic method of narrowing the scope of a problem and moving forward with resolution.

Many times over the phone the first 30-60 seconds are your chance to LISTEN intently and gather key information, there will be complaining and possibly hostility, move past it and remain objective.

The customer is in touch with you to get resolutions not excuses or apologies. Once they get to a stopping point now begin your Q&A go down the list below before starting any repair or forming a theory of resolution.

Some of the questions below will be answered right away if you were paying attention to the person’s description of the problem. A few of the below questions will be answered as or at least implied you should still run them past customer for verification/approval.

If you need to keep things brief due to time or backlog of cases, advise the customer that you have some questions for them and wherever possible pre-phrase them with statements like: “Yes or no” “How many days weeks or months has this been the case” “How many times do you suspect this has happened…”

Be sure and THANK the customer for their time in answering the interrogatories ahead of time let them know you are nearly done interviewing them. People with broken stuff are not usually very patient and most of us are busy regardless of equipment failure. (continued in step 3)

Who? & Where?
  • Do they have much time to discuss issue?
  • What is the best time to reach them in case of call back?
  • Is this an existing issue? Is there an existing work order or case #?
  • Name, Location of Problem, Phone Numbers, email address, company name. (Preferred method of contacting them?)
What? & When?
  • What is the affected device or resource?
  • Is there an inventory number or serial number that you may have on file to see previous case history?
  • Is the error or problem affecting 1 or more users?
What does the customer want?
  • Desired results?
  • Optional results?
  • Is a workaround acceptable if you cannot resolve immediately in their time frame?
  • If no workaround is possible is there a back out plan should the repair or troubleshooting make things worse?
When did this occur?
  • If recently were there any changes to environment/procedure/materials that may have at least helped cause error?
  • Is there a case history that shows the same pattern of error?
  • What was the previous resolution?
  • Does the previous resolution merely “Band-Aid” or fix the root cause?

At this stage, rephrase the customer’s problem using some of the keywords they used in the description so you can properly phrase your work order or case notes. This should ideally begin to frame the problem and possibly eliminate some variables. Usually at this point the customer doesn’t need to be kept any longer.

If the end user or customer asks you why this happened, it is premature to answer the question unless you are 100% certain what caused the problem, replace “I don’t know” with something else… My preferred go to phrase is: “I’ll need to review my documentation and the information at hand a bit longer before I can give an accurate answer.” “At this stage I would be guessing and I don’t like to guess on matters of this nature.”

Now begin looking into the issue on your own with the tools and training you have, this will ideally add to the case, eliminate variables, and insure you don’t perform unnecessary work. In many cases this can be done while you are asking the above questions or remotely to save time, if not advise the customer of the approximate time that you will need to run through the below diagnostics. Make sure to “under promise and over deliver” whenever you can, this will help establish trust and credibility.

For example if the below steps will take approximately 30 minutes to complete, advise the customer it will be about 45 minutes. This may sound dishonest but is really more geared towards driving satisfaction and managing the end user’s expectations.

  • What is broken?
  • Error messages?
  • Event logs?
  • Results of diagnostic utilities or websites? Examples in IT/Network troubleshooting (Ping, Tracert, Route Print, MXToolbox.com, Who IS Lookup….)
  • Manufacturer hardware diagnostic available? (Are there any error codes produced?)
  • Utilities to monitor performance of device or system?
  • Is error reproducible?
  • On other device with same user account/task/settings?
  • On this computer with different user account/task/settings?
  • Are security privileges an issue? (Example from IT: does user have local admin rights)
  • Does it happen with regular frequency? (if this happens with regularity again case or work order history is where you start your research)
  1. BACKUP ANY DATA THAT YOU MAY NEED LATER OR COULD BE AFFECTED BY REPAIRS. Do not take this for granted!
  2. Check and search your firm’s internal knowledge base and case history notes.
  3. Does your personal skills/experience provide a fix that you already know to be true and tested?
  4. Vendor knowledge base search: (Examples: Microsoft, QuickBooks, JD Edwards, EMC, Dell, HP, Adobe…)
  5. Contact vendor directly for support if available.
  6. Forums dedicated to your trade: (In my trade Spiceworks.com/SS64.com/TomsHardware.com are nice narrow places to begin looking for specific answers.)
  7. Google search: (Be careful not to jump at first resolution you find, try to find at least three similar sources with the identical fix/procedure before you begin working on the problem.)
  8. Inquire with colleagues in your shop for assistance if you are still stuck. Make sure to communicate what you have eliminated already as a possible cause, and what notes and key points you think are relevant. This will be most easily accomplished by taking detailed notes, make sure to attach diagnostic results to your case if possible for your peers to review.
  9. Follow up with supervisor or escalation authority if your company has one, even if the solution is obvious and should be simple if you are this deep into a problem they need to know to make sure that service level agreements are being met and that any other customer facing issues are being adequately covered.
  10. Communicate to customer what you intend to do to fix the issue (keep it simple), the project or procedure’s risk, and what the blackout plan is if the repair doesn’t work as well as where the blackout plan will leave things.
  1. Have customer test device or system and make sure the results are to their liking.
  2. Remove any workarounds or other “clutter” from any trial and error during repairs which could lead to confusing the customer after you’re done.
  3. If you saved a backup of any data, make sure the data is back in place to customer’s satisfaction.
  4. If neccessary, encrypt the backup you prepared in section 6 step 1 above, mark with case#, and leave with customer in case something was left out.
  5. Verify documentation is up to date, and easily discernible by the next person that may need it, have colleagues in your shop proof the “how to” docs.
  6. If documentation is required for customer, it must be easy to read, consider screenshots and or video with time stamps for when the key points are emphasized.
  7. Get customer to sign off on repair or project provided all criteria are met to their satisfaction.
  8. THANK THE CUSTOMER for their patience, time, and the opportunity they provided.
  9. Once matter is resolved:
Why? & How?
  • Why did the problem occur?
  • How can we prevent the problem from happening in the future?
  • Is the root cause a training issue for your shop or the customer?
  • Are there training resources available to sell to the customer or give them for free as an added value?

At this point forward suggestions/findings to appropriate supervisors and/or quality assurance people referencing your case number or info specific to any affected departments. Changes to procedure or customer environment may need to be documented in a separate change order or internal case.

The method above is my usual approach to solving most technical and even non technical problems. Often times it is helpful to have such a checklist so that I can make sure I covered all possible variables and solutions.

I hope you find this helpful.

References Original document:

The following is a method I have refined in the course of my career and education, it is geared toward IT helpdesk or IT service company field technicians. It can however be modified to pretty much anything.

Troubleshooting is nothing more than the logical elimination of variables. This guide provides a systematic method of narrowing the scope of a problem and moving forward with resolution.

Many times over the phone the first 30-60 seconds are your chance to LISTEN intently and gather key information, there will be complaining and possibly hostility, move past it and remain objective.

The customer is in touch with you to get resolutions not excuses or apologies. Once they get to a stopping point now begin your Q&A go down the list below before starting any repair or forming a theory of resolution.

Some of the questions below will be answered right away if you were paying attention to the person’s description of the problem. A few of the below questions will be answered as or at least implied you should still run them past customer for verification/approval.

If you need to keep things brief due to time or backlog of cases, advise the customer that you have some questions for them and wherever possible pre-phrase them with statements like: “Yes or no” “How many days weeks or months has this been the case” “How many times do you suspect this has happened…”

Be sure and THANK the customer for their time in answering the interrogatories ahead of time let them know you are nearly done interviewing them. People with broken stuff are not usually very patient and most of us are busy regardless of equipment failure. (continued in step 3)

Who? & Where?
  • Do they have much time to discuss issue?
  • What is the best time to reach them in case of call back?
  • Is this an existing issue? Is there an existing work order or case #?
  • Name, Location of Problem, Phone Numbers, email address, company name. (Preferred method of contacting them?)
What? & When?
  • What is the affected device or resource?
  • Is there an inventory number or serial number that you may have on file to see previous case history?
  • Is the error or problem affecting 1 or more users?
What does the customer want?
  • Desired results?
  • Optional results?
  • Is a workaround acceptable if you cannot resolve immediately in their time frame?
  • If no workaround is possible is there a back out plan should the repair or troubleshooting make things worse?
When did this occur?
  • If recently were there any changes to environment/procedure/materials that may have at least helped cause error?
  • Is there a case history that shows the same pattern of error?
  • What was the previous resolution?
  • Does the previous resolution merely “Band-Aid” or fix the root cause?

At this stage, rephrase the customer’s problem using some of the keywords they used in the description so you can properly phrase your work order or case notes. This should ideally begin to frame the problem and possibly eliminate some variables. Usually at this point the customer doesn’t need to be kept any longer.

If the end user or customer asks you why this happened, it is premature to answer the question unless you are 100% certain what caused the problem, replace “I don’t know” with something else… My preferred go to phrase is: “I’ll need to review my documentation and the information at hand a bit longer before I can give an accurate answer.” “At this stage I would be guessing and I don’t like to guess on matters of this nature.”

Now begin looking into the issue on your own with the tools and training you have, this will ideally add to the case, eliminate variables, and insure you don’t perform unnecessary work. In many cases this can be done while you are asking the above questions or remotely to save time, if not advise the customer of the approximate time that you will need to run through the below diagnostics. Make sure to “under promise and over deliver” whenever you can, this will help establish trust and credibility.

For example if the below steps will take approximately 30 minutes to complete, advise the customer it will be about 45 minutes. This may sound dishonest but is really more geared towards driving satisfaction and managing the end user’s expectations.

  • What is broken?
  • Error messages?
  • Event logs?
  • Results of diagnostic utilities or websites? Examples in IT/Network troubleshooting (Ping, Tracert, Route Print, MXToolbox.com, Who IS Lookup….)
  • Manufacturer hardware diagnostic available? (Are there any error codes produced?)
  • Utilities to monitor performance of device or system?
  • Is error reproducible?
  • On other device with same user account/task/settings?
  • On this computer with different user account/task/settings?
  • Are security privileges an issue? (Example from IT: does user have local admin rights)
  • Does it happen with regular frequency? (if this happens with regularity again case or work order history is where you start your research)
  1. BACKUP ANY DATA THAT YOU MAY NEED LATER OR COULD BE AFFECTED BY REPAIRS. Do not take this for granted!
  2. Check and search your firm’s internal knowledge base and case history notes.
  3. Does your personal skills/experience provide a fix that you already know to be true and tested?
  4. Vendor knowledge base search: (Examples: Microsoft, QuickBooks, JD Edwards, EMC, Dell, HP, Adobe…)
  5. Contact vendor directly for support if available.
  6. Forums dedicated to your trade: (In my trade Spiceworks.com/SS64.com/TomsHardware.com are nice narrow places to begin looking for specific answers.)
  7. Google search: (Be careful not to jump at first resolution you find, try to find at least three similar sources with the identical fix/procedure before you begin working on the problem.)
  8. Inquire with colleagues in your shop for assistance if you are still stuck. Make sure to communicate what you have eliminated already as a possible cause, and what notes and key points you think are relevant. This will be most easily accomplished by taking detailed notes, make sure to attach diagnostic results to your case if possible for your peers to review.
  9. Follow up with supervisor or escalation authority if your company has one, even if the solution is obvious and should be simple if you are this deep into a problem they need to know to make sure that service level agreements are being met and that any other customer facing issues are being adequately covered.
  10. Communicate to customer what you intend to do to fix the issue (keep it simple), the project or procedure’s risk, and what the blackout plan is if the repair doesn’t work as well as where the blackout plan will leave things.
  1. Have customer test device or system and make sure the results are to their liking.
  2. Remove any workarounds or other “clutter” from any trial and error during repairs which could lead to confusing the customer after you’re done.
  3. If you saved a backup of any data, make sure the data is back in place to customer’s satisfaction.
  4. If neccessary, encrypt the backup you prepared in section 6 step 1 above, mark with case#, and leave with customer in case something was left out.
  5. Verify documentation is up to date, and easily discernible by the next person that may need it, have colleagues in your shop proof the “how to” docs.
  6. If documentation is required for customer, it must be easy to read, consider screenshots and or video with time stamps for when the key points are emphasized.
  7. Get customer to sign off on repair or project provided all criteria are met to their satisfaction.
  8. THANK THE CUSTOMER for their patience, time, and the opportunity they provided.
  9. Once matter is resolved:
Why? & How?
  • Why did the problem occur?
  • How can we prevent the problem from happening in the future?
  • Is the root cause a training issue for your shop or the customer?
  • Are there training resources available to sell to the customer or give them for free as an added value?

At this point forward suggestions/findings to appropriate supervisors and/or quality assurance people referencing your case number or info specific to any affected departments. Changes to procedure or customer environment may need to be documented in a separate change order or internal case.

The method above is my usual approach to solving most technical and even non technical problems. Often times it is helpful to have such a checklist so that I can make sure I covered all possible variables and solutions.

I hope you find this helpful.

References Original document:

The following is a method I have refined in the course of my career and education, it is geared toward IT helpdesk or IT service company field technicians. It can however be modified to pretty much anything.

Troubleshooting is nothing more than the logical elimination of variables. This guide provides a systematic method of narrowing the scope of a problem and moving forward with resolution.

Many times over the phone the first 30-60 seconds are your chance to LISTEN intently and gather key information, there will be complaining and possibly hostility, move past it and remain objective.

The customer is in touch with you to get resolutions not excuses or apologies. Once they get to a stopping point now begin your Q&A go down the list below before starting any repair or forming a theory of resolution.

Some of the questions below will be answered right away if you were paying attention to the person’s description of the problem. A few of the below questions will be answered as or at least implied you should still run them past customer for verification/approval.

If you need to keep things brief due to time or backlog of cases, advise the customer that you have some questions for them and wherever possible pre-phrase them with statements like: “Yes or no” “How many days weeks or months has this been the case” “How many times do you suspect this has happened…”

Be sure and THANK the customer for their time in answering the interrogatories ahead of time let them know you are nearly done interviewing them. People with broken stuff are not usually very patient and most of us are busy regardless of equipment failure. (continued in step 3)

Who? & Where?
  • Do they have much time to discuss issue?
  • What is the best time to reach them in case of call back?
  • Is this an existing issue? Is there an existing work order or case #?
  • Name, Location of Problem, Phone Numbers, email address, company name. (Preferred method of contacting them?)
What? & When?
  • What is the affected device or resource?
  • Is there an inventory number or serial number that you may have on file to see previous case history?
  • Is the error or problem affecting 1 or more users?
What does the customer want?
  • Desired results?
  • Optional results?
  • Is a workaround acceptable if you cannot resolve immediately in their time frame?
  • If no workaround is possible is there a back out plan should the repair or troubleshooting make things worse?
When did this occur?
  • If recently were there any changes to environment/procedure/materials that may have at least helped cause error?
  • Is there a case history that shows the same pattern of error?
  • What was the previous resolution?
  • Does the previous resolution merely “Band-Aid” or fix the root cause?

At this stage, rephrase the customer’s problem using some of the keywords they used in the description so you can properly phrase your work order or case notes. This should ideally begin to frame the problem and possibly eliminate some variables. Usually at this point the customer doesn’t need to be kept any longer.

If the end user or customer asks you why this happened, it is premature to answer the question unless you are 100% certain what caused the problem, replace “I don’t know” with something else… My preferred go to phrase is: “I’ll need to review my documentation and the information at hand a bit longer before I can give an accurate answer.” “At this stage I would be guessing and I don’t like to guess on matters of this nature.”

Now begin looking into the issue on your own with the tools and training you have, this will ideally add to the case, eliminate variables, and insure you don’t perform unnecessary work. In many cases this can be done while you are asking the above questions or remotely to save time, if not advise the customer of the approximate time that you will need to run through the below diagnostics. Make sure to “under promise and over deliver” whenever you can, this will help establish trust and credibility.

For example if the below steps will take approximately 30 minutes to complete, advise the customer it will be about 45 minutes. This may sound dishonest but is really more geared towards driving satisfaction and managing the end user’s expectations.

  • What is broken?
  • Error messages?
  • Event logs?
  • Results of diagnostic utilities or websites? Examples in IT/Network troubleshooting (Ping, Tracert, Route Print, MXToolbox.com, Who IS Lookup….)
  • Manufacturer hardware diagnostic available? (Are there any error codes produced?)
  • Utilities to monitor performance of device or system?
  • Is error reproducible?
  • On other device with same user account/task/settings?
  • On this computer with different user account/task/settings?
  • Are security privileges an issue? (Example from IT: does user have local admin rights)
  • Does it happen with regular frequency? (if this happens with regularity again case or work order history is where you start your research)
  1. BACKUP ANY DATA THAT YOU MAY NEED LATER OR COULD BE AFFECTED BY REPAIRS. Do not take this for granted!
  2. Check and search your firm’s internal knowledge base and case history notes.
  3. Does your personal skills/experience provide a fix that you already know to be true and tested?
  4. Vendor knowledge base search: (Examples: Microsoft, QuickBooks, JD Edwards, EMC, Dell, HP, Adobe…)
  5. Contact vendor directly for support if available.
  6. Forums dedicated to your trade: (In my trade Spiceworks.com/SS64.com/TomsHardware.com are nice narrow places to begin looking for specific answers.)
  7. Google search: (Be careful not to jump at first resolution you find, try to find at least three similar sources with the identical fix/procedure before you begin working on the problem.)
  8. Inquire with colleagues in your shop for assistance if you are still stuck. Make sure to communicate what you have eliminated already as a possible cause, and what notes and key points you think are relevant. This will be most easily accomplished by taking detailed notes, make sure to attach diagnostic results to your case if possible for your peers to review.
  9. Follow up with supervisor or escalation authority if your company has one, even if the solution is obvious and should be simple if you are this deep into a problem they need to know to make sure that service level agreements are being met and that any other customer facing issues are being adequately covered.
  10. Communicate to customer what you intend to do to fix the issue (keep it simple), the project or procedure’s risk, and what the blackout plan is if the repair doesn’t work as well as where the blackout plan will leave things.
  1. Have customer test device or system and make sure the results are to their liking.
  2. Remove any workarounds or other “clutter” from any trial and error during repairs which could lead to confusing the customer after you’re done.
  3. If you saved a backup of any data, make sure the data is back in place to customer’s satisfaction.
  4. If neccessary, encrypt the backup you prepared in section 6 step 1 above, mark with case#, and leave with customer in case something was left out.
  5. Verify documentation is up to date, and easily discernible by the next person that may need it, have colleagues in your shop proof the “how to” docs.
  6. If documentation is required for customer, it must be easy to read, consider screenshots and or video with time stamps for when the key points are emphasized.
  7. Get customer to sign off on repair or project provided all criteria are met to their satisfaction.
  8. THANK THE CUSTOMER for their patience, time, and the opportunity they provided.
  9. Once matter is resolved:
Why? & How?
  • Why did the problem occur?
  • How can we prevent the problem from happening in the future?
  • Is the root cause a training issue for your shop or the customer?
  • Are there training resources available to sell to the customer or give them for free as an added value?

At this point forward suggestions/findings to appropriate supervisors and/or quality assurance people referencing your case number or info specific to any affected departments. Changes to procedure or customer environment may need to be documented in a separate change order or internal case.

The method above is my usual approach to solving most technical and even non technical problems. Often times it is helpful to have such a checklist so that I can make sure I covered all possible variables and solutions.

I hope you find this helpful.

References: https://community.spiceworks.com/how_to/109077-troubleshooting-guidelines-for-nearly-anything

  • other/troubleshooting_guidelines.txt
  • Last modified: 2019/03/15 14:53
  • by ericclaus