An idea for how to handle incidents as requests

I've tried for years to argue that you don't resolve technical issues as part of incident workflow - they're problems. But I have to face up to the fact that I'm never going to win that one. So here's a gentler option that still addresses my concerns: the Request for Restoration of Service. Does this idea have legs?

I can argue until I am blue in the face that incident management is about users, problem management is about causes. I think that the incident process is solely where we restore service to individual users or groups of users (through workarounds, resets...), and that the underlying issue causing the interrupted service is a Problem, to be dealt with by Problem Management. To me that is a simple and intuitive model but people don't buy it: they want to handle the resolution of the underlying cause as an Incident because ITIL says so.

This sucks because you now have user responses stored in two places: as Incidents and Requests, depending on what they asked for.

And it sucks because tech fixes are recorded on either incident or problem records depending on ... who knows what.

Most of all, it sucks because the Incident process now has two often-conflicting goals and draws two completely different teams and skillsets to resolve them: make users happy, resolve technical problems.

So if you won't buy my simple answer, here's a proposed alternative:

• Log all user requests as Requests, whatever they ask for.
• One kind of Request is Restoration of Service. "I'd like my service back please".
• Open many Requests for Restoration of Service, one for each user requesting.
• Open one Incident, no user associated. This is what would have been called the Master Incident.
• Link your Requests for Restoration of Service to the Incident.
• Handle the workarounds for each user in the Request tickets. Close when the user is working again.
• Handle the underlying technical issues in the Incident workflow.
• As per ITIL, open a Problem if you feel like it. (I can't find a clearer criterion)

Now the Service Desk's make-the-user-happy people are not trying to fix tech, and the misanthropic techs are not trying to love users.
The fix to the tech issue is only recorded in one incident ticket.

But wait: we still have both incidents and problems being used to track technical resolutions, making both knowledge searches and statistical reporting twice as hard. Sigh. I still think the best answer is to say that Incidents are about users (restoration of service through workarounds, or appeasement if we can't) and Problems are for fixing stuff.