Why user errors are not incidents

Case 1: A user reports "I lost my password, can you reset it for me?"

Case 2: A user reports "I lost the key to my locker, can you get me a new one?"

Case 3: A user reports "I made an incorrect entry in application X, and now my data is corrupted, can you fix that?"

Numerous internal and external service providers treat these cases as incidents, as failure reports. They perform the required actions, register the request as a failure, and report on it neatly in service reporting.

Why is this wrong? The failure is fixed, right?

The fallacy

Every request from a customer/user can be traced back to a wish, an RFC, an incident, or a service request (or it is communication within a previous call). The nature of the request determines the interaction type, within the context of the agreed service.

The assumption to handle the above cases as incidents is based on the perception:

1. that the customer is entitled to support
2. that there is a failure in the functioning of the facilities made available
3. that there is, therefore, a shortcoming in the actions of the service provider
4. that the service provider must therefore repair the situation at his own expense

In all three cases, point 1 will be answered positively, otherwise, the service provider should not have taken action at all. In all three cases, however, point 2 fails, and as a consequence also points 3 and 4 fail.

After all, there is no failing of a facility: on the contrary, they function as agreed. The user cannot get into the secured application or the locker - and that is exactly the intention. In case 1 and case 2, the service agreement apparently contains an agreement about security. Unauthorized users are not allowed to access secured resources (the application, the locker). Thus, the facility is functioning correctly and therefore there cannot be a failure.

Both cases are therefore examples of user errors, as is case 3.

The Solution

In all three cases, the user wants to be supported. To ensure that this happens, the right to this support must first be agreed upon. This is done in the service agreement, the SLA.

As soon as it is agreed in the SLA that a facility will be secured (cases 1 and 2), the customer and supplier must also agree on what happens if the user makes an error (i.e. losing the key). The solution is simple: the supplier should provide additional actions ("provide additional password/key"). The costs for these extra actions should then be laid down in the SLA. Logically, the customer will have to pay extra because the customer causes the extra actions.

The same applies to all other user errors. Customers and providers must agree in the SLA which support the provider will provide if the customer makes an error that leads to extra effort and how the extra costs will be settled.

Practice shows that numerous user errors are registered and handled as incidents. Those situations detract from a proper customer-provider relationship and lead to errors in the provider's performance evaluation and in service agreements.

Those who follow the simple logic of the USM management system can easily discuss those situations in service negotiations, and then handle them easily and correctly.

If you want to learn more about a simple, systematic, and methodical way of solving issues like these, you're invited to a free online workshop. The SURVUZ Foundation now provides these workshops on a regular basis (2 per week), to cope with the overwhelming interest for the new thinking of USM for Service Management Architecture, and for Enterprise Service Management. A workshop takes 2 hours and is a very intensive activity. Starting times will be alternating 09:00 CET (to accommodate the eastern hemisphere) and 15:30 CET (to accommodate the western hemisphere).

If you want to catch up on what you didn't learn at school, 2021 is the year to do so. As we aim for small groups to foster discussion in the interactive workshops, registration is required. You can register at the USM Portal.