Part 01
Escalation Tiers
Speaker 1: Let's map out how a tricky issue moves through support teams. The goal is
to fix things fast without clogging the pipeline.
Speaker 2: Each tier focuses on what it does best. Knowing where your ticket belongs
saves everyone time.
Speaker 2: Tier 1 is the front desk. They reset passwords, guide users through quick
checks and follow scripts.
Speaker 1: If the script doesn't solve it, they escalate so the queue keeps moving.
Speaker 1: Tier 2 technicians dig deeper. They have access to system logs and
configuration tools to unravel stubborn faults.
Speaker 2: When they spot a code bug or design flaw, it's time to bring in Tier 3
specialists.
Speaker 2: Tier 3 is often the product developers or vendor engineers. They tackle root
causes and push permanent fixes.
Speaker 1: Once resolved, details flow back down so Tier 1 can handle similar issues
faster next time.
Incident Vs Request
Speaker 1: Let's untangle two concepts that often trip up new support staff: incidents
and service requests. They sound similar but lead to very different workflows.
Speaker 2: Picture a computer that suddenly refuses to boot. That's an incident. Now
imagine a user politely asking for a new mouse—that's a request. Different problems,
different playbooks.
Speaker 2: An incident is any unplanned disruption or reduction in the quality of a
service. When the payroll system crashes, we drop everything and focus on restoring
normal operations.
Speaker 1: The aim is speed and stability. We log the ticket, assign urgency and
escalate if needed so employees can get back to work quickly.
Speaker 1: A service request is different. It's a predefined, low-risk action like
provisioning an account or ordering approved hardware. No firefighting here—just
following a standard procedure.
Speaker 2: Because requests repeat often, we can automate many steps or let junior
staff handle them. That frees up senior engineers to tackle actual incidents.
Speaker 2: Keeping incidents and requests separate means we measure the right
things. Incident metrics show how fast we recover from outages, while request stats
reveal how well we serve everyday needs.
Speaker 1: So the next time something goes wrong, check whether you're fixing a
broken service or just helping with a routine task. Getting it right keeps support queues
manageable and customers happy.
Job Roles Lifecycle
Speaker 1: Before a service goes live, someone has to own the concept. That's the
service owner, supported by analysts who gather requirements and a change manager
who plans the rollout.
Speaker 2: Good planning at this stage means smoother transitions and fewer surprises
once people start using the service.
Speaker 1: Day to day issues land with the service desk. They triage requests and keep
users informed.
Speaker 2: When problems get tricky, application or infrastructure teams jump in, and if
needed, vendors or engineers provide deep fixes.
Speaker 1: Once a service is running, the work isn't done. Problem managers look for
recurring issues while improvement specialists suggest changes.
Speaker 2: Operations leaders review performance reports so they can steer resources
and keep customers happy.
Speaker 1: Many IT careers start on the service desk. From there, you might move into
a specialist role like change manager or rise through management ranks.
Speaker 2: With experience, you could end up owning a service portfolio or leading
operations for an entire organisation.
Major Incident Drill
Speaker 1: Welcome to our major incident drill. Think of it as a fire drill for IT—everyone
needs to know their part before the real emergency hits.
Speaker 2: We'll walk through a simulated outage so you can practice the motions
without the adrenaline spike. The goal is to stay calm and restore service swiftly.
Speaker 2: A major incident is more than a glitch. It affects core services and usually
drags multiple teams into the fight. Picture the checkout system rejecting every
payment during a sale—that's major.
Speaker 1: When you see widespread impact or a breached SLA on the horizon,
escalate it and rally the right experts immediately.
Speaker 1: Let's map the checkout flow so everyone knows where problems can start.
The web front end hits an API gateway, which then fans out to microservices for
payments, inventory, and orders. Those services talk to a clustered database and
ping the payment provider over the internet. Monitoring agents watch each step.
Speaker 2: A failure anywhere in that chain kicks off a big response.
The incident commander coordinates efforts and sets priorities.
A communications lead keeps executives and customers in the loop.
Front-end and backend engineers dig into code issues.
Database admins check queries and replication.
Network ops verify connectivity and DNS.
A liaison talks to the payment provider.
Finally, the service desk fields user reports and keeps them updated.
Speaker 1: During the drill, assign each role quickly and follow the runbook.
The incident commander leads, comms handles updates, and a scribe logs every step.
Speaker 2: Treat it as the real thing—no shortcuts. The more accurately you rehearse,
the smoother an actual outage will play out.
Speaker 2: Once the dust settles, gather the team to review what happened. Share
successes, missteps, and any surprises.
Speaker 1: Update the playbook based on those lessons and book another drill. Practice
turns panic into muscle memory.
Overview
Speaker 1: Welcome to our quick tour of ITIL 4. Think of this first slide as the stage
curtain rising. Behind it lies a set of practices that guide how large organisations deliver
tech support.
Speaker 2: If you're new to the scene, picture ITIL like a city's traffic system—lanes,
signs and intersections that keep everything flowing. Without it, we'd have gridlock
every time an incident pops up.
Speaker 1: We'll stick to the essentials, sprinkling in some humour so you won't nod off.
By the end of this course you'll see why ITIL lingo is your ticket to a smoother IT career.
Speaker 2: ITIL once stood for the Information Technology Infrastructure Library, but
these days it's simply ITIL 4—a flexible set of practices focused on value. Imagine a
cookbook for service management, packed with recipes like incident resolution and
change enablement.
Speaker 1: Each ingredient is designed to balance stability and innovation. When you
follow the book, you avoid the "too many cooks" problem and keep services tasty.
Speaker 2: So next time someone says "ITIL," picture a restaurant kitchen. Everyone
has a station, the meals come out on time, and customers leave happy.
Speaker 1: You're probably wondering how this applies to landing a job. Recruiters love
candidates who speak the language of ITIL because it means less hand-holding on day
one.
Speaker 2: Think of it like joining a sports team mid-season. If you already know the
playbook, you can jump right into the action. You'll deal with incidents, requests and
changes in any support role, so learning the plays now saves you from awkward
fumbles later.
Speaker 1: Plus, tossing around a few ITIL terms at interviews might just make you
sound like the pro you are becoming.
Speaker 2: The real takeaway is that ITIL 4 gives you a sturdy framework for managing
technology services. It's like having a trusty toolkit when something breaks—you don't
have to guess which wrench fits.
Speaker 1: As you explore the rest of this course, keep that toolkit analogy in mind. You
won't memorise every tool on day one, but knowing they exist means you're ready for
whatever problems pop up.
Speaker 2: So buckle up and enjoy the ride. The better you understand ITIL now, the
easier every other topic will become.
Servicenow Visual Guide
Speaker 1: Welcome to ServiceNow. Think of it as a living map of ITIL in action. Every
form and button matches a step in the framework, so you can see where work flows
next. We'll take a short tour and point out the key bits.
Speaker 2: If you've never opened ServiceNow before, don't worry. It's just a website
with a very organised menu. The goal here is not to master the tool, but to recognise
how incidents and requests move through their lifecycle. Let's dive in.
Speaker 1: Start on the homepage. You'll see tiles for the Service Catalog and Incident
lists. Most new analysts live here. Click into the catalog and you'll find request forms for
common services. Each field is an ITIL data point—category, priority, and short
description.
Speaker 2: The incident form looks similar. Raising a ticket captures details like impact
and urgency, which combine into priority. The form also shows assignment groups. As
we fill it out, notice how required fields enforce consistency. This is ITIL governance
without you having to memorise a textbook.
Speaker 1: Once an incident is logged, watch the state field. It starts as New, then
moves to In Progress when someone picks it up. If we need more information, we set it
to Awaiting Info, which pings the requester automatically.
Speaker 2: When the issue is fixed, change the state to Resolved. After the user
confirms, we mark it Closed. Every update is tracked in the Activity log, forming a
complete audit trail. This visual flow mirrors the textbook ITIL lifecycle, so you can see
each handoff and decision point.
Speaker 1: Now check out the dashboards. These are customisable charts that show
how many incidents sit in each state and which teams are handling them. It's a quick
pulse check on service health.
Speaker 2: You can also view request queues and SLA countdowns. Managers love
these graphs because they highlight bottlenecks at a glance. By reviewing the charts
each day, teams spot trends early and keep priorities aligned with customer impact.
Speaker 1: The real value of this quick tour is seeing ITIL concepts play out in a real
tool. When you log in to ServiceNow, each click represents a step in the process: raising
an incident, updating status, or linking related tasks.
Speaker 2: Remember, the interface is simply a guide. The principles—clear
communication, proper escalation and thorough documentation—apply no matter which
platform you use. ServiceNow just makes them visible. Use this visual map to reinforce
your understanding of ITIL and you'll navigate complex service desks with confidence.
Value Chain
Speaker 1: Imagine the service value chain as a relay race. Each runner hands the
baton to the next, from planning to improving, so customers receive consistent results.
Speaker 2: ITIL lays out six activities—plan, improve, engage, design and transition,
obtain and build, and deliver and support. They aren't a strict sequence but rather a set
of interlocking moves that keep services humming.
Speaker 2: Continual improvement is the glue holding those activities together. After
each handoff, teams look back on what worked, gather metrics and brainstorm tweaks.
Speaker 1: It's like tuning a recipe. You keep tasting and adjusting the flavours so the
next batch turns out even better. Without that feedback loop, the chain would stall.
Speaker 1: In many organisations, teams visualise the value chain on a Kanban board.
They track where work items sit in the flow and highlight delays.
Speaker 2: When a step lags, it's a signal to review the process. Maybe a handover
checklist is missing or a tool doesn't integrate well. Adjustments keep the chain
responsive.
Speaker 2: The value chain only shines when everyone embraces small, steady
improvements. It's a mindset as much as a method.
Speaker 1: Keep asking "how can we do this better?" and you'll help your team deliver
reliable services that evolve with customer needs.
