Source mc mcse Certification Resources

Gather Information on the Problem
In a contact center network, problems are typically discovered and reported by one of the following types of users:

• External customers dialing into a call center to order products, obtain customer service, and so forth.
• Internal agents receiving incoming calls from a call queue or initiating outbound collection calls to customers.
• Internal users using administrative phones to call employees in other company locations or PSTN destinations, and perform basic actions such as call transfers and dialing into conferences.

As the network administrator, you must collect sufficient information from these users to allow you to isolate the problem. Detailed, accurate information will make this task easier. As you turn up your network, you may consider putting these questions in an on-line form. A form will encourage users to provide more details about the problem and also put them into the habit of looking for particular error messages and indicators. Capturing the information electronically will also permit you to retrieve and re-examine this information in the future, should the problem repeat itself.

Identify The Affected Area
Determine if the problem is limited to one workstation, or several workstations, one server, one segment, or the entire network. If only one person is experiencing a certain problem, the problem is most likely at the workstation. If groups of workstations are affected, the problem might lie at a part of the network that users all have in common, such as a particular software application or database, a server, the network segment, or the network configuration.

Determine If Anything Has Changed
To determine what has changed, ask question such as:

• Could you do this task before? If this is a new task, perhaps the user needs different sysetm permissions, or additional hardware of software.
• If you could do it before, when did you first notice you couldn’t do it anymore? Try do find out what happened just before the problem came up, or at least try to pinpoint the time, since the source of the problem might be related to other changes elsewhere on the network.
• What has changed since the last time you were able to do this task? Users can give you information about events that mightaffect their local systems. You can help them with leading questions such as, ”Did someone add something to your computer?” or “Did you do something differently this time?”.

Establish The Most Probable Cause
T o establish the most probable cause, use a systematic approach. Eliminate possible causes, starting with the obvious and simplest one and working back through other causes. Do not overlook straightforward and smple corrections that can fix a range of problems and do not cost much time or effort to try. You might find you can resolve the issue on the spot.

Determine If Escalation Is Necessary
While troubleshooting a network problem, you might find the cause of the problem is not an issue that can be resolved over the phone or at the user’s desktop. It may be necessary to contact a fellow employee who has specialized knowledge, or a more senior administrator with the appropriate permissions and authoration. In these cases, the problem should be escalated to the appropriate personel to be resolved as quickly as possible. Create an Action Plan and Solution, Identifying Potential Effect Once you have determined the probable cause, you should create an action plan before changes are made, detailing each step taken while attempting to resolve the issue. One should also be certain that the original state (before troubleshooting) can be returned to in case things do not go as planned. Also consider the how the plan will affect the user or other aspects of the network. Thinking ahead can help ensure productivity doesn’t suffer and that downtime is minimized.

Implement and Test the Solution

Implement the action plan step by step to fix the problem. If multiple changes are made at once, you will be unable to verify exactly what effect each adjustment had. Be sure to document each step because you can lose sight of what you have tried in complex troubleshooting scenarios. Test the solution. Make sure the solution implemented actually solves the problem and didn’t cause any new ones. Use several options and situations to conduct the tests. Sometimes testing over time is needed to ensure the solution is the correct one.

Identify the Results and Effects of the Solution
Verify that the user agrees that the problem is solved before you proceed with final documentation and closing the request. Even if the problem is solved, and the solution was well thought- out and documented, there might cascading effects elsewhere on the local system or on the network. Test for this before closing out the issue. If a major change was made, it is advisable to continue monitoring and testing for several days or even weeks after the problem appears to be resolved.

Document the Process and Solution
Document the problem and process used to arrived at the solution. Maintain the records as part of an overall documentation plan. This will provide and ever-growing database of information specific to your network and also it will be valuable reference material for future troubleshooting instances….especially if the problem is specific to the organization. Creating a troubleshooting template with required information included in all trouble reports will ensure all trouble reports are accurate and consistent no matter who completes them.

Want more information on how to become CompTIA Net+ Certified? Learn more!

Also published on Medium.