CLC COLLABORATION by Marisa Cavazos

1. Identify the problem | When identifying the problem, resist the urge to start fixing things at this point. To identify the problem: Ask the user to describe the problem or symptoms, check for error messages, or recreate the problem. Establish what has changed. Most often, problems are caused by new hardware, software, or configuration changes. If necessary, ask users to discover what might have changed that could have caused the problem. Remember to inquire about environmental and infrastructure changes that could be relevant. Review system and application logs. Check knowledge base articles, network topology diagrams, the Internet, and any other documents that may provide helpful information.
2. Back up the system | Before making changes to the system, back up user and system data (or make sure a recent backup exists). While some changes can be made without affecting user data, you should back up data to protect against unintentional data loss caused by making changes.
3. Identify possible causes and identify a theory of probable cause | Check for simple, obvious, and common problems first. For example, check power cords, connectors, and common user errors.
4. Test your theory | Test your theory to verify the cause of the problem. If your theory is not correct, examine other possible causes (return to the previous step).At this point, if the problem is caused by simple things like an unplugged system, you can safely take actions to resolve the problem. If the cause is not a simple one, identify the necessary steps to correct the problem. If you cannot identify the cause of the problem, or if it is beyond your ability or responsibility to fix, escalate the problem. Escalation means turning the problem over to someone more capable of handling it. When escalating the problem, be sure to detail the actions you took and the information you have discovered up to this point.
5. Create an action plan | To create an action plan, address the most likely problem and account for side effects of the proposed plan. For example, Will the fix result in significant system downtime? Is the resolution best left for other times of the day? Is there a temporary solution that should be implemented immediately? When side effects have been weighed against the fix and all concerns have been addressed, fix the problem.
6. Test the solution | When you are testing your solution, do the following: Ensure that the problem is fully resolved and that implementation did not cause any new problems. If necessary, take additional actions to prevent the problem from happening again.
7. Ensure satisfaction | After the problem is fixed, ensure the customer's satisfaction and explain what you did to fix the problem. If possible, have the user perform the task to make sure that they understand and accept that the problem has been resolved.
8. Document the solution and process | Documenting the solution and process provides you with a record of what the problem was and what you did to solve the problem. In the future, you can check your documentation to see what has changed or to help you remember the solution to common problems. It will save you time and money when troubleshooting problems.