Mitratex

Introduction:

Have you ever wondered how IT teams handle the countless service requests they receive daily, whether it’s a simple password reset or a request for a new email account? Just like any other organized system, there’s a method to the madness. This article simplifies the request management process, making it understandable for both IT professionals and everyday users.

1. Receiving the Request:

Before any action is taken, a formal request must be received. This request can come through various channels, such as:

  • Service desks.
  • Email.
  • Automated web interfaces.
  • Phone calls.

Standardized forms capture the specifics of each request, ensuring it contains all necessary details, so there’s minimal back-and-forth with the requester.

Now, there’s an essential distinction to make here: not all requests are the same. Some could be incidents (like reporting a malfunctioning device), while others could be for new or altered services. The former might go to an ‘incident management’ team, while the latter might be directed to teams responsible for service changes or even relationship management.

2. Logging and Validating the Request:

Every service request, irrespective of its source, is logged with a date and time stamp. Important information that’s usually logged includes:

  • Unique reference number.
  • Request categorization.
  • Urgency and impact.
  • Requester details.
  • Expected closure and fulfillment dates.

Sometimes, service staff, when dealing with one issue, might get other requests on the spot. In such cases, each new request is separately logged. 

3. Categorizing the Request:

To understand the request better, it’s slotted into specific categories. Examples include:

  • By service (e.g., email service).
  • By activity (e.g., password reset).
  • By type (e.g., standard change).

4. Prioritizing the Request:

Not all requests are of equal importance. Some might be urgent, while others can wait. A request’s priority is determined by its urgency and impact on the business. Factors influencing this include:

  • Number of services or users affected.
  • Financial implications.
  • Regulatory repercussions.

5. Authorizing the Request:

Before any action is taken, the request must be authorized. The service desk may handle basic authorizations, but more significant requests may need further approvals, possibly involving financial considerations or access rights.

6. Reviewing and Allocating the Request:

The request is reviewed to decide who will handle it. While the service desk might tackle some, others could be escalated to specialized teams. 

7. Following a Standard Model:

To ensure consistency, a standard model or procedure is followed to address the request. This model provides a clear step-by-step guide to fulfilling specific requests, reducing chances of error or delay.

8. Closing the Request:

Once the task is completed, the service desk is notified. Before closing the request:

  • It’s checked if all requirements are met.
  • User satisfaction is assessed.
  • Financial implications are considered.
  • The request’s documentation is updated.

Sometimes, based on pre-set rules, certain requests are auto-closed if not revisited within a specific period.

9. Reopening Requests:

On occasion, a closed service request might need to be reopened. However, there are rules about when this can happen. For example, some organizations might permit reopening within a day of closure, but beyond that, a fresh request must be made.

Conclusion:

Behind the scenes, IT teams follow a structured and methodical approach to ensure every service request is handled efficiently. While this process might seem complex initially, understanding its essence can lead to better communication and smoother interactions between IT teams and users. Whether you’re an IT professional or an end-user, knowledge of this process can certainly be beneficial.

References: ITIL Service Operation, 2011 edition, ISBN 9780113313075