IT Service Management

01Purpose and scope

• This manual supports the course IT Service Management. It is written as a working reference for people who run, support, or consume IT services, including service desk analysts, support team leads, change coordinators, service owners, and the managers who review how those services perform.
• IT service management, often shortened to ITSM, is the set of practices an IT group uses to plan, deliver, support, and improve the services it provides to users and the business. In day-to-day work it covers how a user reports a problem, how a request for access or equipment is fulfilled, how a change to a live system is approved and made, and how the organization learns from repeated failures. The scope here is the operational side of those activities rather than the design of any single technology.
• Practice varies a great deal between a small office with one service desk and a large enterprise running hundreds of applications across several sites. This manual describes common patterns and the reasons behind them, so you can adapt them to your own environment. It does not replace your organization's approved procedures, contracts, or security policies.

02Core principles

• The first principle is that a service exists to help a user or business outcome happen. A password reset, a printer queue, and a customer billing platform all count as services, and each should have a named owner, a description written in terms a user would recognize, and a known set of hours and support levels. When a team cannot say who owns a service or what it is for, incidents tend to bounce between groups.
• The second principle is that work should be recorded in one system of record. Tickets, changes, known errors, and configuration items all need a consistent home, even if the tool is a shared spreadsheet in a very small group. Without that record, you cannot measure anything, and you cannot explain to a manager why the same fault occurred three times in a quarter.
• The third principle is that restoring service and fixing the cause are different activities. Incident management aims to return the user to work as quickly as is reasonable, often through a workaround. Problem management looks for the underlying cause so that the incident stops recurring. Mixing these together usually means either that users wait too long or that the root cause is never addressed.
• The fourth principle is that change carries risk and needs a deliberate path. Most outages in mature environments are linked to changes, so changes need an assessed impact, a rollback plan, and an approval step proportional to their risk. Standard, pre-approved changes can move quickly, while emergency changes need a short, documented review afterward.
• Frameworks such as ITIL describe these practices in a common vocabulary, and ISO/IEC 20000-1 sets out requirements for a service management system that can be audited. You do not need to adopt either one in full, but knowing their terms helps when you work with auditors, vendors, or colleagues trained in them.

03Planning and preparation

• Before running any of these processes at scale, define the service catalog. A catalog lists the services offered, who can request them, the expected fulfillment time, and the approval path. Keep the catalog short at first. Ten well-described services are more useful than a hundred half-finished entries that nobody maintains.
• Next, agree on priority. Most teams combine impact and urgency into a simple matrix, where impact describes how many users or how much business activity is affected and urgency describes how soon the damage grows. The matrix should be written down, reviewed with the business, and used consistently. A payroll system outage during a pay run will rank high on both measures, while a single user unable to change a font setting will rank low.
• Define service levels with the people who depend on the service. A service level agreement records targets such as response time, resolution time, and availability, along with the hours they apply to and what happens when they are missed. Targets should be achievable with the staffing and tooling you actually have. An unrealistic target produces a dashboard full of red and encourages people to close tickets early.
• Decide on your tooling early but keep the process ahead of the tool. Most organizations use a commercial or open source service management platform, a configuration database, and a monitoring system that can open tickets automatically. The trade-off is that heavy tooling takes time to configure and can encode a process nobody agreed to. Start with the workflow you need and configure only what supports it.
• Finally, identify the roles. A service owner is accountable for a service's performance and improvement. An incident manager coordinates major outages. A change manager or change advisory board reviews proposed changes. A problem manager tracks recurring faults. In small teams one person may hold several of these roles, but the responsibilities should still be written down so that no task is orphaned.

04Recommended workflow

1. 1
   : Receive and log the request or report. Every contact from a user, monitoring alert, or automated feed should become a record with a short title, a description, the affected service, the reporter, and the time received. Capture enough detail that the next person does not need to call the user just to learn what the problem is.
2. 2
   : Classify and prioritize. Assign the category, the affected service, and the priority from your impact and urgency matrix. Check whether the issue matches a known error or an existing incident affecting the same service, since duplicates are common when several users report the same outage at once.
3. 3
   : Restore or fulfill. For incidents, the first aim is to restore service, using a documented workaround if one exists. For service requests, follow the fulfillment procedure in the catalog. Record each action taken in the ticket as it happens, not from memory at the end of the day.
4. 4
   : Escalate when needed. Escalate to a second-line or specialist group when the first-line analyst cannot resolve the issue within the agreed time. For major incidents, invoke the major incident process, which usually means a named incident manager, a status update cadence to stakeholders, and a bridge call or chat room. Escalation should pass along the full history so the receiving group does not start over.
5. 5
   : Assess and plan changes. When a fix requires altering a production system, raise a change record. Describe what will change, the systems affected, the business window, the test evidence, the rollback steps, and the people who must be told. Route it for approval according to its risk category, and do not schedule work until approval is recorded.
6. 6
   : Implement, verify and close. Carry out the change or fulfillment step in the agreed window, confirm with the user or a monitoring check that service is restored, and record the outcome. Close the ticket only after the user confirms or after a stated waiting period passes without objection. Where the incident was caused by a recurring fault, link it to a problem record for root cause analysis.
7. 7
   : Review and learn. For major incidents and failed changes, hold a short post-incident review. Agree on the timeline, the contributing causes, what worked, and the actions to prevent recurrence, with named owners and due dates. Feed the outcomes into the knowledge base and the problem log.

05Quality checks, risk controls and compliance

• Quality in service management is checked at the record level and at the service level. At the record level, a reviewer or a periodic sample can confirm that tickets have accurate categories, that work notes explain the actions taken, and that closure codes match the outcome. Reviewing a random sample of ten to twenty closed tickets each month is a common starting point, though the right number depends on volume and risk.
• Change risk controls are the most important ones to get right. Typical controls include a risk rating based on the systems affected and the number of users impacted, a requirement for tested rollback steps, a freeze period around business peaks such as month-end financial closing, and a separation of duties so that the person requesting a change is not the only approver. The trade-off is speed. Tight controls slow down routine work, so many teams define pre-approved standard changes for low-risk, repeatable tasks.
• Access and fulfillment controls matter because service desks hold privileged capability. Identity verification before a password reset or account unlock is essential, as social engineering against help desks is a documented and frequent attack pattern. Access requests should record who approved them and should be reviewed periodically.
• Compliance requirements depend heavily on jurisdiction, sector, and contract. Data protection laws, financial reporting controls, health information rules, and government security frameworks can all affect how incidents are reported and how changes are recorded. This manual does not set out those requirements. Confirm them with your compliance or legal function and with the current authoritative text in your jurisdiction. Where guidance on regulated activity touches medicine, finance, tax, or safety, it does not replace qualified professional judgment, approved procedures, or required authorization.
• Records are also evidence. Keep audit trails for approvals, emergency changes, and access decisions, and protect them from edit after closure. Decide how long records are retained, and align that with your legal and contractual obligations rather than a default tool setting.

06Collaboration and documentation

• Service management depends on handoffs between the service desk, infrastructure, application support, security, procurement, and the business. Handoffs fail when the receiving group does not know what is expected or when the sending group assumes a fix is visible. A short standard for each handoff, including the information required and the expected response time, prevents most of these failures.
• Documentation should be useful to the person who will read it under pressure. Knowledge articles for common issues should state the symptom in the words users actually use, the diagnostic steps, the workaround, and the conditions under which the article does not apply. Service descriptions should say who to contact, when the service is available, and what is excluded. Avoid writing articles that describe the system as the architect imagined it. Describe what the analyst will see on screen.
• Keep the configuration record accurate enough to answer basic questions quickly, such as which servers support a service, which application depends on a database, and who owns each component. A configuration record that is wrong is often worse than none, because people trust it. Assign owners to configuration items and check them during periodic reviews.
• Communication with users is part of the work. Status updates during a major incident should be short, regular, and honest about what is known and unknown. Avoid promising a fix time you cannot control. A message that says the team is investigating, the next update is due at a stated time, and a workaround is in progress is usually better than a long technical explanation.

07Measures and continuous improvement

• Measure what helps decisions rather than what is easy to count. Common indicators include first contact resolution rate, mean time to restore service for incidents, percentage of incidents resolved within the agreed target, number of repeat incidents linked to the same known error, change success rate, and the proportion of changes that required emergency handling. Each measure should have a definition written down, including what is counted and what is excluded, so that results can be compared over time.
• Read indicators together. A high first contact resolution rate combined with rising repeat contacts may mean analysts are closing tickets with temporary answers. A fast average resolution time can hide a long tail of stalled requests. Look at distributions and the oldest open items, not only averages.
• Use service reviews to turn data into action. A monthly or quarterly review with service owners and business representatives can examine trends, agree on problem records to address, and adjust service levels if they no longer match business needs. Keep the review focused on decisions and owners, and avoid turning it into a reporting ritual.
• Continuous improvement works best with small, tested changes. Pick one recurring problem, define the expected effect, make the change, and measure again after a reasonable period. Large reorganizations of process rarely hold up unless the smaller changes underneath them have already shown results.

08Common mistakes and how to prevent them

• One common mistake is treating the ticketing tool as the process. Teams configure dozens of fields, workflows, and automations, then find that analysts fill them in with placeholder values. Start with the minimum set of fields needed for routing, reporting, and audit, and add more only when someone can name the decision that depends on them.
• A second mistake is setting service levels that ignore the support model. A commitment to resolve all incidents within four hours is not credible if there is one analyst on shift and the average fix requires a vendor. Check targets against actual staffing, vendor response times, and historical data before publishing them.
• A third mistake is skipping problem management because the service desk is busy. The result is the same incident handled dozens of times. Schedule problem reviews as a standing agenda item and give problem records an owner with time allocated for them.
• A fourth mistake is approving changes without understanding their dependencies. A patch to a shared authentication service may affect many applications that nobody listed. Use the configuration record to identify dependent services, and ask the owner of each one to confirm readiness for significant changes.
• A fifth mistake is closing tickets without confirming the user's outcome. Premature closure makes metrics look better and users more frustrated. Build in a confirmation step or a clear waiting period, and reopen tickets easily when the problem returns.
• A sixth mistake is writing post-incident reviews that name people rather than conditions. Reviews that look for a person to blame discourage honest reporting. Focus on the sequence of events, the signals that were missed, and the controls that failed or were absent.

09Practical checklist

• Confirm the service catalog lists each service with an owner, a description, hours, and an approval path.
• Check that the impact and urgency matrix is written down and used the same way by every analyst.
• Verify that each service level target matches current staffing, vendor response times, and past performance.
• Ensure every incident and request record has a category, a priority, an affected service, and clear work notes.
• Confirm that major incidents have a named incident manager, a status update cadence, and a communication channel.
• Review that every change has a risk rating, a tested rollback plan, and recorded approval before implementation.
• Sample closed tickets monthly to check closure codes, user confirmation, and documentation quality.
• Link recurring incidents to problem records and assign an owner with time allocated for root cause work.
• Hold post-incident reviews for major incidents and failed changes, and track the agreed actions to completion.
• Review access request and identity verification controls against your organization's current policy and applicable rules.

★Learning sources

• Micro Degree: IT Service Management
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics