Recently a rather interesting issue was escalated to me from our overseas support team. In my job as a support engineer, I always search for better ways of doing things. Thus, thinking about how this issue was handled, brought up a number of interesting points about how this issue and by extension, other issues could be handled more efficiently, saving time, frustrations and of course, money. Let's take a look at the details.
The issue as defined by the escalating support tech:
Customer is using a web service to print Crystal Reports.
The application was designed to print labels.
This was a well tested application deployed successfully to a number of customers.
On a new customer site there cropped up an issue with any and all reports (this was confirmed in an email message from the customer).
The following behavior was observed at the new customer site:
Send report A to the printer. Report A starts to print.
Send report B to the printer while report A is still printing.
Report A stops printing and report B starts printing until it is finished. Report A than resumes printing.
Let's take a look at the troubleshooting process of the escalating engineer:
1) Determine exact version of the CR SDK used.
2) Check the printer driver (is it up to date), check the OS, check the code.
3) Provide a simpler code to perform the printing.
3) As the customer's application was rather large, the customer was asked to create a new simple test application (it is always a good idea to approach issues with the KISS paradigm) using saved data reports (this eliminates any database connection variables).
Customer refused to create a new simple application, insisting on a fix, at which point the incident got escalated. Unfortunately, this was after three weeks of cajoling and pleading with the customer to do try the simple application test.
As I read the description from the escalating engineer and scanned all the notes in the incident it was apparent that the escalating engineer was quite puzzled and perhaps incredulous / not believing the customer was correct in his observations. There were also a few notes indication that the engineer could not believe this could be a Crystal SDK issue. I realized that this was a rather unusual behavior however my initial testing could not reproduce the issue, therefore I dove into the nitty gritty details of all communications between the customer and the engineer. The nugget? Well there were two:
1) In my very 1st phone communication with the customer it was determined that the issue was not with any report. The issue was with reports larger than 800 pages only.
2) There was a misunderstanding between the actual issue and the way the engineer understood it. The issue was not that the printer started to print report B. Rather, report A stopped spooling until report B finished spooling. And as the spooling of report A was interrupted, nothing was printing, leading to print slow downs...
This behavior was reproduced easily and contrasted with the behavior of printing non CR report files. The issue was immediately passed over to R&D for a fix.
What are the learnings here?
1) Initial support engineer - Be clear on the issue actually being reported.
2) Initial support engineer - Be open about the possibility of weird or 1st time reported issues.
3) Initial support engineer - Provide the simple application to the customer to test with.
4) Customer - Be accurate a to the actual behavior (all reports? / certain specific reports?)
5) Customer - Be open to suggestions made by support. Creation of, and sharing of a simple test application with the support engineer would have taken no more than 30 minutes, eliminating three weeks of back and forth.
6) Customer - Testing of the application with large reports would have pointed out the issue, before the product was installed at a customer site.
7) Escalated engineer - don't rely on summary of the issue from the escalating engineer. Read all notes in the incident notes. In this case, it would have saved about two days of testing on my part.
| To summarize: |
|---|
| Be clear about the issue |
| Be open about unusual / 1st time issues |
| Be proactive |
| Be accurate in issue description |
| Be a team, co-operate |
| Be in due diligence state |
| Be wary of relying on issue summaries |
