Work on improving a business process is launched by an initiative supported by the Leader . The initiative can come from anywhere. It is important that it is the owner of the business process who shows or supports the initiative to improve their process. In our project, the owner of the Customer Request process is the head of the Contact Center.
We are not talking about local process improvements, but about process reengineering, why? Because it was necessary to systemically rethink the entire process, radically change the typology of requests, the role model, add new attributes of requests, new process steps.
For the business of the management company, the process “Customer Request” is one of the key business processes (the role-based graphic diagram of the process is presented in Fig. 1). The logic of the target process is clearly reflected in the presented diagram.
Fig. 1. Graphic role diagram of the “Customer Appeal” process.
Initial situation and problem statement
It took about 1 month to initially set the task of reengineering the Client’s request business process and mobilize the necessary resources to solve it. A working group (WG) was created, within the framework of which all the main methodological development of new requirements for the process was carried out. The WG included the Financial Director (group leader), Project Office (business analyst), Head of the CC, Head of the IT Service, Lead Web Programmer (Bitrix24 developer).
After 4 months of intensive work by the RG, the functional requirements for changing the “Customer Request” process were formed, agreed upon, presented to the management and sent to the IT service for reconfiguration and refinement of the process using the Bitrix24 platform.
The initial state of the “Customer Request” process at the start of the RG work can be characterized as follows:
- The Bitrix24 platform has a process for processing customer requests; there were outdated regulations and instructions for training new employees.
- The directory of request types contained more than 250 request types.
- Applications were often closed without their actual execution.
- It took a lot of time to transfer the application to the relevant performer. It was not clear when the relevant performer would take the application into work and when he would complete it; there was no feedback recording in the application card from the relevant performer.
- There are no delineations between the areas of responsibility of employees in the process of fulfilling customer requests depending on the type of request.
- For emergency calls, the standard time period was set as follows: “immediately.”
Historically, customer requests were processed by the head of the dispatch service (DS), and when the new Contact Center (CC) division was created, the rights to change the directory of request types were not centralized; the directory of request types was situationally replenished with new types of requests without proper methodological verification.
This historical fact led to an uncontrolled expansion of types of requests (more than 250 types of requests), duplication of types of requests, the emergence of vague formulations of types: “electrical engineering – other”, excessive detailing of typology.
The huge classifier of request types did not help to quickly and accurately classify a request when registering it. And as a result, the chances of building correct reporting on the quality of work with customer requests by request types were zeroed out. An example of an incorrect reference book of request types is shown in Fig. 2.
Why is the Customer Appeal process important? Because regular untimely and poor-quality fulfillment of customer requests leads to a range of problems for businesses: a decrease in the reputation of the management company (MC), a decrease in customer loyalty (an increase in the risk of re-election of the MC), and most importantly – a resident with his unresolved problem contacts government industry authorities (EMERCOM, MZI, OATI, Rospotrebnadzor, Roskomnadzor, Rostekhnadzor, Ministry of Internal Affairs, FSB, OBOP, Investigative Committee, Prosecutor’s Office and their structural divisions, Administration, Prefecture, Departments, GKU IS). Based on a resident’s complaint, government industry authorities form and send their official request to the management company. Failure to fulfill the official request ends in fines and other very unpleasant things.
Fig. 2. Example of an incorrect classifier of request types (fragment of the reference book).
Developing the target process of Client Appeal
The RG focused on the following requirements:
- Ensure internal control over the execution of the request;
- Ensure receipt of feedback from the client – external quality control;
- Create conditions for collecting data on the development of measures to improve the quality of services;
- Develop a minimum required typology of requests covering all types of customer requests;
- Link typical routes for implementing customer requests to the types of requests, and ensure a clear composition of those responsible for implementing each specific request.
Fig. 3 visually indicates the blocks where individual requirements for the business process are taken into account.
Fig.3. Target process of Customer Appeal.
Description of process roles
- Request registrar: Contact Center specialist
- Sales organizer: an employee of the additional services sales department, forms the cost of the service; controls the fact of payment for additional services
- Responsible person: the relevant head of the structural unit (depending on the type of request), appoints the executor, attracts additional employees, coordinates the work, accepts the execution of the request
- Contractor: specialized contractor, depending on the type of request
- Editor: an employee who is responsible for the timeliness and quality of the official response to the client
- Controller: a customer service employee who controls the turnaround time for a request, has the ability to escalate a request, initiate the creation of a repeat request
At first, a target business process was developed with a link to employee positions. But to solve the project tasks: 1) to develop the minimum necessary typology of requests, 2) to link typical routes for implementing customer requests to the types of requests, it was necessary to develop, unify process roles, process steps, and link them to a new typology of requests.
As a result, based on the analysis of the statistics of requests, the RG formed a new typology of requests, where the number of types of requests was reduced by an order of magnitude, from 250 to 22 types, see Fig. 4.
Fig. 4. Categories and types of customer requests.
At the next step of the project to reengineer this business process, the RG quite successfully solved the creative task of defining a set of attributes, characteristics of the request, necessary and sufficient for the unambiguous definition of the composition of roles (responsible) for the purpose of implementing each specific type of request.
Employees in the Request Registrar role at step 1 of the process (see Fig. 3) classify the incoming customer request — assign a set of characteristics/attributes to the request (see Fig. 5). The assigned set of attributes should trigger automatic formation of the route for implementing the customer request in the Bitrix24 system. Based on the request classification, a standard route for implementing the request is automatically formed: a standard composition of roles (responsible persons). Each route has its own composition of participants, tasks for each role and a standard time frame for fulfilling the customer request.
Fig. 5. Formation of standard routes for implementing customer requests.
To effectively manage any business process, three conditions must be met:
- Trained qualified staff (human factor);
- Correctly constructed business process(es);
- Convenient tools that support process execution and process reporting (IT).
In our project of reengineering the process “Customer Requests”, in order to effectively manage this process, it is important to be able to receive a report on the entire array of requests at any time for any period of time, where you can see the current statuses of requests, so that it is possible to dynamically monitor the implementation of customer requests by relevant persons responsible for a set of criteria (quality, standard deadlines).
An employee of the Company in a certain role performs his step of the process (see Fig. 6). The statuses of the request are tied to the choice of one or another solution by the employee at each step of the business process.
Fig. 6. Matrix Roles X Process Steps X Statuses.
The methodological development of requirements for the automation of a business process is not always clear to an IT specialist until there is a level of detailing the requirements down to the level of describing the fields of the request card and a detailed description of the properties of the fields, see Fig. 7.
Fig. 7. Description of the fields of the request card.
Implementation of functional requirements for the process
The WG participants from the IT service implemented all the main functional requirements for setting up the process on the Bitrix24 platform in 1-1.5 months: the necessary reference books were created, the request card was set up (see Fig. 8), and business processes were developed at the technical level using the internal process designer in Bitrix24.
Fig. 8. Client request card in Bitrix24.
In parallel with testing and refining the solution, the head of the CC developed training courses on the process of Customer Appeals in electronic form for each process role (see Fig. 9, 10). Training materials and tests for verification were developed using the Bitrix24 platform.
Fig. 9. Training courses for participants in the Client’s request process.
Fig.10. Example of educational material.
Conclusion
At the stage of modeling and methodological development of the business process, it is necessary to think over the required analytics for process management and control. The analytics embedded in the process settings (attributes of the request in our case) will allow us to subsequently generate a convenient, correct report. When the real work of employees physically begins to “live” in the system, 1 week or 1 month will pass, we will want to generate our first report. And it happens that at this moment something new opens up that was not previously envisaged)
Based on the customer request attributes previously embedded in the process, it is possible to generate a report on the efficiency of fulfilling customer requests by request types and objects (see Fig. 11), where efficiency (efficiency coefficient) is calculated using the formula: k = t1/ t2, t1 is the sum of actual working hours, t2 is the sum of standard working hours for fulfilling customer requests.
If the efficiency coefficient is equal to or less than 1, it is good, since employees fulfill requests within the standard timeframes. If the efficiency coefficient is greater than 1, it is bad, delays are allowed, the client waits for the service longer than the time promised by the company, etc.
The result of a large project can be seen on page 1 of the report – at which facilities, for which requests, how effectively customer requests are processed.
Business processes, information systems, reports are necessary conditions for the manager’s work to make decisions on deviations or problematic situations, but automated business processes and process reporting by themselves will not create miracles. It is important that the correct report falls into the hands of a proactive, competent manager who will regularly draw the right conclusions based on the report, make the right decisions so that ideally for all objects and for all types of requests the efficiency coefficient is no more than 1 and there are no red zones as in the report in Fig. 11.
The final efficiency coefficient in the presented report = 1.06, which practically means good work of the organization as a whole.
But if you look at the efficiency of individual types of requests or individual objects, the efficiency coefficient can vary from 0.05 to 66.05, which, of course, can raise questions for the manager – why did these deviations occur? For what reasons was the work done so slowly or so quickly? What needs to be done to reduce delays in fulfilling requests? Perhaps the value of 0.05 is due to the fact that the performer formally pressed the button that he fulfilled the request, but in fact nothing was done? Thanks to the implemented project, the manager, the owner of the business process, received a good management tool – a report. The result of the project has been achieved, but the real work to improve the business process Customer Request is just beginning.
Fig. 11. Report on the efficiency of fulfilling customer requests by request types and objects (per month).
