Service Requests versus Change Requests and Incidents versus Problems
Businesses define and apply concepts differently in their Modern Service Management solution. They mix, for example, the use of Service Requests, Change Requests, Incidents, and Problems. The confusion of concepts can cause great confusion and to be guilty of a lot of waste time. Here, Allan Pihl from AlfaPeople comes with a Modern Service Management conceptual clarification that can streamline service agents’ daily lives and increase productivity across the organization.
Modern Service Management solutions have different functional purposes. One of them is to act as the company’s structuring tool, where requests from users get one classification, after which the inquiry is handled in one type of process, while other inquiries get another classification, after which the inquiry is handled in another type of process and so on.
However, this structuring and streamlining principle only work if there is a consensus on the classifications. If internally in an organization there are different ways of classifying requests from users, confusion occurs quickly. And confusion has the effect of generating both waste time and frustration.
Therefore, Allan Pihl, Lead in Customer Service & IT Service Management at AlfaPeople, comes here with a Modern Service Management conceptual clarification that companies can inspire.
Service Request versus Change Request
A Service Request is a question or order from the user. A Service Request usually does not take long and is at a retail level where the service agent can help the user immediately.
A Change Request is a major and permanent change to the existing production setup. A change to the existing production set-up must be recorded, controlled, tested and implemented, which is a much wider process that typically requires time and involvement from several different parties.
“It is important to distinguish between these two types of requests internally, so you can get an overview of what you spend time in the organization,” says Allan Pihl. “If something is classified as a change, a streamlined process must be initiated, ensuring that you have the necessary knowledge that you have the necessary time to have an overview of how the change will affect other systems and that you have a recovery plan if something goes wrong in the change.”
Incident versus Problem
An Incident is an event that interferes with the user or causes a malfunction for the user. This is a matter of quickly re-establishing the user’s service or presenting them for a workaround on the issue so they can work on. For example, a user may report an error when he or she tries to start the Office package.
One problem is recurring incidents that continue to interfere with or cause errors to the user. For example, if the same user or multiple users, for example, report the same error when trying to launch the Office suite, there is something that indicates that there is a general problem with the Office suite that requires a permanent solution.
“Again, the art of distinguishing when something is a problem and not just a single incident. Because it is against the recurring problems you have to target. Of course, users need to provide instant-and-answer solutions to acute incidents, but the most important thing is to get the necessary resources to ensure that the problem does not stop on the long run,” says Allan Pihl, ending:
“A recurrent problem may mean that you need to set up a change process where you need to change the existing setup. And then we are back by the importance of classifying uniformly and correctly. Modern Service Management would like to run like a well-sourced machine. When users’ inquiries are addressed in the right process, one can better prioritize tasks, continuously improve performance and ultimately ensure that customers experience improved service.”
If you would like further information, please feel free to contact us.