Don't focus on a specific detail of the problem. Instead, focus on a high-level view with as much detail as possible
What is our ultimate goal? We want to fix shifting What do we know so far? Not much... shifting doesn't work. But wait... we **DO** know more information... if we change our perspective and how we think about this problem You now tell the master mechanic - I have a problem shifting in this vehicle - The issue happens when I'm going from neutral to drive - The shifter lever does not move The master mechanic thinks about this for 30 seconds and responds with - Check the connecting rod from the shifter to the transmission - You check the rod and it's broken. - You replace the rod and shifting works perfectly now In this scenario, while you thought the issue was transmission-fluid related from doing the research ... the answer clearly lies in a different direction entirely. The focus was too much on a 'specific thing' rather than the overall picture. ## Moral of the story When we asked the 'right question' we got the answer almost immediately. Of course not every situation is as cut and dry and as straightforward as this is... but if you ask your mentor, project lead, or other resource the 'wrong question' you're going to still be miles away from solving your problem because it's too detailed... to deep in the rabbit hole to be useful for solving your problem. While never a bad idea to get extra training... extra training can always be done (and should be done) during 'downtime' when customers aren't waiting for jobs to be completed. The ultimate goal is to fix the problem for the customer. Detailed learning and understanding are great, but it's important to focus on those aspects *after* the problem is solved when you have a relaxing time to absorb and learn. ## Examples **Wrong question:** How do I make the swap file smaller? **Right Question:** I need to clean up disk space, what large files should I delete first? **Analysis:** While you might think shrinking the huge swap file is a great way to save disk space... perhaps the real problem is the 500 gigabytes of files in 'Downloads' **Wrong question:** How do I make this phone register more often? **Right Question:** I'm having a problem with a phone registration dropping out... the user can't make calls after 5 minutes. How can we troubleshoot the network? **Analysis:** Registering more often won't fix the problem if it's a broken or misconfigured network. This is why backing out to the 'high level' question is better **Wrong question:** How do I turn off the blinking light on the phone? **Right Question:** I have a phone, where every time the user gets a voicemail, the light goes on... they would rather get an email for new voicemail messages. **Analysis:** The 'Blinking light' could be related to many possible reasons. Lights blink during startup, during configuration reload, for warnings, or for voicemail. # Collecting Call Examples ## Overview - Help Us, Help You When encountering a call behavior issue, routing issue, dialing issue, and just about any other communications-related issue, it's very important to note some key points of information. This will help the technical support team to diagnose the problem.| **Reporter Notes** | **Analysis** |
| Issue occurred at 12:25pm Eastern Time on June 5th when calling \*123 from extension 1000 | This is a **perfect** start of a Call Example report. It concisely describes all three critical details of a Call Example. |
| Tried calling into voicemail in order to change a greeting. Twice we got a busy signal, and two more times we got a weird buzzing. The fifth time we got in and changed the greeting. | This is a **great** level of detail without a lot of writing! The reporter concisely described what they were trying to do (the **Action**), what they **Expected** (access to voicemail for the greeting change). The reporter stated how many times they tried to do the action (this can be incredibly helpful to the support staff). The reporter also stated what occurred when each attempt was taken (the **Result**). It's important to describe how the call failed. The technicians working on your issue will be keyed into the problem area by error codes and sounds. Buzzing may very well indicate a wire has been physically damaged. Beep codes from the system or your service provider will give clues to the source of the problem. |
This type of report may result in *delays* in resolving the issue while the support team shuffles through troubleshooting data to locate specifics.
Suppose a reporter was having the same problem as described in Example One, but reported the problem in this way:| **Reporter Notes** | **Analysis** |
| Issue occurred at around 12:00pm in June 5th when calling \*123 from extension 1000 | This is an "**OK**" start of a Call Example report. The time is vague, but with the date, the technical support staff can locate the problematic call with some searching and poking around to find the specific calls that started at 12:25. Also, the time zone has not been specified in this example. Depending on where the reporter is located and where the staff is located, there may be some guessing involved in locating the correct Time Zone to apply when searching the system data. |
| Voicemail had a problem, we were disconnected a few times, but we did get through once. | This note provides some detail. The reporter has noted the **Action** (voicemail), and the **Result**, but didn't relay the **Expected --** Why is the **Expected** item important you might ask? If the support team understands what you are trying to accomplish, they can suggest Alternative ways to complete the goal while they work on the issue. The support team immediate response to Example One would be to use the web portal to change the greeting in the meantime, while we troubleshoot the issue dialing into voicemail. Also, the reporter in this example did not give any detail on *which* attempts were failures and which attempts were successful. When the support team is working on the reported issue from Example One, they may be able to locate the issue within **minutes**, given the specifics, since the team knows exactly what to look for. When the support team is working on the issue reported from Example Two, it could take an hour or more to sift through data, and system reports to locate the problem. |
This type of report will most certainly result in a *serious delay* in resolving the issue that has been reported. The support team may take hours or days to locate the calls in question
| **Reporter Notes** | **Analysis** |
| One of the phones called voicemail, the problem was during the first week of June. | This is a **poor** start of a Call Example report. There is a vague starting point of investigation (first week of June). There is no time listed, and no extension listed. The support team might not be able to locate the problematic call if this phone is part of a large system. Depending on the size of your installed system, sifting through hundreds, thousands, or tens of thousands of calls over a period of a week is not going to be an effective way to solve this problem. Also, the reporter has not defined what the problem is. The support staff will not know what to look for! It is possible that the support team may be **unable** to investigate or resolve this issue. |
| (No **Additional Information** supplied) | This reported example provides very little detail. The reporter has noted the **Action** (voicemail) and a very vague **Result** (a problem). Depending on the size of your installed system -- Every minute, hundreds or thousands of data points are recorded on the communications system. Given this level of detail that is recorded, there may be no realistic way to locate the problem. Without ample information, the support team may decline to work on this issue until more information is available. |