Support and Troubleshooting

Asking the right question

First, let's ask the 'wrong question'

Here are some quick tips on how to get the right answer you need, by asking the 'right question'.

Imagine this situation:

You then ask the master mechanic at your shop:

The local master mechanic then proceeds to spend 30 minutes training you on this topic. Then you check the pressure it is correct. Now what?

Next, let's ask the 'right question'

There is never an exact way to find precisely the 'right question', but we can start by 'backing out of the weeds'.  Or zooming out on the problem. 

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

The master mechanic thinks about this for 30 seconds and responds with

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.

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.

What to do if a call has failed to connect, or other call-related issues occur.

The following points of information represent what is referred to as a "Call Example".  Call Examples are a key component in troubleshooting just about *any* type of issue, disruption, or problem that might occur on your communications system.

Please collect these three Critical Details about your call so that the technical support team can look into your issue

1) Date and Time of occurrence

  • If you can, please try and notate the time to the closest minute that the issue occurred

2) What phone number or extension was being called

  • If you are calling an internal extension, please note the extension being called
  • If you calling an outside number, please note the full phone number
  • If you are calling another branch or office location, please note the name of the location you intend to reach as well as the number dialed

3) The extension or number that the call was placed from

  • If this call was placed from inside the office or otherwise is part of the office system, note the extension used
  • If this call was placed from outside the office, please provide the full phone number (CallerID) of the received call

Also, please try to be as detailed as possible and provide the following Additional Information if possible.

  • Action: What is the task or action that was attempted? Example: "We tried to access voicemail at the Main Street Office from the Maple Street Office"
  • Expected: What was the expected behavior? Example: "We expected to be able to access the voicemail box of extension 155"
  • Result: What was the actual behavior? Example: "We experienced an odd tone, it was three beeps and then the call hung up, then the announcement told us that Error 55 has occurred"

Here are some example reports

Example One - The Great Example

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.

Example Two - The "OK" Example 

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.

Example Three - The Poor Example

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.