No computer system is error-free. None is also perfect without any need for improvements or modifications. Ensuring smooth communication between software producers and users is crucial. The incident reporting and modification proposal system is one of the most important tools in customer relations.
Archman has created a proprietary incident reporting tool based on the NAVIGATOR system. Each user of the system has access to it.
S.Z.O.P
Remote Assistance and Support System (System Zdalnej Obsługi i Pomocy in Polish) is a web-based system maintained on Archman servers. In each instance of the NAVIGATOR system, there is a link to launch this system:
After selecting this option, a new tab will be opened in the browser, containing the incident reporting system. The user will be automatically logged into the service using their NAVIGATOR system credentials, so all reports will be assigned to the user.
The typical appearance of the screen after opening the system. Document names can be written in any language based on the team’s most used language.
The most important option is to add a new error report. A new report can be added by pressing the red button on the screen.
Add error report
After selecting the option for a new report, a new screen will appear. Some options will be automatically filled in, such as the company name, the URL from which SZOP was called, and the browser and Navigator system version. Typically, the user cannot change the company name unless licenses for the system have been purchased for different entities and the user has access to all of them. Information about the URL, browser and system versions is essential for those who will be fixing the errors, so it’s best not to change them. Additionally, it is best to call the SZOP system from the location in the system where the problem occurred – the system operator will have an immediate reference to the system element that caused the problem.
The only required field is the name of the submission. The service team operates in English and Polish so both languages are commonly used. It is best to give a name that means something, both to the user and the person receiving the request in the service team. If we name our ticket simply Error then put ourselves in the role of the system operator who gets a list of a dozen tickets each named Error. In addition, if we check after solving the problems whether everything is okay, will we remember what all our requests named Error were about?
Additional elements to fill in are:
Type: we can choose between Error or Improvement.
Error – something in the system is malfunctioning,
Improvement – the system lacks the required functionality.
Priority: we have three levels of priority to choose from, 1 – the lowest, 3 – the highest. The higher the priority, the faster a given request will be processed. However, it is not a good idea for all requests to have the highest priority. In this situation, you may find that an important fix is waiting because less important ones have also been marked with the highest priority. It is worth mentioning at this point that the speed of response to a ticket depends on many factors. Bug fixes always have a higher priority than improvements so bug reports are handled first. Specific response times also depend on signed service contracts.
Description: A place for a more detailed description of the problem or improvement. Here the user can give all the details of the problem occurrence. It is a good idea to give as many details as possible that will allow you to reproduce the error and diagnose it. It is a good idea to give the circumstances under which the error occurred, the type of data entered, the subsequent actions performed, etc.
Attachments: Here you can add attachments to the notification such as screen images, error messages, etc. It is a good idea to record a video or animation showing the sequence of actions that led to the error. For the sake of system speed, it would be best if the animations were small files, such as animated gifs. In the company we successfully use a free tool ScreenToGif which allows you to record a page from the browser in gif format.
After filling out the form, just click Save and Send to make the submission. Note: after submitting a submission you lose the ability to edit it, any comments can be added only through tab comments.
Submission status
Once a submission is sent, it goes into Archman’s internal submission workflow. The user has the ability to check what is happening with each submission sent. On the home page, we have a section called Your open error reports.
Here you will find all submissions created by the logged-in user. By the status of the submissions, you can identify which task is accepted, rejected, in the process of work, or for acceptance. In addition, you can preview a specific submission by clicking on its name. In the Workflow tab, we can track what has been happening with the submission.
A special type of status is the rejection of a submission. As a rule, the rejecter writes in a comment why the submission was rejected. Rejection does not always indicate that the work will not be done, very often the reason for rejection is the multiple reporting of the same problem by different people. In this case, the first application is considered and the others are rejected with the note Duplicate.
Communication with the company
If there is a need to supplement the notification with new information, you can add a comment to the notification. Add as in any document in the system.
List of submissions – Error reports
The user has the ability to view other users’ submissions. The user can see submissions from his/her company only. After selecting the Error reports option from the application menu, a list of all submissions is shown:
The user has filters to find the submission of interest. It is a good idea to check whether someone else from the company has already submitted a similar ticket. Especially in the case of improvements.
Here you can also check the history of your submissions, just select a name in the filter.
Acceptance of the work
After the contractor completes the work, an email is sent to the user who reported the problem with the information. In the email, there is a direct link to the report. It is also possible to go to the S.Z.O.P system and search for submissions. This is convenient if we have several reports to verify. On the main page of the system, on the right, a list of Error reports awaiting your approval is displayed.
This list of completed jobs is waiting for the user who submitted them. When the user clicks on the Document name, the submission document will open.
As you can see, the user has the standard workflow buttons – here named Submit and Reject. After checking that the work has been done properly and the problem has disappeared, the user can approve the work and close the request or reject it. In the second case, the submission is returned to the company for correction. In case of rejection of the submission, it is advisable to add a comment explaining why the submission was rejected.
The case of rejection of a submission by the service team is particularly confusing and sometimes misleading. If the user disagrees with the decision to reject the submission, they can choose the Reject option (Reject this decision of rejection) – at this point, the submission is resubmitted to the Archman company. It is also advisable to add a comment explaining the reason