Support FAQs: Questions We Ask the Customers

Support FAQs: Questions We Ask the Customers

Let’s face it – Google doesn’t always give us the answers we need. Sometimes you have to contact Support at Datalogics. Having provided technical support for most of my professional life, in one form or another, I thought I would use this blog entry to share a few tips on how to shorten the time it takes for me to identify and resolve problems. The sooner I can identify the problem, the sooner I can find a solution (or, if needed, escalate the problem to Engineering).

For those of you not familiar with Datalogics or its products, we have a number of SDKs that are sold to developers working with PDF and eBook technologies.

Too often, I’ll get an e-mail or a support case created in our portal to the effect of:

  • The API call xyz()  is not working as expected.
  • How do I make the application do some functionality?
  • Something stops working when this happens.

Typically, these appear in the case ticket or my inbox with little additional information. From a support perspective, my first priority is to understand and reproduce the problem. If I can’t reproduce the problem, I can’t test any potential solutions to confirm the problem has been solved.

Support’s Frequently Asked Questions to the Customer:

1. What version are you working with?

By version, I mean Operating System and/or specific release number. Many of Datalogics customers license multiple products on multiple platforms. Too often, however, a customer will report their problem and fail to mention what version of the product they are using. Unless you are evaluating a product, it’s difficult for Support to determine what version a customer is using as we can’t assume that all customers download and run with the most current versions available. Indeed, for many valid reasons, customers often work with versions of our products that are not up-to-date, and can even be a year or two old.

Why is this important:

Step one is usually to reproduce the problem. To do that we need to know what version you’re working with. Step two often is to test the problem with the current release – the problem may already be fixed! If you are working with and/or have tested with the current release, then that helps narrow down the issue and saves time.

2. What Operating System do you see this problem on?

As mentioned earlier, Datalogics supports a large number of platforms. Many customers license more than one. It’s important to know if the problem affects only one OS or all platforms.

Why is this important:

When reporting a problem to Engineering, they usually want to know two things: what version did the problem first appear in and what platforms are affected? When reviewing source code changes in an attempt to track down potential sources of the problem, this information provides useful context to determine if the suspect code might be related to the problem.

3. Can you reproduce the problem, or better yet, provide steps to reproduce it? Even better, do you have a sample that reproduces the problem?

Why is this important:

I won’t go so far as to say “if it’s reproducible, we can fix it” but the odds do go up quite a bit. It’s not enough just to know about a problem – we need something to work on. Even if I think the problem you report is a known issue, it is better to have a sample to work with and verify the issue. This sometimes requires a sample file to work with. Other issues may require sample code we can compile/run and debug as needed.

4. Is this something that used to work, or are you having trouble implementing new functionality?

Why is this important:

It’s not always apparent when a problem is reported or where the problem originated. Are we trying to resolve a problem that end users are encountering, or is it a new feature being added to an existing application? If something previously worked, the support issue often becomes “what’s changed?” When working with new functionality, support can become more of a “how-to” effort.

5. Can you give me some more background? Why are you trying to do this?

Why is this important:

Sometimes we see a customer asking help for an API call, and we are given no context or background. After a few failed attempts, the customer is not able to solve the problem. After some additional discussion, it’s determined that the wrong API was used or perhaps even the wrong approach was taken to solve the particular problem. If the customer provides more background initially, support will likely be able to identify a better solution more quickly.

In Conclusion:

Naturally, each problem is unique and the above questions do not guarantee solutions for all problems. More often than not, supplying the answers to the above questions represent the minimum needed to get started diagnosing any issue. If at some point in the future you are asked one of the five questions above, I hope you’ll understand why and be able to provide us with an answer that will lead us to finding a quick solution to your problem.

 

Leave a Reply

Your email address will not be published. Required fields are marked *