IT support roles, tiers and channels

Twelve requests reach a service deskservice desk: The first-contact team of IT support, also called the help desk. It records every request as a ticket, fixes known issues with documented procedures and escalates the rest with evidence. in one morning: a forgotten password, a blank monitor, a laptop for a new starter, a VPN that is down for a whole warehouse, an email asking for a payroll login and seven more. Each has a right owner, and a request sent to the wrong team waits in a queue that cannot fix it.

Support work is split into tiers by how deep a problem goes and into roles by where the work happens. You will route the twelve requests with a rule table and then with the facts that change it, follow one ticket up the tiers with its evidence, compare the roles and the five channels requests arrive by, write a follow-the-sunfollow-the-sun: Support shared by desks in different time zones, each working its own daytime and handing its open tickets to the next, so that users are covered around the clock. handover with UTC offsetsHow far a local clock is ahead of or behind Coordinated Universal Time (UTC), written after the time, as in 08:00+05:30 or 13:30-05:00., and list what first-line support owns and what it never does.

Four tiers, each owning the work it can finish

Take three of the twelve. The forgotten password (R01) can be fixed by the user alone, at three in the morning, when the company runs a self-service reset. The blank monitor (R02) needs someone who knows the usual causes: a loose cable, the wrong input, a screen that went to sleep. The VPN that is down for a whole site (R04) needs the engineers who run the network. Each request belongs at the lowest level that can finish it, because every level above adds people and waiting.

That is the tier model. This track numbers four tiers from 0:

Tier 0 runs on a self-service portalself-service portal: A website where users raise requests, read knowledge base articles and finish common tasks such as a password reset themselves, at any hour: tier 0 of the tier model this track uses. and its knowledge baseA library of articles that describe known problems and their documented fixes, written so that users and the service desk can apply them.. Tier 1 is the service desk, the first team a request meets when it needs a person. Moving a ticket up is an escalationescalation: Moving a ticket to people with more skill or access (functional escalation) or with more authority (hierarchical escalation), together with the evidence of what has been tried so far., and it always carries what the lower tier learned.

The model is a convention, not a standard. CompTIA’s A+ Core 2 objectives list escalation levels among the things a ticketing system records, beside the user, the device, the category and the severity, but how many tiers a desk has and what it calls them is the organisation’s choice: some desks merge tiers 1 and 2, and in a small office one person works all four.

Category and impact choose the route, and a few facts change it

Most desks route by two fields every ticket already holds: the category (password, hardware, software, network, access, new starter, security) and the impact (one user, a team, a site, everyone). The program writes that as a rule table of seven rows, where the first row that matches wins. It routes the twelve requests and prints each route beside the one an experienced desk chose:

"""Route twelve support requests with a rule table, then compare each
route with the one an experienced service desk chose."""

# The first row that matches wins. "any" matches every value, and
# "site+" matches an impact of "a site" or "everyone".
RULES = [
    # category, impact, tier, owner
    ("security", "any", None, "security team"),
    ("network", "site+", 3, "network operations"),
    ("software", "site+", 3, "application engineers"),
    ("password", "any", 0, "self-service portal"),
    ("access", "any", 2, "identity and access"),
    ("new starter", "any", 2, "desktop support"),
    ("any", "any", 1, "service desk"),
]

# id, summary, channel, category, impact, facts the table never reads
REQUESTS = [
    ("R01", "Forgotten password", "phone",
     "password", "one user", []),
    ("R02", "Blank monitor after a desk move", "walk-up",
     "hardware", "one user", []),
    ("R03", "Laptop for a new starter", "portal",
     "new starter", "one user", []),
    ("R04", "VPN down at the warehouse", "phone",
     "network", "a site", []),
    ("R05", "Email asks for a payroll login", "email",
     "security", "one user", []),
    ("R06", "Excel closes on one workbook", "chat",
     "software", "one user", []),
    ("R07", "Printer jams on every page", "phone",
     "hardware", "a team", ["supplier contract"]),
    ("R08", "No access to the Finance folder", "email",
     "access", "one user", []),
    ("R09", "Video calls freeze at home", "chat",
     "network", "one user", []),
    ("R10", "Payroll app fails for everyone", "phone",
     "software", "everyone", []),
    ("R11", "New printer for the depot", "portal",
     "hardware", "a team", ["remote site"]),
    ("R12", "Cracked laptop screen", "walk-up",
     "hardware", "one user", ["damaged"]),
]

# The route an experienced desk chose for each request.
DESK = {
    "R01": (0, "self-service portal"), "R02": (1, "service desk"),
    "R03": (2, "desktop support"), "R04": (3, "network operations"),
    "R05": (None, "security team"), "R06": (1, "service desk"),
    "R07": (3, "vendor"), "R08": (2, "identity and access"),
    "R09": (1, "service desk"), "R10": (3, "application engineers"),
    "R11": (2, "field technician"), "R12": (2, "desktop support"),
}


def matches(rule_value, value):
    if rule_value == "any":
        return True
    if rule_value == "site+":
        return value in ("a site", "everyone")
    return rule_value == value


def route(category, impact):
    for rule_category, rule_impact, tier, owner in RULES:
        if matches(rule_category, category) and matches(rule_impact, impact):
            return tier, owner


def name(tier, owner):
    return f"{owner}, no tier" if tier is None else f"tier {tier}, {owner}"


agree = 0
for rid, summary, channel, category, impact, facts in REQUESTS:
    rules = route(category, impact)
    desk = DESK.get(rid)
    print(f"{rid} {summary} ({channel})")
    print(f"    {category}, {impact} -> {name(*rules)}")
    if desk == rules:
        agree += 1
    elif desk is None:
        print("    desk: no route chosen yet")
    else:
        print(f"    desk: {name(*desk)}, because: {', '.join(facts)}")

print()
print(f"Rules and desk agree on {agree} of {len(REQUESTS)} requests.")
counts = {}
for tier, owner in DESK.values():
    key = "security" if tier is None else f"tier {tier}"
    counts[key] = counts.get(key, 0) + 1
order = ["tier 0", "tier 1", "tier 2", "tier 3", "security"]
print("The desk's routes:", ", ".join(f"{k} {counts[k]}" for k in order))

R01 Forgotten password (phone)
    password, one user -> tier 0, self-service portal
R02 Blank monitor after a desk move (walk-up)
    hardware, one user -> tier 1, service desk
R03 Laptop for a new starter (portal)
    new starter, one user -> tier 2, desktop support
R04 VPN down at the warehouse (phone)
    network, a site -> tier 3, network operations
R05 Email asks for a payroll login (email)
    security, one user -> security team, no tier
R06 Excel closes on one workbook (chat)
    software, one user -> tier 1, service desk
R07 Printer jams on every page (phone)
    hardware, a team -> tier 1, service desk
    desk: tier 3, vendor, because: supplier contract
R08 No access to the Finance folder (email)
    access, one user -> tier 2, identity and access
R09 Video calls freeze at home (chat)
    network, one user -> tier 1, service desk
R10 Payroll app fails for everyone (phone)
    software, everyone -> tier 3, application engineers
R11 New printer for the depot (portal)
    hardware, a team -> tier 1, service desk
    desk: tier 2, field technician, because: remote site
R12 Cracked laptop screen (walk-up)
    hardware, one user -> tier 1, service desk
    desk: tier 2, desktop support, because: damaged

Rules and desk agree on 9 of 12 requests.
The desk's routes: tier 0 1, tier 1 3, tier 2 4, tier 3 3, security 1

The table and the desk agree on 9 of the 12. Each difference is a fact the table never reads:

• R07, a printer that jams on every page, is covered by a supplier contract, so the supplier’s engineer repairs it (tier 3, the vendor) and the desk follows the call up.
• R11, a new printer for a depot with no IT staff, needs someone on site: a field technician, not the service desk.
• R12, a cracked laptop screen, is damage that no fix on a call can repair, so it goes to desktop support.

The channel makes no difference to the route either: R05 arrived by email and R12 at the desk, and both would go to the same team by phone. A table is quick and consistent, and the people using it still have to read the facts. Answer the five questions for R07, for R12 or for a request of your own, and watch which routes stay:

In short: a possible attack goes to the security team before anything else, a fault that stops a site goes to engineers, hands-on work rules out tiers 0 and 1, and a supplier contract sends the repair to the vendor.

Escalation moves a ticket to more skill or more authority

R06, a workbook that closes Excel, starts at tier 1 like most software faults that stop one user. The desk tries the documented fixes first; when they fail, the ticket has to move, and how well it moves decides how long the analyst waits. Step through it, and watch what each step adds to the ticket:

That move was a functional escalationfunctional escalation: Moving a ticket to the team with the skill, access or tools to fix it, such as from the service desk to application support. The owner changes and the evidence goes with the ticket.: the ticket went to the team with the skill to fix it, and its owner changed. A hierarchical escalationhierarchical escalation: Taking a ticket to someone with more authority, such as a shift lead or a manager, who can raise its priority, add people, spend money or press a supplier, often while the same team keeps the work. goes to more authority instead: a shift lead or manager who can raise a priority, add people, spend money or press a supplier, often while the same team keeps the work. If R07’s supplier misses the response time its contract promises, the shift lead calls the supplier’s service manager; the repair stays with the supplier, and someone with more authority pushes it.

Either way, the ticket carries its evidence. CompTIA’s objectives name the written parts of a ticket: the issue description, progress notes and the resolution. For an escalation that means:

• who the user is, and which device and version;
• the symptom in the user’s words, and the restatement they agreed with;
• when it started, and what changed;
• the steps that reproduce it;
• every fix tried, with its result;
• the impact: who is stopped, and by when it matters;
• attachments: a screenshot, a log or a copy of the file.

Tier 2 in the figure started from that evidence, and its fix came back down as a knowledge base article, so the next case ends at tier 1.

Roles differ by where the work happens

The tiers say how deep a problem goes; the roles say where the person who fixes it works. Each of the twelve requests meets one of these roles, and some people move between them in a single day:

The NOCNOC: A network operations centre: the team that watches network and service monitoring and fixes outages of shared links, Wi-Fi, VPNs and other network services. sees an outage on its monitoring, often before the first call, which is why the desk sends it site-wide network faults such as R04 at once. The SOCSOC: A security operations centre: the team that watches security alerts and investigates possible attacks, such as phishing reports, unexpected sign-ins and lost devices. Every tier sends it such reports at once. is not a tier above tier 3: it is a separate team that every tier sends possible attacks to straight away. It may be in-house or bought in; NIST’s incident response guide gives outsourcing a SOC to a managed security services provider as one way to staff incident handling.

A managed service providermanaged service provider: A company that delivers, operates or manages IT services for other organisations under contract, often with service levels written in. Its desk may run any tier of a customer's support. (MSP) does support work for other organisations. CISA’s advisory on MSPs describes them as companies that deliver, operate or manage information and communications technology (ICT) services for customers under a contract, and notes that these services usually need trusted network connections and privileged access to customer systems. An MSP’s desk therefore follows each customer’s procedures as strictly as an in-house desk, because a mistake there can reach a customer’s network.

Each channel changes how you work the ticket

The twelve requests came by five channels: four by phone (R01, R04, R07, R10) and two each by chat, email, the portal and walk-up. The route does not depend on the channel, and the exercise below tests exactly that. The method does, because what you can see, how fast the user answers and what gets written down all change. CompTIA’s communication objective asks for the same habits everywhere: restate the issue to check you understood it, avoid jargon, set and meet expectations for the timeline, and follow up later to confirm the user is satisfied. The rest depends on the channel:

Follow-the-sun handovers need times with offsets

A desk that supports users in several countries rarely stays open around the clock in one place. Follow-the-sun support puts desks in different time zones, each working its own daytime and handing its open tickets to the next. The program checks a rota for desks in Pune, Dublin and Bogotá. Each shift is a local time with its UTC offset, and the program turns every shift and handover into UTC:

"""Three desks follow the sun. Each shift is written as local times with
their UTC offsets, so every handover can be checked in UTC."""
from datetime import time

# Offsets from the tz database: Asia/Kolkata is +05:30 all year,
# Europe/Dublin +01:00 in summer and +00:00 in winter, and
# America/Bogota -05:00 with no daylight saving time.
SUMMER = [
    ("Pune", "08:00+05:30", "16:00+05:30"),
    ("Dublin", "11:30+01:00", "19:30+01:00"),
    ("Bogotá", "13:30-05:00", "21:30-05:00"),
]
WINTER = [
    ("Pune", "08:00+05:30", "16:00+05:30"),
    ("Dublin", "11:30+00:00", "19:30+00:00"),
    ("Bogotá", "13:30-05:00", "21:30-05:00"),
]


def utc(text):
    """Minutes after midnight UTC of an ISO time, and the day it falls on."""
    t = time.fromisoformat(text)
    offset = int(t.utcoffset().total_seconds()) // 60
    minutes = t.hour * 60 + t.minute - offset
    return minutes % 1440, minutes // 1440


def show(text):
    minutes, day = utc(text)
    clock = f"{minutes // 60:02d}:{minutes % 60:02d} UTC"
    return clock + {-1: " (day before)", 0: "", 1: " (next day)"}[day]


def rota(title, desks):
    print(title)
    for desk, start, end in desks:
        print(f"  {desk:7}{start} to {end} = {show(start)} to {show(end)}")
    for (a, _, end), (b, start, _) in zip(desks, desks[1:] + desks[:1]):
        gap = (utc(start)[0] - utc(end)[0]) % 1440
        if gap == 0:
            print(f"  {a} -> {b} at {show(start)[:9]}: no gap")
        elif gap < 720:
            print(f"  {a} -> {b}: {gap} minutes with no desk open")
        else:
            print(f"  {a} -> {b}: {1440 - gap} minutes with two desks open")


rota("Summer rota", SUMMER)
rota("Winter rota", WINTER)

print()
print('A note says "call back at 16:00 IST". Three zones write IST:')
for where, text in [("India, all year", "16:00+05:30"),
                    ("Ireland, summer", "16:00+01:00"),
                    ("Israel, winter", "16:00+02:00")]:
    print(f"  {where:16}{text} = {show(text)}")

Summer rota
  Pune   08:00+05:30 to 16:00+05:30 = 02:30 UTC to 10:30 UTC
  Dublin 11:30+01:00 to 19:30+01:00 = 10:30 UTC to 18:30 UTC
  Bogotá 13:30-05:00 to 21:30-05:00 = 18:30 UTC to 02:30 UTC (next day)
  Pune -> Dublin at 10:30 UTC: no gap
  Dublin -> Bogotá at 18:30 UTC: no gap
  Bogotá -> Pune at 02:30 UTC: no gap
Winter rota
  Pune   08:00+05:30 to 16:00+05:30 = 02:30 UTC to 10:30 UTC
  Dublin 11:30+00:00 to 19:30+00:00 = 11:30 UTC to 19:30 UTC
  Bogotá 13:30-05:00 to 21:30-05:00 = 18:30 UTC to 02:30 UTC (next day)
  Pune -> Dublin: 60 minutes with no desk open
  Dublin -> Bogotá: 60 minutes with two desks open
  Bogotá -> Pune at 02:30 UTC: no gap

A note says "call back at 16:00 IST". Three zones write IST:
  India, all year 16:00+05:30 = 10:30 UTC
  Ireland, summer 16:00+01:00 = 15:00 UTC
  Israel, winter  16:00+02:00 = 14:00 UTC

In summer the shifts meet exactly: the handovers fall at 10:30, 18:30 and 02:30 UTC. In winter the same local hours break the rota, because the tz database gives Europe/Dublin +01:00 in summer and +00:00 in winter, while Asia/Kolkata stays at +05:30 and America/Bogota at −05:00. Dublin then opens an hour after Pune closes, leaving 60 minutes with no desk open, and stays open an hour into Bogotá’s shift. Plan a rota in UTC and let the local hours move.

The last lines show why a note must never say only “IST”. The tz database uses that abbreviation for three offsets: India Standard Time (+05:30), Irish Standard Time (+01:00, which Ireland uses in summer) and Israel Standard Time (+02:00). “Call back at 16:00 IST” can mean 10:30, 15:00 or 14:00 UTC, so write 16:00+05:30, or the time in UTC, in every handover note and ticket.

What tier 1 owns, and what it never does

First-line support owns five things on every ticket:

1. Confirm who the user is, with the checks the procedure lists.
2. Record the ticket: the user, the device, the category, the impact and the description.
3. Fix known issues with documented procedures.
4. Escalate with evidence when no documented fix works.
5. Keep the user informed: who has the ticket, the next step and when it will come.

It never does three things, however the request is put. It never shares credentials, its own, a colleague’s or a service account’s, and never asks a user for a password or a sign-in code. It never skips an identity check or an authorisation that its procedure requires. And it never works on a system it is not authorised to touch, even when it could get in.

Attackers test exactly these rules. CISA’s advisory on the Scattered Spider group describes criminals who target large companies and the help desks those companies contract for IT support. Posing as employees, the group’s callers asked help desk staff to reset a password and to move the employee’s MFAmulti-factor authentication (MFA): Authentication that requires at least two independent factors from different types: something you know, something you have, or something you are. More in “Passwords, MFA and passkeys for support” to “a device they control”, and their first calls only learned how a desk’s resets work. The personal details they quoted came from social media, open sources, commercial intelligence tools and database leaks, so a caller who knows an employee number and a manager’s name has proved nothing. Step through a reset done by the rules, then a second call that fails the check:

The desk trusted only contact details already on file, and the second caller’s urgency and new phone changed nothing. Moving a user’s MFA to a new device gets the same check as a reset, because whoever holds the second factor holds the account.

When no documented fix exists yet, tier 1 still needs a way to work: the next lesson builds the troubleshooting method it uses.

Practise: route the twelve requests yourself

Turn the desk’s judgement into code. The exercise gives the rules in order, facts included, and its sample tests replay the twelve requests and the cases where the order matters, such as a damaged laptop under a supplier contract.

def route(request):
    """Return (tier, owner) for a support request.

    request has "category", "impact" and "facts" (a list). The tier is 0
    to 3, or None for a security report, which leaves the tiers.
    """
    tier, owner = 1, "service desk"
    return tier, owner

from route import route


def ask(category, impact="one user", facts=(), channel="phone"):
    """A request as the desk records it."""
    return {"category": category, "impact": impact, "facts": list(facts), "channel": channel}


def test_security_leaves_the_tiers():
    """sends a security report to the security team, whatever its impact or its facts"""
    assert route(ask("security", channel="email")) == (None, "security team")  # R05
    assert route(ask("security", "a site")) == (None, "security team")
    # A laptop under a supplier contract, back with its seal broken: security first, no repair yet.
    tampered = ask("security", facts=["supplier contract", "damaged"], channel="walk-up")
    assert route(tampered) == (None, "security team")


def test_supplier_contract():
    """sends a device under a supplier contract to the vendor, even when it is damaged"""
    assert route(ask("hardware", "a team", ["supplier contract"])) == (3, "vendor")  # R07
    assert route(ask("hardware", "one user", ["damaged", "supplier contract"])) == (3, "vendor")


def test_site_wide_faults():
    """sends faults that stop a site or everyone to the engineers"""
    assert route(ask("network", "a site")) == (3, "network operations")  # R04
    assert route(ask("software", "everyone")) == (3, "application engineers")  # R10
    assert route(ask("network", "everyone")) == (3, "network operations")


def test_one_user_or_a_team_stays_with_the_desk():
    """keeps faults of one user or one team with the service desk"""
    assert route(ask("network")) == (1, "service desk")  # R09
    assert route(ask("software", channel="chat")) == (1, "service desk")  # R06
    assert route(ask("software", "a team")) == (1, "service desk")
    assert route(ask("hardware", channel="walk-up")) == (1, "service desk")  # R02


def test_hands_on_work():
    """sends work that needs hands on a device to a technician"""
    assert route(ask("hardware", "a team", ["remote site"])) == (2, "field technician")  # R11
    assert route(ask("hardware", facts=["damaged"])) == (2, "desktop support")  # R12
    assert route(ask("hardware", facts=["damaged", "remote site"])) == (2, "field technician")


def test_categories_with_their_own_team():
    """routes passwords, access and new starters to their owners"""
    assert route(ask("password")) == (0, "self-service portal")  # R01
    assert route(ask("access", channel="email")) == (2, "identity and access")  # R08
    assert route(ask("new starter", channel="portal")) == (2, "desktop support")  # R03


def test_channel_and_request_unchanged():
    """gives the same route on every channel and leaves the request as it was"""
    by_phone = ask("hardware", facts=["damaged"], channel="phone")
    in_person = ask("hardware", facts=["damaged"], channel="walk-up")
    assert route(by_phone) == route(in_person)
    assert by_phone == ask("hardware", facts=["damaged"], channel="phone")

Then test yourself on all seven ideas, from the tiers to the reset that tier 1 refuses; the questions adapt to your answers as you go:

Interview questions

Warm-up (fresher): how do functional and hierarchical escalation differ, and when do you use each?

Functional escalation moves a ticket to a team with more skill or access: the service desk assigns a workbook that closes Excel to application support, or a site-wide VPN fault to network operations, because it cannot fix them itself. The owner changes, and the evidence goes with the ticket: what was tried, the results and how to reproduce the fault. Hierarchical escalation goes to more authority: a shift lead or manager who can raise the priority, add people, spend money or press a supplier that has missed its contract’s response time. The same team often keeps working while that happens. Use functional escalation when the current team lacks the skill, access or tools, and hierarchical escalation when the problem is time, priority or a decision above your role. A serious incident often needs both at once.

Two harder cases follow: a site outage that floods the desk with calls, and an urgent request for access made in an executive’s name. For each, note whom you would tell first and which check you would refuse to skip, then open the question and hold your note against its first step:

Key takeaways

• This track’s tier model has four levels: tier 0 self-service, tier 1 the service desk with documented fixes, tier 2 specialist teams for deeper device, identity and application work, and tier 3 engineers or the vendor; each request belongs at the lowest tier that can finish it.
• Category and impact route most requests, but facts such as a supplier contract, a remote site or damage change the route, and a possible attack goes to the security team before anything else.
• Functional escalation moves a ticket to more skill and hierarchical escalation to more authority, and both carry the evidence: the steps, every fix tried and its result.
• Roles differ by where the work happens: the help desk works mostly remotely, desktop support at the user’s desk or the bench, field technicians at sites with no IT staff, the NOC on networks, the SOC on security alerts, and an MSP does any of these for other organisations.
• Each channel changes the method rather than the route, and follow-the-sun handovers write every time with its UTC offset, because IST alone can mean +05:30, +01:00 or +02:00.
• Tier 1 confirms identity, records the ticket, fixes known issues, escalates with evidence and keeps users informed, and it never shares credentials, skips a required check or works on a system it is not authorised for.