In a previous post I talked about the notion of employee service and a later one I showed that this notion of employee service was making its way into people’s heads and into the market. But just because people are thinking about it and solutions to do it are appearing on the market doesn’t mean it will become a reality or become a reality quickly.
The objective of this post is to review the cost/benefit ratio of such an approach and, above all, to discuss the practical details.
- Why an employee service approach?
- Employee demands are vital to operations
- The black hole of employee requests
- The customer is always better served than the employee
- The benefits of ticketization of the business
- Ticketization is not complication
- Ticketization in action
Why an employee service approach?
We can assume that the main principles of the employee experience are inherited from those of the customer experience, that we are in a logic of consumerization of organizations or evoke the need for symmetry of attentions between the employee and the customer on the one hand, and the business and the employee on the other hand, but we arrive at the same point: in any business there is a customer service but rarely an employee service.
And why is that? Obviously because, as I said about the Management Delivery Model, the business makes a promise to the customer, the employee must have the means to keep it, and for that he or she has the right to expect something from his or her manager and the organization, and may have requests and questions.
Employee demands are vital to operations
There is a myth here that I want to dispel as soon as possible: employee requests are not only HR requests and do not have to be handled by HR alone.
Yes, sometimes an employee has things to ask of HR and there are usually channels or even people identified for this.
He also has things to ask his manager. The interlocutor is known by definition and there is no lack of channels: telephone, email, chat, meeting, going to speak to him impromptu. These requests can concern the managerial dimension of the manager but also his operational dimension: need for an approval, an advice, a standpoint as to the conduct to be followed…
There are also more technical things that usually go to iT. Problem using a tool, tool not working, need to access a new tool, need to get different spaces and instances created for a project…
Sometimes they may also need expert advice or assistance. Sometimes identifying the person is easy, sometimes not. This also shows us that the subject is also linked to the issue of knowledge management.
Finally, there are “alerts”. An employee can observe a dysfunction, something that puts the business at risk or, conversely, a good practice that would benefit from being known and generalized, and this information must be passed on to the “right” level in the interest of the business. Without anyone forgetting to process it, without letting it sleep in an email box and within a timeframe that allows action to be taken.
What you need to understand is that, contrary to what many people think, when an employee has a request of the organization, it is rarely related to his or her personal situation and is most often related to operational needs. They are stuck somewhere and are waiting for someone to unblock the situation so they can move forward in their work. Just as when I commented on the 4th employee experience barometer, I noticed that the subject was looked at through a purely HR prism, whereas the employee spends at least 95% of his or her time in an operational context and (fortunately) not interacting with HR!
The black hole of employee requests
Each of these requests has a recipient, a criticality level and must follow a path. In some cases, the request should be automatically escalated if the recipient cannot process it within a certain timeframe.
The truth is that in many cases the recipient is not known or vaguely known (IT, HR…) that there is no security in terms of processing times and that once the request is gone it is totally impossible to know what happens to it, where it is. And I’m not even talking about certain requests for assistance or alerts that are buried either because there is not enough time to process them in time or because someone wants to hide the dust under the carpet.
Sometimes they are processed, sometimes not. Sometimes within an acceptable time frame, sometimes not. Meanwhile the employee waits.
This poses three obvious problems that are worth mentioning.
This penalizes the business from an operational point of view. An employee blocked by a subject, no matter what its nature, is an employee who does not deliver, or does so poorly.
This sends a bad signal to the employee: “I am there for the customer, but who is there for me? He can’t count on a business that asks a lot of him. Disengagement guaranteed.
All this not being followed up on, the business loses opportunities to learn from what it is doing right or wrong and therefore loses opportunities to improve.
In any case and whatever the subject you are most sensitive to, it is wrong.
The customer is always better served than the employee
As a customer, when you have a problem with a product or a service, you have a recourse: customer service. Today the standard in this matter is :
1°) An available knowledge base that limits the need to refer to a person for information. Such a knowledge base can be set up in a company
2°) A sort of online one-stop shop where you ask your questions before they are directed to the right people with follow-up and escalation systems. On the “back office” side, a request results in the creation of a “ticket” which will be followed up, reassigned, processed, and will be the subject of interactions and comments both internally and, sometimes, with the customer.
It is this second feature that is totally absent in companies, which is all the more surprising since they use this type of approach with their customers.
But, for the employee, it is obvious that it is easier to get an answer from the organization for the customer than for him. Even if answering to him allows to answer to the customer…
In short, a customer who has a problem or a question “opens a ticket” and an employee should be able to do the same.
The benefits of ticketization of the business
This logic, which I call the tickerization of the business and which we identified a year ago as an emerging trend in this video with Olivier Delestre, has many benefits.
First of all, it allows the traceability of each request. This may seem obvious, but the employee must know the status of his request. But that’s not all. It also allows the business to measure the efficiency and reactivity of its internal services, its management and its “People Operations”.
This allows, of course, after analyzing the problems frequently reported and measuring the efficiency of the system, to enter into a continuous improvement process.
This makes the system scalable across the business.
This makes it possible to add security to practices that, today, do not have any. For example, alerting (such a ticket has not evolved for x days) or automatic escalation.
It is an opportunity to formalize and therefore simplify practices that are currently mostly informal.
This enables collaboration by allowing a variety of employees to contribute to solving the problem.
This reduces the effort of coordination and administrative management of requests. This reduces the mental burden on those who have to respond and can focus on the value they have to bring rather than on sorting and following up on a mass of requests that would arrive by email for example.
It also improves the responsiveness of the system and the business. Remember that sometimes behind an employee who asks a question there is a customer waiting for an action from him or a task waiting to be executed.
This contributes to a dematerialization process in which certain functions (and notably the HR function) are lagging behind.
This makes it possible to set up a one-stop shop, which is simpler for the employee, as the request is then automatically “routed” to the right place.
Ticketization is not complication
Of course some will find limits to such an approach. Several months ago Philippe Szilerzahn wrote about the subject and found nothing but flaws in it. Although I generally agree with what he writes, I think he confuses several things here.
He limits it to technical support. We have seen above that there are many more cases.
He sees this as an extreme application of Taylorism. As far as I’m concerned, I make a clear difference between the so-called Easily Repeatable Processes (ERP) and the Barely Repeatable Processes (BRP). In the first ones, the human being has a low added value, they add an unnecessary mental load and the human being is mainly a source of error and slowness. In the second type, which involves managing exceptions and unique cases, the human being is indispensable and must be able to give it his full attention.
The approach as I describe it allows humans to free themselves from monitoring and administration tasks through automation. And when Philippe Szilerzahn criticizes the separation of execution and design tasks, I think on the contrary that here it is a good thing for individuals to no longer execute the process (the software takes care of it) and to only intervene to design and provide answers and solutions.
He sees it as a source of disempowerment and demotivation. For me, it’s spending the day receiving emails, requests, sorting them, directing them and following them that is a problem. Not answering questions.
Finally, he sees the shortcomings of a formal organization and I think he is confusing formalism with complication of organizations. Formalism is “writing down the way things are done”. You can formalize a simple organization or a complicated one: formalization is not the problem, it only makes it visible. On the other hand, formalizing the way we handle various requests allows us to realize the current complication in order to set up a simplified system facilitated by technology.
Moreover, the codification/specification of easily identifiable tasks is one of the components of a lean approach to simplifying organizations for knowledge workers.
Ticketization in action
So you’re probably wondering how this is set up and works on a daily basis. This will be the subject of a future post on what is for me the backbone of People Operations.