Best Practices

7. Juli 2021 | Michel Rienäcker

It's a question that everyone has asked themselves at one time or another when struggling with their IT software and hoping for rescue help: What's the fastest way to get my support ticket, and thus my problem, processed? That's entirely up to you. The better you present the problem to your IT service provider's support department, the more efficiently it can be handled and resolved. Using a practical CRM example, our Sellmore CRM developer Michel Rienäcker gives tips on what it takes to create the perfect support ticket, make the developers' job easier, and get you to the solution faster.

In the beginning there was the problem. And its description.

In the life of a software developer you can't avoid doing support work. Whether it's problems in your own developments or helping out in the relevant department. When communicating with customers, stumbling blocks appear again and again that are actually avoidable. This starts with problem descriptions that leave big question marks and ends with screenshots that do not allow any conclusion as to where in the CRM the error occurred in the first place. These points ensure that the processing of a ticket is unnecessarily prolonged.

Since I am confronted with these problems again and again, I asked myself the question: Why is this? Why do we keep receiving support requests that automatically include a query upon consideration? 

One answer is that customers often don't understand our view of things and what "tools" we have available. To close this knowledge gap, I will show here with a simple example why information about the time, the user and especially the URL (i.e. the link of the error page) is important.

Typical error message - an example from the developer's perspective

To illustrate the problem, I have written a small page that creates a new person within a company. You can jump to this page by clicking a button in the company summary. In the page I have now deliberately built in an error, so that a certain combination of security settings of the CRM leads to the fact that the person can not be created. 

Now an example that occurs like this again and again: the customer contacts me with the following description of the problem: 

"The CRM does not work. (see attached screenshot)". 

The screenshot shows the following:

Since this is obviously a .net error, I would first look through the log files. These offer, depending on the setting, a different information content. In most cases, however, the logging is set relatively low in order not to fill the hard disk of the CRM server. This is also the case here, so that the following picture emerges:

As you can see here, you can neither tell where the error occurred, nor which user was affected. The only thing that can actually be read out here is the time of the error. Since SQL errors are sometimes hidden behind the error message shown above, I also checked the SQL log. However, this was completely empty. Now there is no other possibility. I have to ask the customer where in the CRM the error occurred. But since there are about 10 other customers waiting for their problem to be solved, I write an e-mail to the customer with the corresponding query. By the time the customer has answered this, another 2-3 days have passed.

Advantages of a good problem description

• Less communication effort
• Faster processing of your ticket
• Efficient problem solving
• Less frustration for all involved

How to better present software problems

Now, what could the customer have done better with his request, and how would the ticket processing have gone then?

1. screenshot of the complete screen

First and foremost, a screenshot would have been good, showing where it was taken. That is, a screenshot of the complete screen including the clock. If the log files are larger, the overview is quickly lost and the supporter is happy about any time information.

Tool-Tip

For all Windows users, the app "Snipping Tool" is a good choice. With this you can easily create, edit and save screenshots. The best way to find it is via the Windows search function. 

But beware, the start screen of Snipping Tool already indicates that the tool will be "moved to another page in a future update" (as of July 2021). But then you can still make your screen clippings as usual with the "Cut and Sketch" function. 

"Cut and sketch": Windows logo key + Shift + S. 

Mac users can use the screenshot function "Screenshot" by default under OS X with the help of the following key combination: [CMD] + [Shift] + [4].

2. URL of the error page

Furthermore, it would have been very important that the called address is sent along. If the URL is examined more closely, it becomes apparent that various information is available here in the form of URL parameters.

• http://example.org/crm/eware.dll/Do?SID=14189268433763&Act=432&Mode=1&CLk=&Key0=1&Key1=35
  &Key2=42&dotnetdll=Blog.dll&dotnetfunc=RunDemoPage

Thus, the Act parameter indicates which functionality in CRM has just been called. In our example there is 432, which means that a .net DLL is listed here. Furthermore, the parameter Key0 shows which is the current dominant key in the URL. In the example URL, Key1 would be the dominant key, meaning that the user was in the context of a company here. Other examples of keys would be Key2 for people, Key3 for addresses, or Key6 for communications. Furthermore, the value determined by parameter Key1 shows the ID of the selected company, in this case 35.

In addition, there are two parameters in the sample URL that specify the .net environment. So here the file "Blog.dll" was called with the function "RunDemoPage". This allows the supporter to determine which record was displayed to the user when the error occurred and which function was called. Thus, errors can already be searched for here in the source code of the corresponding file.

3. Naming the user

Another important aspect is the user who experienced the problem. In our example, it is the case that certain security settings have triggered the problem. If the supporter now tries to recreate the behavior with the admin access, the error will not occur, because: All actions that an administrator performs in CRM are performed without a security context. This means that the administrator can create, view, modify and delete records in any area. He does not experience any restrictions here. The situation is different for normal users. These are subject to the authorization concept of CRM. Knowing which user got the error, the supporter could have set the logs here to maximum and recreated the problem together with the customer. The result would be a meaningful error message in the .net log:

The supporter could now fix the error and review the result with the customer directly. Result: Happy customer = happy supporter.#

4. Description of the action leading to the error

Now, if the problem had not been with the user permissions, it clearly would have needed more information. Specifically, this is the description of the entered data that led to the error. The first question is: Does the problem occur frequently?  

What is annoying in the daily routine can be helpful in troubleshooting. If the problem occurs frequently and can be reproduced, it is advisable to write as detailed a description as possible to reproduce the error. Important are here the steps, which must be accomplished, in order to provoke the problem surely.

At this point, it is again advisable to specify the affected user, since the authorization context also plays an important role here. 

You can ask yourself the following questions when you are posting an error report:

• Where does the problem occur? Always on the same URL (see point 2)? 
• How does it become noticeable?
• Which steps have to be performed in which order to cause the error?

If you follow these points, you will create a good basis for your supporter to solve the problem.

At a glance: 4 checkpoints for your perfect support request

1. screenshot of the complete screen incl. clock 

2. URL of the error page

3. name of the user where the error occurs

4. description of the action performed that led to the error

In conclusion, it is important that you provide us with as much information as possible. The most important information is the address called and the user who received the error message. This is where the highest information content lies.

You want or need to put what you have learned directly into practice? We are happy to help you. 
Click here for Sellmore Support.

No maintenance contract for your CRM system yet? We will be happy to advise and support you here as well. Write to us via our contact form.

The Author: Michel Rienäcker, CRM Developer at Sellmore

Michel has been part of the development team since 2015. His focus is on the Sage CRM system. His motto for all upcoming development tasks: Can't do, won't do! For the Sellmore CRM Blog he gives insights into the daily business of the CRM development world.  

To the Sellmore team

Screenshots ^© Sellmore GmbH