incident vs. service request
expressionIT support
The great ITIL fork: an incident is something broken; a request is something wanted - different queues, clocks, and expectations.
Misfiling one as the other is how a password reset gets a major-incident bridge call.
An incident is something broken that should be working; a request is somebody asking for something new or different. The distinction sounds bureaucratic and it determines almost everything about how the work is handled: urgency, who is authorized, whether change control applies, and which clock is running.
The reason it matters is that treating one as the other fails in both directions. A genuine outage entered as a service request sits in a queue behind password resets while a business function is down. A request for new access raised as an incident bypasses the approval that exists specifically to prevent people granting themselves things, which is how audit findings are generated.
The judgement calls are where practice actually lives. A slow system is an incident if it used to be fast and a request if it was always this slow and someone now wants better. A feature that never worked is arguably a defect rather than an outage. Getting the classification right at intake is worth more than any amount of process downstream, because everything after it inherits the initial decision, and misclassification is rarely revisited once the ticket is moving.