Work on assets in the native mobile application “Itilium +” will continue
In the previous announcement for the release of 5.0.0.5, the Itilium development team promised to add work with requests and assets in the native mobile application in the next 2-3 releases.
Work with requests was added in release 5.0.0.5 , and the assets are only being worked on, which were discussed earlier. Planned to be completed by release 5.0.0.6.
When working with assets in a mobile application, the service engineer fills in only the asset data. The mechanism for scanning barcodes on the assets themselves helps him in this. These data are transmitted to the main information base of the “large system” Itilium in the form of a pre-filled document. And, if earlier, in order to completely fill the document with data and carry it out, the specialist had to return to a stationary workplace, now these processes are planned to be implemented remotely.
Custom widgets for the main page of Service Desk Itilium
In most cases, aggregated totals are much better suited to describe work tasks than lists. For example, when opening a desktop application, it is more convenient for a specialist to immediately see that 3 orders are assigned to him and his work group has 5 unassigned orders. At the same time, the tasks themselves can not be shown right away – on the first screen, it is enough to see only their number. It is relevant when a lot of widgets are displayed on the first page of the application: “Group outfits” and “My outfits”, “My calls” and “Group calls”, “My calls by status”, “My approvals”. Similar functionality with the addition of widgets has already been implemented in 1C: Document Management.
In the release of Itilium 5.0.0.6, the developers of Desnol Soft plan to bring these widgets to the main page of the system. Clicking on a specific option, such as “My Outfits”, will open more detailed information. In this case, for each user it will be possible to install its own set of start page widgets.
Schedules for the provision of services depending on the priority in the Itilium system
Many companies that use the Itilium system have agreements with their service consumers: if the client wants the service to be provided to him faster, then he chooses a higher priority when concluding a service level agreement. At the same time, the response time and the time for resolving the incident are reduced, and the schedule for the provision of the service itself changes. For example, support for the Internet service is provided from 8:00 to 20:00 with medium priority. For critical cases, you can request high priority support with a 24/7 schedule. It costs more, but sometimes it is needed.
Now in the Itilium system it is not possible to specify different schedules for the provision of services for different priorities. In release 5.0.0.6, a mechanism will be added that, when specifying a service level “depending on priority”, will allow you to select a priority and execution schedule for each of them. If the schedule is not set, the Itilium system will automatically select the general schedule.
Robots inject – happy man!
How, with the help of Machine Learning, it is planned to “teach” Itilium how to predict the configuration unit (CU) needed by the service consumer, how to help the Service Desk engineer handle mass incidents and quickly find solutions to similar requests.
- Not sure? Don’t choose!
It is often difficult for a service consumer to choose a CU. But if this service consumer has previously dealt with the problem “The printer does not work” and indicated “Printer 5”, then why not teach the system itself how to help the user fill out the KE when sending a request to the service engineer. This will reduce the response time to requests and their processing. Even if the request on behalf of the service consumer is registered by the Service Desk (SD) employee himself, it will be no less convenient if the system prompts the CU previously selected by the consumer.
We plan to implement this feature literally in the next release: when a user registers an appeal on the Itilium web portal or in a thin client, the system will prompt KE users: whether it is a consumer who applies for a service, or an SD employee who registers an appeal. The system will match the description of the case and the initiator and try to predict the CI. If the machine learning confidence is higher than the threshold, then the system will peremptorily prompt the SD operator to install the appropriate KE.
- A Cheater’s Dream, or Tips for a Service Engineer
When communicating with a user, it is difficult for an engineer to keep in mind all closed calls and their solutions. And the information that is contained in closed calls can certainly be useful to the service specialist in the work on the next new call. The system could prompt the engineer for solutions from similar closed calls.
Starting with release 5.0.0.6, when communicating with a service consumer, an SD engineer will see closed cases along with a description of the solution to similar problems in a separate block of the communication form. The data in this block will be received using machine learning based on the description of the open call and communication with the initiator.
Achtung! Mass incidents under control!
The need for mass processing of requests usually manifests itself when one of the SD operators is forced to take on too many requests of the same type, or if something breaks inside your infrastructure, and it is clear to everyone that such a problem will affect many clients at the same time. This generally sets a higher priority for bulk access, and as a result, a problem that interferes with many users is resolved more quickly.
In the release of Itilium 5.0.0.6, it is planned to make it so that in case of similar requests, the system itself compares data from users, makes a recommendation to the operator and notifies the responsible persons that similar requests are received, which can be characterized as a mass incident.
New opportunities for two-way integration
Now in the Itilium system it is possible to receive data on requests through the API, but there is no way for external systems to somehow work with requests. This means that there is essentially no bilateral integration. The Desnol Soft development team wants to ensure that external systems integrated with Itilium can perform basic things – register, post by status, coordinate and confirm requests.
And already in the release of Itilium 5.0.0.6 such an opportunity will appear! The following functions will be added to the http service designed to receive data from Itilium: registration, approval and confirmation of requests, as well as changing their states.
