In the olden days, the typical IT call logging system comprised of requests and incidents, the ‘change process’ came along for changes to production systems, then some companies brought in the problem request.

Defining what we mean by this on a simple level is important.  If a call is logged in correctly from the user viewpoint it might get closed or dealt with incorrectly, from the IT perspective, I might get fined for missing my SLA, my targets for resolving issues.

• An incident is a call that requires immediate attention, it is an in time call which stipulates the issue affecting a user and therefore requests it is fixed.

• The resolution time might be minutes for a business critical incident.

• It might be something like a new share on the filer, or a new laptop for oncall, or even a server install.

• Changes usually only apply to production systems to monitor production and prevent unnecessary impact to the business users.

• For example the trading server needs rebooted every day at 8pm due to a memory leak. It’s got a temporary fix, to reboot it, but on a permanent basis we need support to resolve this with the application team if necessary.

How do you manage these different requests?
What is an acceptable time delay in resolving an issue?

They are equally important, but at the same time you want the support teams to focus on incidents, on keeping everything working first, then dealing with requests.