The product analyst of the domestic service desk is back in touch. Last time about our client, the Brant service company, which implemented our platform during the active growth of its business.
Simultaneously with the growth in the number of applications, "Brant" has also increased the number of service objects - quantitatively and geographically. As a result, it took more trips to bоlonger distances, and the budget for fuel costs has increased significantly. How dispatch service automation helped save her from these expenses, I want to tell in this post.
So, Brant is a fairly large service company. It maintains more than 1 objects - these are shops, offices, salons, pharmacies - and each of them periodically requires maintenance, emergency repairs or warranty service. On average, 000-100 applications are received per day.
How it was BEFORE automation of the dispatch service
Network of objects of a specific customer merged into a separate project. A separate dispatcher was assigned to each project and a staff of service specialists was formed. For a long time, this type of service structure was considered by Brant to be the most effective.
The team formed for a specific project could accept incoming applications in the format that is convenient for the customer, and service specialists knew all the specifics of fulfilling applications at these facilities. This made it possible to solve maintenance tasks with high quality, but with a lot of “manual” work.
The Brant dispatcher received an application, then checked the list of objects: which specialist is assigned to this address? Does he keep up with the deadline with the current load? If not, to whom from neighboring sites can the application be submitted?
Manually, this process is not fast and you can’t call it transparent either - you have to turn to the same cumbersome tables and check with the performers whether they are ready to accept the application.
In 2019, Brant experienced a sharp increase in the number of service facilities, and this showed the inconsistency of the existing structure. Namely:
- territorial overlays of objects began. It happened that 2-3 service specialists went to one regional city to fulfill requests from different customers. Similarly, 1-2 dispatchers controlled these specialists, who are literally in neighboring buildings in the same city.
- it was necessary to increase the staff of service specialists, as well as engineers and dispatchers who manage projects and specialists;
- as a result, the cost of fuel and lubricants has sharply increased;
- it became impossible to quickly receive analytical data on the execution of applications: there are now too many employees and information.
How everything became AFTER automation of the dispatch service
It became obvious that to solve the problems you need to do the following:
- collect all incoming applications in one place, and not within one working draft
- translate all received applications into a single format
- implement a standard for the implementation of the application, regardless of which customer received this application.
This will allow creating a territorially formed network of service specialists who are ready to fulfill all requests for their area without being tied to the specifics of a particular Customer.
The restructuring was carried out quickly and without compromising the quality of the services provided. This made it possible to reduce fuel costs and avoid an increase in the staff of engineers and dispatchers. A single dispatch center was created for all Customers. The assignment of employees at all levels was carried out on a territorial basis.
The administrative panel of our HubEx platform provides flexible settings for automatic distribution of requests. The list of objects that is imported into HubEx from an Excel file already contains a field indicating the responsible person, so when creating a request for his object, the Service Specialist receives it immediately, without the participation of the dispatcher.
The subsequent distribution can be set in the settings. For example, if within a few hours the assigned executor does not move the application to the “Accepted for work” stage, the application will “inherit” another suitable executor. The settings allow you to select a spare person in charge, or the nearest one who has the necessary skills for repairing a specific request. Here's what it looks like:
Thanks to GPS navigation, you can always control whether an employee was really at the facility, and where exactly he is at a given time.
And again - the optimization of the time of all employees of the company, and significant. Increasing the transparency of the performance (or non-performance) of work at all stages.
With the help of the platform, it became possible to implement technical supervision of work and operational technical support for a service specialist.
If an employee encounters problems when fulfilling an application, he reports this in the application itself, the dispatcher promptly connects an engineer to the communication at the request. At any time, any question of the customer is promptly given feedback on any application. Project managers, while still accepting a request from the customer, can open an application and provide all relevant information on the work. This is especially true when performing emergency and labor-intensive applications.
Benefits of online dispatch
Thus, the automation of the dispatching service not only saved the time of employees, but also significantly reduced fuel costs. The analytics system aggregates all data and provides a visual representation of the status of all applications, thereby helping Brunt to control the quality of its services and plan further work.
Source: habr.com