Why user errors are not incidents
USM cartoon ? SURVUZ Foundation

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.

Paul L. Laird

IT Service Management and Delivery Manager ?Sold $225MM to 25 Service Management clients. ?Reduced costs 30% for 28 Service Desks. ?Led 45+ client transformation to Managed Services.

4 年

Love this

Johan Sundnér

Consultant at Trustad AB

4 年

I think you have many good points and I agree with many of them but there is never one solution. You can always have another angle on things. The focus should be on the value not on definitions. If the customer do not think the provider deliver value than it won't make a different even if the SLA is followed. The customer will sooner or later move to another provider.

Michael Zanchetta

CEO & Partner : Service Management Consulting ☆ Leadership & Team Training

4 年

Interesting reflections Jan van Bon. I do agree that a vast amount of interactions/requests aren't and shouldn't be treated as Incidents nor in the Incident Process. Some may be treated as Service Request through e.g. Access Management... others become change requests and yes some obviously would be incidents; only an effective analysis will show. Regardless; in the real world users/customers don't care what we call it - why would they - they're interested in having their issue solved. You're describing is a typical example (we've all seen it countless of times) but what's the most effective way to solve it? Balance your strategy and investments to your defined service level. Document and categorize incoming requets/interactions. Evaluate the effectiveness and efficiency for each process. Bring output to CSI Constant feedback to process architects and strategic owners. Point being; it may be lack of user training, it may be organizational attitude, it may be weak leadership etc... every organization's different, but the common denominator is insight and bridging the strategic aims to reality.

回复

要查看或添加评论,请登录

Jan van Bon的更多文章

  • USM E-learning is now available

    USM E-learning is now available

    ?? The Next Step in Unlocking the Potential of USM is Here: USM E-Learning for Enterprise Service Management! ?? Learn…

    7 条评论
  • Another dozen USM Thoughts-Of-The-Day [4]

    Another dozen USM Thoughts-Of-The-Day [4]

    If any of these posts rings a bell, and you've missed them when they were posted, hit the link and add your comments…

  • Another dozen USM Thoughts-Of-The-Day [3]

    Another dozen USM Thoughts-Of-The-Day [3]

    If any of these posts rings a bell, and you've missed them when they were posted, hit the link and add your comment…

    4 条评论
  • Another dozen USM Thoughts Of The Day

    Another dozen USM Thoughts Of The Day

    If any of these comments rings a bell, and you've missed them when they were posted, hit the link and add your comment.…

    3 条评论
  • USM Thoughts of the Day

    USM Thoughts of the Day

    As most of the first ‘USM thoughts of the day’ have been posted during the end-of-the-year holiday season, this…

    6 条评论
  • Breaking Free from ITIL’s Limitations and Costs

    Breaking Free from ITIL’s Limitations and Costs

    Embracing a Sustainable Service Management Approach For decades now, countless organizations have invested heavily in…

    6 条评论
  • Moving up the USM Value Maturity model

    Moving up the USM Value Maturity model

    In the second webinar of "The USM Revolution" series on the Unified Service Management method, we received more live…

    2 条评论
  • Product, service, or goods?

    Product, service, or goods?

    In the second webinar of "The USM Revolution" series (https://www.youtube.

    33 条评论
  • Layered architecture models are outdated

    Layered architecture models are outdated

    Layered models are extremely popular in the world of architecture. This started with PRISM in 1986, and was followed up…

    35 条评论
  • Three ways to deal with the concept of data i.r.t. service and management system

    Three ways to deal with the concept of data i.r.t. service and management system

    Last week, I got a call from a government architect who, in a discussion with colleagues, failed to answer the…

社区洞察

其他会员也浏览了