3.3Event management and request fulfilment

What reaches the service desk is not only fault reports. There are countless events automatically raised by monitoring systems, and routine requests such as "please reset my password" are mixed in as well. Lining all of these up in the same queue as incidents buries the truly urgent faults. This section distinguishes event management, which sorts monitored occurrences by threshold, from request fulfilment, which handles low-risk routine requests through a dedicated flow, and covers how to route which report to which process.

3.3.1Event management and thresholds

• An event is a state change significant to the management of a service or component. Event management is the process that detects and classifies these through monitoring and, when necessary, connects them to corrective action (such as automatically raising an incident).
• Events are usually classified as informational (a normal notification for logging), warning (an alert as a threshold is approached, e.g., disk usage reaches 80%), or exception (an abnormality deviating from the agreed level, e.g., usage exceeds 95% or the service stops responding). Acting at the warning stage lets you respond before it becomes an exception (an actual fault).
• Threshold design is key: set too low, warnings flood in and cause alert fatigue that buries important signs; set too high, you only notice once it has become an exception (an actual fault). The value of monitoring lies in acting proactively at an appropriate threshold.

3.3.2Request fulfilment and service requests

• A service request is not a fault but a routine, low-risk request from a user (password reset, installation of standard software, granting access rights, arranging supplies, etc.). It differs decisively from an incident in that its procedure, approval path, and cost are predefined—it is a "known request."
• Request fulfilment is the process that receives, approves, and executes these service requests through a flow separate from incidents. Being routine and low-risk, they lend themselves to automation via a self-service portal or catalog; standardizing them lowers the service desk's load while responding quickly.

Suppose a service manager faces three reports queued up in the morning. (1) The monitoring system has automatically raised a warning event that "disk usage on the production DB server has reached 80%"; (2) a sales-department employee has requested "I forgot my password, please reset it"; and (3) the accounting department reports that "the monthly-closing screen is blank and will not open." It is wrong to line all of these up uniformly in the same "incident queue." First, (3) is clearly an incident (an unplanned quality degradation of a service); it is prioritized by impact x urgency and restored through incident management. (2) is not a fault but a routine, low-risk service request with a predefined procedure, so it is routed to the request fulfilment flow rather than incident management—ideally automated so the user can complete it themselves via a self-service portal, lowering the service desk's load. (1) is not yet a fault but a warning caught by event management. Since 80% usage is not an exception deviating from the agreed level, it need not be turned into an incident immediately, but as a sign of approaching the threshold, deleting unneeded logs or adding disk capacity is arranged proactively before it reaches 95% (an exception, i.e., an actual fault). Had the threshold been set at 95%, you would only notice just before writes actually fail. Conversely, setting the threshold too low, such as 50%, floods warnings and causes alert fatigue, burying truly dangerous signs. "Route faults to incident management, routine requests to request fulfilment, and monitoring signs to event management to act ahead while still a warning"—routing reports correctly is the judgment of a service manager who uses limited staff efficiently.

3.3.3Section summary

• Event management sorts monitored occurrences into informational/warning/exception by threshold and acts proactively at the warning stage
• A service request is a routine, low-risk request that is not a fault, handled by the dedicated request fulfilment flow (automated where possible) rather than as an incident
• Route reports correctly—faults to incident management, routine requests to request fulfilment, monitoring signs to event management—to use limited staff efficiently