As our networks become more complex, it becomes more difficult to find the cause or causes of a problem, and even more difficult to implement solutions while minimizing the impact on users. Against such a background, it becomes advantageous to follow a more structured approach to troubleshooting. Namely, we advocate the following multi-step approach:

1. Identify the problem: This step involves gathering information, identifying symptoms, and, in some cases, interrogating users. Such an approach should help you to isolate the cause.
2. Formulate a theory of probable cause: Although a problem can have multiple causes, as long as you have exercised due diligence, you should be able to eliminate at least some of the causes and emerge with a theory of probable cause.
3. Test the theory: Now that you have a theory of probable cause, you can test this theory. If you are able to confirm the theory, then you can move on to the next step. Otherwise, you will have to move back to step 2, and consider other possible causes.
4. Establish a plan: Although we have a theory of probable cause that seems to be valid, we still need to formulate a plan for restoring the network to full functionality. This may be a simple procedure if we only have a few users on the network. As we move toward more enterprise-level networks, our plan may well involve scheduling downtime for the network and making sure we abide by whatever formal or informal procedures have been established.
5. Implement the solution: Make the corrective changes, but also test the solution several times, and take into account the fact that early results may be deceptive.
6. Verify system functionality: Keep in mind that the solution might create another problem, and you will need to verify full system functionality before moving on to the next step.
7. Document the problem and solution: Keeping a record of all steps taken when solving the problem, and documenting both successes and failures, will potentially save you time in the long run. In large organizations, knowing who implemented the solution can be important, especially if other technicians have follow-up questions later on.

While you may have encountered the problem yourself, the more people there are using your network, the less likely that this will be the case. If a regular user reports the problem, you may want to provide feedback to the user after asking them questions. It could provide them with an incentive to report problems in the future.