One point of contact
Users call, chat or log one place, whatever the fault. The desk works out who fixes it, so users never need to know the org chart.
1st, 2nd and 3rd line support
IT support that fixes it at the first line that can
I design support models for infrastructure, networks and desktops: who fixes what at each line, how a ticket moves, how the clocks run, and how knowledge moves fixes closer to the user. This page follows tickets through the service desk, the NOC (network operations centre) and the engineers behind them, with tools to try.
Support lines
Who fixes what, from line 0 to the vendor
IT support is organised in lines, also called tiers or levels. Each line has more skill and more access than the one before, and costs more per ticket. The aim is to fix each fault at the first line that can fix it safely, and to pass it down cleanly when it cannot.
Swipe sideways to see the whole diagram.
Line 0 is everything users can do without waiting for a person: a password reset portal, a status page, searchable knowledge, a request catalogue and automated fixes. Every contact it absorbs frees the desk for work that needs a human. A good line 0 still records what it fixed, so trends stay visible.
The service desk is the single point of contact. It logs every contact, sets the category and priority, and fixes what it can on the first contact using knowledge articles: lockouts, access, how to questions and known errors with a scripted workaround. What it cannot fix, it escalates with a complete note.
Second line teams are grouped by skill: desktop and deskside support, the network operations centre (NOC), server operations and application support. They hold admin rights and deeper tools. They swap hardware, change a switch port, rebuild a laptop or restart a service, usually as pre approved standard changes.
Third line are the engineers who design and build the platforms: network, server, storage, cloud and security specialists. They take faults that need design knowledge or a non standard change, and lead root cause work. Their time is the scarcest, so a clean escalation matters most here.
Fourth line sits outside the organisation: the vendor's technical assistance centre (TAC), the carrier, the hardware maker or a managed service provider. Contracts set what they must do and how fast. I raise vendor cases at the right severity with logs attached, and keep our own ticket open until their fix is proved.
Each step down adds a handoff, waiting time and cost. MetricNet's 2017 averages put a 1st line ticket at about $22 and a 2nd line ticket at about $104. Shift left moves each repeatable fix closer to the user: from engineers to the desk, and from the desk to self service, through knowledge and automation.
What each line does
| Line | Who | What it fixes | Access and tools | What it hands on |
|---|---|---|---|---|
| Line 0 | The user, helped by the portal and automation | Password resets, status checks, how to questions, catalogue requests | Self service portal, virtual agent, knowledge base | A ticket, created automatically when self help fails |
| 1st line | Service desk analysts | Lockouts, access, known errors, simple software and device faults | ITSM (IT service management) tool, knowledge, remote support, read only consoles | A complete escalation note to the right group |
| 2nd line | Deskside, NOC, server operations, application support | Hardware swaps, port and VLAN (virtual local area network) changes, rebuilds, service restarts, configuration | Admin rights, management consoles, monitoring, standard changes | Faults that need design knowledge or a non standard change |
| 3rd line | Network, server, storage, cloud and security engineers | Design faults, complex routing, platform bugs, root cause | Full rights, lab, change authority, vendor contacts | Vendor cases with evidence attached |
| 4th line | Vendors, carriers, makers, managed service providers | Software bugs, failed parts, circuit faults | Their own TAC tools, under contract | A fix, a part or a bug reference back to us |
One owner to the end
In the models I design, the service desk keeps ownership of each incident even after escalating it. It chases the resolver group, updates the user and confirms the fix before closing.
Lines follow skills and access
A line is about what a team can safely change and what it knows, not about seniority. A senior desk analyst is still 1st line, and that is a career in itself.
Incident, problem and change records, the priority matrix and example targets are on the support and service management page. This page is about the people and the flow: who fixes what, how a ticket moves, and how to keep it moving.
The practices of ITIL (originally the IT Infrastructure Library) behind the service desk and resolver groups are on my ITIL 4 page.
Channels
Many ways in, one queue behind them
Users reach support by portal, chat, phone, email, walk up and, increasingly, without asking at all, because monitoring found the fault first. I design the channels so the cheapest one that works is the easiest one to use, and so every contact ends up as a record in the same queue.
Swipe sideways to see the whole diagram.
Every channel lands in one queue in one tool, so nothing is handled off the books. Portal and chat contacts meet line 0 first, where a virtual agent or a knowledge article fixes many before a person is involved. Monitoring raises its own tickets and routes them straight to the right resolver group.
Channels, and what each is good at
| Channel | Best for | Watch out for |
|---|---|---|
| Self service portal | Requests from the catalogue, password resets, status, knowledge | Forms that ask for everything. I ask only what the resolver needs. |
| Chat and virtual agent | Quick how to questions, status, guided fixes. An analyst can typically run two or three chats at once. | A bot that loops. There must always be a way to reach a person. |
| Phone | Urgent faults, priority 1 and 2, users who cannot log in at all | Peaks at 9am and after lunch. It is the costliest channel, so I staff it for the peaks. |
| Low urgency, users with no portal access | Unstructured and slow to triage. I turn each email into a ticket at once and point repeat senders to the portal. | |
| Walk up or tech bar | Hardware swaps, new starters, hands on fixes | Queues at the counter. A booking slot and a loan pool keep it moving. |
| Collaboration chat | Teams or Slack messages linked to the ITSM tool | Fixes done in private messages leave no record. Every fix still needs a ticket. |
| Monitoring | Faults found before users notice | Noise. Only alerts that need action become tickets. |
Where the desk sits
| Desk model | How it works | When I use it |
|---|---|---|
| Local | A desk at each site, near its users | Large sites with hands on work, or local language needs |
| Central | One desk for every site | Most organisations. Consistent quality, one queue, easier to staff. |
| Virtual | Analysts in several places working one queue in one tool | Home working, or several offices sharing the load |
| Follow the sun | Desks in time zones that hand the queue over at the end of each day | Global estates needing 24 hour cover in business hours |
With follow the sun, the handover between desks is the weak point. I require a written handover of every open priority 1 and 2 ticket, and each desk works to the same knowledge base.
Tickets
The ticket is the memory of every fix
A ticket is how support remembers: who was affected, what was tried, who owns it now and how it was fixed. A ticket that is easy to read moves faster through every line, and a closed ticket that is complete feeds the reports, the knowledge base and problem management.
Swipe sideways to see the whole diagram.
The ticket records the caller, the affected service or configuration item (CI), a category, the impact and the urgency, in the user's words and in mine. Impact and urgency set the priority, and the priority starts the clocks. The desk tries a fix while the user is still on the line.
If the desk cannot fix it, the ticket goes to an assignment group, the team that owns that kind of fault. Accepting it stops the response clock. The ticket has one owner at a time, and every finding is written as a work note in the ticket, never only in a private chat.
A ticket that is waiting must say what for. ServiceNow offers four reasons: awaiting caller, change, problem or vendor. In the contracts I write, only waiting for the caller pauses the resolve clock. Waiting for our own supplier is still our time.
Resolved means service is back. The engineer records a resolution code and notes a stranger could follow, links the knowledge article used or written, and links a problem record if the fault will come back. The user is asked to confirm.
The ticket closes when the user confirms, or after a set number of days in resolved. In ServiceNow the property
glide.ui.autoclose.timesets those days. A closed record is checked for its category and cause, because reports and problem trends are built from them.If the fault returns inside the window, the user reopens the same ticket and its history stays together. Duplicates and contacts that were never incidents are cancelled and linked to the main ticket. Nothing is deleted, so the numbers stay honest.
The fields that make a ticket useful
| Field | Why it matters | A good example |
|---|---|---|
| Short description | It is what every queue view and report shows | "Floor 3 east: no wired network on desks 3E01 to 3E12" |
| Service and CI | It routes the ticket and shows the impact through the CMDB (configuration management database) | Service: Corporate LAN (local area network). CI: switch LON-3E-AS01 |
| Category | It drives routing, knowledge suggestions and trend reports | Network, then LAN, then Access port |
| Impact and urgency | Together they set the priority, so they must be chosen, not left at the default | Impact: a team. Urgency: high, as they cannot work. |
| Contact and hours | Second line can call back without asking the desk again | Mobile number, on site until 17:00 |
| Work notes | The next person starts where the last one stopped | "Port Gi1/0/14 err disabled, port security. Cleared, user online 10:42." |
| Resolution code and notes | They make the record useful for problem management | "Workaround: cleared err disabled port. Cause: unapproved hub on desk." |
Incident or request?
A request is something expected, such as a new starter's laptop or access to a folder, fulfilled from the catalogue. An incident is something broken. Mixing them hides real faults inside routine work, so they are separate record types with separate targets.
Categories that people can use
I keep categories to two or three levels and fewer than about a hundred leaf values, so an analyst can pick one in seconds. A category nobody chooses is deleted, and "other" is reviewed weekly.
One ticket per fault
When fifty users call about one outage, there is one parent incident and fifty child tickets linked to it. Updating the parent updates everyone, and closing it closes them all.
The state names above follow ServiceNow's. Jira Service Management and other tools use different names and let you design your own workflow, but the same stages exist in every good one. How impact and urgency become a priority is on the support and service management page.
Clocks
How the clock really runs, hour by business hour
An SLA (service level agreement) target such as "resolve in three business days" depends on when the clock runs, when it pauses and when it stops. Most arguments about breaches come from rules nobody wrote down. Step through one ticket, then try your own.
Swipe sideways to see the whole diagram.
A P3 (priority 3) ticket is logged on Thursday at 16:00 with a resolve target of three business days. Business hours here are 08:00 to 18:00, Monday to Friday, so the target is 30 business hours, not 72 clock hours. The clock starts when the ticket is logged, not when someone picks it up.
The clock stops at 18:00 and restarts at 08:00, and Saturday and Sunday do not count. The same ticket on a 24 by 7 clock would be due on Sunday at 16:00. Which clock applies is set by the service and its priority, and written in the contract.
On Friday at 10:00 the engineer needs the user to test, but the user is in meetings until 14:00. The ticket goes on hold, awaiting caller, and those four hours are not counted. Waiting for our own supplier would not pause it.
On Monday at 15:00 half of the 30 hours have gone and there is no clear cause. The tool warns the group and its team lead. This is when I escalate, while there is still time to act, not at the breach.
The ticket is due on Wednesday at 10:00: 30 business hours, plus the 4 hour pause, plus the nights and the weekend. The tool works it out, but everyone on the desk should be able to check it by hand.
Fixed on Tuesday at 15:00 and confirmed by the user: 25 business hours used, inside the target. The response time, the resolve time and every pause stay on the ticket, because the monthly service report is built from them.
Try it: when is this ticket due?
The targets are the example targets from the support and service management page. Business hours are 08:00 to 18:00, Monday to Friday, with no bank holidays.
- Clock
- Business hours, 08:00 to 18:00, Monday to Friday
- Respond by
- Friday 10:00
- Half time warning
- Monday 15:00, the following week
- Resolve by
- Wednesday 10:00, the following week
P3 runs in business hours: 30 business hours to resolve, plus 4 hours on hold. Nights and weekends do not count.
The clock rules I write into every contract
- Start at logging. The clocks start when the ticket is logged, not when someone accepts it.
- Response means a person. An automatic email is not a response. A response is a named person who has read the ticket and contacted the user.
- Name the hours. Business hours are set per service, with the time zone and the bank holiday calendar named in the contract.
- Pause only for the caller. Each pause has a reason and a timestamp. Waiting for a supplier or another internal team never pauses the clock.
- Restore, then stop. The resolve clock stops when service is restored, even if root cause work carries on in a problem record.
- Moving it is not a restart. Reassigning a ticket never restarts its clock. Each group has its own OLA (operational level agreement) timer inside the SLA.
- Report every breach. A breach with a good reason is still reported, with the reason. Hiding breaches hides the next one.
Escalation
Pass it on once, with everything the next line needs
Escalation comes in two kinds. Functional escalation passes the work to a team with more skill or access. Hierarchical escalation tells managers, so they can add people or pressure. Both work only with a clear note and a clear owner. A ticket that bounces between queues is the most common way support wastes time.
Swipe sideways to see the whole diagram.
A cold handoff. The desk passes the ticket on with "user has network issue" and little else. Network says it is the laptop, desktop says it is the server, and the server team sends it back. Four reassignments later the user has waited two days and told the story four times.
A warm handoff. The desk escalates with a full note (scope, tests done, evidence and impact) to the group the evidence points at. For urgent faults the analyst stays on the call and brings the engineer in, so the user explains once. One hop, and the fix starts at once.
Hierarchical escalation runs alongside. At half time with no clear cause, or when a contract or a critical service is at risk, the team lead or duty manager is told. They add people, call a swarm or contact the supplier's escalation manager. Functional escalation moves the work. Hierarchical escalation moves attention.
The escalation note I ask every analyst to write
- Symptom
- What the user sees, in their words, with the exact error message.
- Scope
- Who and where: one user, a team, a site. Since when, and is it constant or intermittent?
- Impact
- What they cannot do, and the business effect. This justifies the priority.
- What changed
- Recent changes, moves, updates or new kit, from the user and from the change calendar.
- Tests done
- Each check and its result, so nobody repeats it: "Wi-Fi works, wired does not, two other desks fine".
- Evidence
- Screenshots,
ipconfig /alloutput, log extracts and times, attached to the ticket. - Workaround
- Anything in place now, such as a loan laptop or Wi-Fi, and whether it is holding.
- The ask
- What I need from the next group, and the best time to reach the user.
A ticket that comes back for more information costs a full queue cycle. I review a sample of escalations every week, score them against these headings, and feed the gaps into coaching and knowledge. Each group also agrees its acceptance rules: what it needs before it will take a ticket.
Try it: who fixes this?
Pick a symptom to see who owns it, what 1st line checks first, what goes in the note, and how to stop it coming back. Owners and priorities are typical. Each organisation sets its own.
Password expired or account locked
- Who fixes it
- Line 0, or 1st line
- Typical priority
- P4 for one user, or P3 if they cannot work at all
- 1st line checks
- Verify identity first, using the method in the security policy, never the caller's number alone. Check whether the account is locked or the password expired, and whether it comes from Active Directory.
- Put in the note
- Rarely escalated. If lockouts keep coming back, an old password saved on a phone or a mapped drive is the usual cause, so note which sign in logs show the failures.
- Shift left
- Self service password reset with MFA (multifactor authentication). With password writeback, on premises accounts can be reset too.
New starter needs a laptop and access
- Who fixes it
- A service request for 2nd line deskside and the access team, from the catalogue
- Typical priority
- Not an incident. It has a request target, such as five business days' notice.
- 1st line checks
- Is there an approved request from the manager or HR (human resources)? Which role template applies?
- Put in the note
- Start date, location, role, kit needed and the approvals already given.
- Shift left
- Zero touch builds with Windows Autopilot, and access by role, so most of it happens with no analyst involved. See the end user computing page.
One user has no wired network at their desk
- Who fixes it
- 2nd line NOC
- Typical priority
- P4 for one user with a workaround such as Wi-Fi, or P3 with none
- 1st line checks
- Does Wi-Fi work? Do nearby desks work? In
ipconfig /all, an address starting 169.254 means no DHCP (Dynamic Host Configuration Protocol) answer. Read the wall port label. - Put in the note
- Wall port label, desk number, the computer's MAC (media access control) address, the
ipconfigoutput and the time it stopped. - Shift left
- A read only port lookup lets 1st line see the switch port state, so only real faults reach the NOC.
A whole floor has lost Wi-Fi
- Who fixes it
- 2nd line NOC, then 3rd line wireless if the controller or the radio design is at fault
- Typical priority
- P2: a team or more cannot work properly
- 1st line checks
- Check the monitoring map and known incidents. Is it one SSID (service set identifier) or all, one floor or the building? Does wired work there?
- Put in the note
- Area, SSIDs affected, device types, start time, and whether wired works there.
- Shift left
- Monitoring of access points and controllers raises the ticket before users call.
A whole site is down
- Who fixes it
- The NOC, run as a major incident, with the carrier as 4th line
- Typical priority
- P1
- 1st line checks
- Is the site down in monitoring? Is the carrier showing an outage? Is there power at the site? Declare a major incident early.
- Put in the note
- Site, time, what is down (internet, WAN (wide area network) or voice) and the carrier circuit references.
- Shift left
- Monitoring raises it in seconds, and the NOC opens the carrier case before users ring.
Laptop will not start, or asks for a BitLocker recovery key
- Who fixes it
- 1st line for the key, 2nd line deskside for hardware
- Typical priority
- P3 for one user, P2 for a shared device a team relies on
- 1st line checks
- Verify identity, then read the recovery key from Entra ID, Intune or Active Directory. Ask what changed: a firmware update, a new dock, a repair.
- Put in the note
- Device name and asset tag, the error on screen, recent updates, and whether a loan laptop was issued.
- Shift left
- Users can read the key for their own device from their account page after signing in elsewhere, if policy allows. A loan pool keeps them working while the laptop is fixed.
A business application is slow for everyone
- Who fixes it
- 2nd line application support, then 3rd line infrastructure if the platform is at fault
- Typical priority
- P2, or P1 for a critical service
- 1st line checks
- Check the status page and monitoring. Is it every user or one site, every function or one transaction?
- Put in the note
- Which function, how slow in seconds, since when, which sites, and any recent change.
- Shift left
- Synthetic transactions test the application every few minutes, so support sees the slowdown first.
Cannot print
- Who fixes it
- 1st line, then 2nd line deskside for the printer itself
- Typical priority
- P4, unless a warehouse label printer stops; then P2 or higher
- 1st line checks
- Which printer and queue? Is the job stuck? Does anyone else print to it? Is it out of paper or toner?
- Put in the note
- Printer name and location, the error shown, and who else is affected.
- Shift left
- Cloud printing with automatic driver install, and a knowledge article with pictures.
A suspicious email has arrived
- Who fixes it
- The security operations centre (SOC)
- Typical priority
- Set by impact: higher if anyone clicked a link or entered a password
- 1st line checks
- Did the user click, open an attachment or enter details? Ask them to use the report button, not to forward it.
- Put in the note
- Whether anything was clicked or entered, the time, and the report reference.
- Shift left
- A report button in the mail client sends the message and its headers straight to the security team.
VPN (virtual private network) fails for one remote user
- Who fixes it
- 2nd line network or remote access team
- Typical priority
- P3 for one user
- 1st line checks
- Does the internet work at home? Which error code? Which client version? Did the MFA prompt arrive? Does it work on a phone hotspot?
- Put in the note
- Error code and time, client version, location and network type, and whether MFA prompted.
- Shift left
- Always on VPN or zero trust access removes most of these calls, and a self check page tests the user's connection.
Server disk nearly full alert
- Who fixes it
- 2nd line server operations, routed straight from monitoring
- Typical priority
- P3, rising to P2 if it will fill within hours
- 1st line checks
- None at 1st line. The alert goes straight to the resolver group.
- Put in the note
- Written by the monitoring tool: server, volume, percentage used and growth rate.
- Shift left
- Automation clears known temporary files and old logs, then closes the alert if the space comes back.
A cloud service is down, such as email
- Who fixes it
- The service owner, with the provider as 4th line
- Typical priority
- P1 or P2, by how many users and how critical the service is
- 1st line checks
- Check the provider's service health page in its admin portal. Post a status message so users stop calling.
- Put in the note
- The provider's incident reference, and the users and functions affected.
- Shift left
- A status banner on the portal and a message on the phone line answer most callers before they reach an analyst.
| Symptom | Who fixes it | Typical priority |
|---|---|---|
| Password expired or account locked | Line 0, or 1st line | P4 for one user, or P3 if they cannot work at all |
| New starter needs a laptop and access | A service request for 2nd line deskside and the access team, from the catalogue | Not an incident. It has a request target, such as five business days' notice. |
| One user has no wired network at their desk | 2nd line NOC | P4 for one user with a workaround such as Wi-Fi, or P3 with none |
| A whole floor has lost Wi-Fi | 2nd line NOC, then 3rd line wireless if the controller or the radio design is at fault | P2: a team or more cannot work properly |
| A whole site is down | The NOC, run as a major incident, with the carrier as 4th line | P1 |
| Laptop will not start, or asks for a BitLocker recovery key | 1st line for the key, 2nd line deskside for hardware | P3 for one user, P2 for a shared device a team relies on |
| A business application is slow for everyone | 2nd line application support, then 3rd line infrastructure if the platform is at fault | P2, or P1 for a critical service |
| Cannot print | 1st line, then 2nd line deskside for the printer itself | P4, unless a warehouse label printer stops; then P2 or higher |
| A suspicious email has arrived | The security operations centre (SOC) | Set by impact: higher if anyone clicked a link or entered a password |
| VPN (virtual private network) fails for one remote user | 2nd line network or remote access team | P3 for one user |
| Server disk nearly full alert | 2nd line server operations, routed straight from monitoring | P3, rising to P2 if it will fill within hours |
| A cloud service is down, such as email | The service owner, with the provider as 4th line | P1 or P2, by how many users and how critical the service is |
Shift left
Move each fix closer to the user
Shift left means fixing each kind of fault at the earliest line that can do it safely: engineers write it down so the desk can fix it, and the desk automates it so users can fix it themselves. It is the biggest lever on cost and on how fast users get back to work.
Swipe sideways to see the whole diagram.
Before. The desk logs and routes. Engineers spend their days on password resets, port changes and the same printer fault, and the queue for real faults grows. These shares are indicative, and every estate is different.
With knowledge. Engineers write down each repeatable fix as an article the desk can follow, and 1st line gets safe tools: a read only port lookup, a BitLocker key viewer, a password reset tool with an audit trail. More is fixed on the first contact, and 2nd line gets fewer, better tickets.
With automation. The routine fixes move to the user: self service password reset, catalogue items that build themselves, bots that clear a print queue or restart a known service. The desk shrinks its routine work and spends its time on harder calls and on writing knowledge.
Knowledge that is written while fixing
The method I follow for knowledge is KCS (Knowledge-Centered Success), from the Consortium for Service Innovation. It was called Knowledge-Centered Service until 2026. Its idea is simple: knowledge is a by product of solving tickets, not a separate project. Version 6 of the practices guide arranges its eight practices in two loops.
Swipe sideways to see the whole diagram.
In the solve loop, the analyst searches the knowledge base early, in the user's words. If an article fits, they reuse it and improve it on the spot. If not, they capture the fix as a new article in a set structure. The evolve loop uses that data to keep content healthy, build knowledge into the ticket tool, measure the right things and lead the change.
| Article state | What it means | Who sees it |
|---|---|---|
| Work in progress | The question and the environment are captured, but there is no answer yet. Meant to be short lived. | Support staff |
| Not validated | There is an answer, but confidence is low: little use yet, or not yet up to the content standard. | Support staff, usually |
| Validated | Complete, accurate, reusable and written to the standard. | Support staff, and users when published to the portal |
| Archived | Out of search results but not deleted. It can still be opened from a linked ticket and restored. | Found through linked tickets or advanced search |
The four confidence values from the KCS practices guide. Tools such as ServiceNow and Salesforce offer KCS article states that follow them.
What I shift left first
- Start with volume. I take the 20 most common contacts from a year of tickets. They usually cover a large share of the desk's work.
- Read before write. Fixes that need only read access move first: checking a port, a licence, a mailbox size, a sync state.
- Give safe tools. Each tool for 1st line does one job, with its own role and an audit trail, instead of handing out admin rights.
- Document, then automate. A fix is written down and proved by people before a bot runs it. Automating a fix nobody understands hides the fault.
- Measure the shift. First contact resolution, the escalation rate per category and article reuse show whether it worked.
Swarming
Bring the people to the ticket, not the ticket to the people
Tiers keep routine work cheap, but every handoff adds a wait. Swarming turns that round for the hard cases: the analyst who took the call keeps the ticket, and the people with the right skills join them. Most good support models use both.
Swipe sideways to see the whole diagram.
Tiered. The ticket moves down a line at a time. Each handoff adds a queue, a wait and another person reading the history. It suits high volumes of known faults. It suits new or cross domain faults badly, because they bounce between groups.
Swarming. The right people come to the ticket instead of the ticket going to people. The analyst opens a channel, and network, server and application specialists with the relevant skills join it. The person who took the ticket keeps it to the end. The Consortium for Service Innovation calls its version Intelligent Swarming.
Blended. Most teams I work with blend the two. Known issues follow the knowledge base and stay cheap. New, complex or cross domain issues go to a swarm early. Every swarm ends with a new knowledge article, so the next one is a known issue.
Tiers and swarms compared
| Question | Tiered | Swarming |
|---|---|---|
| Who owns the ticket? | Whoever has it now | The first person to take it, to the end |
| How does help arrive? | The ticket moves to the next queue | Specialists join the work where it is |
| Best for | High volumes of known faults with clear runbooks | New, complex or cross domain faults |
| Risk | Tickets bounce and users repeat themselves | Experts get pulled into everything without rules |
| What it needs | Clear group boundaries and acceptance rules | A skills directory, a chat tool linked to tickets, and a culture of helping |
| What it measures | Resolution per line, escalation rate | Time to resolve, people per ticket, articles created |
How I run a swarm
- One channel per ticket. The swarm channel is named after the ticket and linked to it, so the record stays complete.
- A named owner. One person drives the swarm, updates the user and closes the ticket.
- Pull by skill. People are invited from a skills directory, not by who happens to be online.
- Time boxed. A swarm that runs past an agreed time, such as an hour, goes to the team lead to decide what next.
- Leave knowledge behind. The swarm is not finished until the fix is written down.
Network support
A network fault, worked line by line
Network faults are where clean tiers pay off most, because the evidence lives in different places: on the user's laptop, on the access switch, in the routing tables and with the carrier. Each line checks what it can see and passes on what it found.
Swipe sideways to see the whole diagram.
A user on desk 3E14 has no network. The desk asks first: one user or many, wired and Wi-Fi, since when? Wi-Fi works and the neighbours are fine, so it is one desk and one port. The desk checks monitoring and the known incidents before touching anything.
With the user on the call, the desk runs
ipconfig /all. An address starting 169.254 means the laptop got no answer from DHCP. The desk records the output and the wall port label, and escalates to the NOC with a full note, priority 4 because Wi-Fi is a workaround.The NOC finds the switch from the port label and runs
show interfaces status err-disabled. Port Gi1/0/14 was shut by port security: a second MAC address appeared on it, from a small hub someone plugged in at the desk.The hub is removed, then the port is reset with
shutdownandno shutdownunder a standard change. The user is online again at 10:42. The NOC writes a knowledge article, so next time 1st line can spot the cause with a read only port lookup.Had many users or several sites lost the network, the NOC would raise it to 3rd line and the incident manager straight away. Network engineers look at the shared parts: the core and the WAN edge, with
show ip route,show ip bgp summaryand the routing logs.If the circuit is down, the NOC opens a carrier case with the circuit ID, the time, interface errors and light levels. If it is a software bug, 3rd line opens a TAC case with
show tech-supportattached, at a severity that matches the impact.
1st line: the user side
The desk works from the user's device, with the user on the call, and from read only views of monitoring. It does not log on to network kit.
| Check | Command | What it tells me |
|---|---|---|
| Address, gateway and DNS (Domain Name System) | ipconfig /all | An address starting 169.254 means no DHCP answer. A wrong gateway points at the wrong VLAN. |
| Can it reach the gateway? | ping 10.1.20.1 | Whether the local network works at all |
| Does the name resolve? | nslookup intranet.example.com | Whether DNS answers, and with which address |
| Can it reach the service? | Test-NetConnection app.example.com -Port 443 | Whether the path to the application port is open |
| Where does the path stop? | tracert 10.20.1.10 | The last hop that answers. I record it for 2nd line rather than interpret it. |
2nd line: the NOC
The NOC (network operations centre) watches monitoring, owns access and campus faults, and makes standard changes. These are Cisco IOS (Internetwork Operating System) XE commands. Other vendors have the same checks.
| Check | Command | What it tells me |
|---|---|---|
| Port state, VLAN, speed | show interfaces status | Whether the port is up, in the right VLAN, at the right speed and duplex |
| Ports shut by protection | show interfaces status err-disabled | Which ports a protection feature shut down, and why |
| Is the device seen? | show mac address-table interface Gi1/0/14 | Whether the device's MAC address is learned on the port |
| Network access control | show access-session interface Gi1/0/14 details | The 802.1X or MAB (MAC authentication bypass) result and the policy applied |
| Power for phones and APs | show power inline Gi1/0/14 | Whether PoE (power over Ethernet) is delivered, and how much |
| Errors and flaps | show interfaces Gi1/0/14 | Input errors, CRC (cyclic redundancy check) errors and drops, a sign of cabling faults |
| Recent events | show logging | include 1/0/14 | Flaps, security violations and the times they happened |
3rd line: network engineering
Engineers own routing, the core, the WAN, the data centre and the design. They also run captures and lead root cause work.
| Check | Command | What it tells me |
|---|---|---|
| Route and next hop | show ip route 10.20.1.0 | Which route is used, learned from where, through which next hop |
| BGP (Border Gateway Protocol) neighbours | show ip bgp summary | Whether BGP sessions are up and how many prefixes each sends |
| OSPF (Open Shortest Path First) neighbours | show ip ospf neighbor | Whether OSPF adjacencies are full |
| Spanning tree root | show spanning-tree root | Whether the root bridge is where the design put it |
| Control plane load | show processes cpu sorted | Which process is using the CPU (central processing unit) |
| Capture on the box | monitor capture CAP interface Gi1/0/1 both | Embedded packet capture, matched to one host, to prove what is on the wire |
Routing and switching faults are covered in depth on the routing, switching and troubleshooting pages.
4th line: carriers and vendors
Before I open a case I gather the evidence the other side will ask for, so the first reply is a diagnosis and not a request for logs.
| Check | Command | What it tells me |
|---|---|---|
| Full device state for TAC | show tech-support | redirect bootflash:tech.txt | Everything the vendor needs, in one file attached to the case |
| Circuit errors | show interfaces Gi0/0/0 | Errors, drops and resets on the carrier facing port |
| Optical light levels | show interfaces transceiver | Transmit and receive power on fibre optics, against their limits |
| Cisco severity | What it means | What Cisco expects from the customer |
|---|---|---|
| Severity 1 | Critical impact on business operations. The product is down. | Full time resources, around the clock |
| Severity 2 | Substantial impact. The product is degraded. | Full time resources during business hours |
| Severity 3 | Minimal impact. The product is partly degraded. | Resources during business hours |
| Severity 4 | No impact. Information about features, implementation or configuration. | Resources during business hours |
From Cisco's published severity and escalation guidelines. Other vendors use similar scales. I set the case severity from the business impact, never higher to get attention.
Infrastructure support
Servers, storage, cloud and the applications on them
Infrastructure support follows the same lines, but the split depends on access more than on skill. 1st line can see a service is down. 2nd line can restart it safely. 3rd line can work out why it fell over and change the design so it stops.
Who does what, by area
| Area | 1st line | 2nd line | 3rd line |
|---|---|---|---|
| Identity | Lockouts and resets after an identity check, group membership through the catalogue | Group Policy faults, sync errors between Active Directory and Entra ID | Replication, trusts, federation and conditional access design |
| Windows and Linux servers | Check the status page and monitoring. Never restart a server. | Service restarts, disk space, failed patches, event and system logs, as standard changes | Cluster faults, performance root cause, platform builds |
| Virtualisation | None. Report what users see. | Virtual machine restarts, snapshot clean up, host alarms | Cluster, vMotion, storage paths and vendor cases |
| Storage and backup | Log restore requests with the path and the date needed | Rerun failed jobs, restore files and folders | Array faults, replication, capacity and recovery tests |
| Cloud platforms | Check the provider's status page and post a status message | Respond to alerts, scale within limits, restart managed services | Landing zone, networking and identity design, provider cases |
| Business applications | Access, known errors and how to questions | Application support: configuration, batch jobs, interfaces between systems | Developers and the software vendor: defects and releases |
A restart is a fix once
Restarting a hung service brings users back, and that is the right first move. The second time it happens, it needs a problem record, because the restart is hiding a cause.
Runbooks for 2nd line
Each common alert has a runbook: how to confirm it, the safe steps, how to check it worked, and when to call 3rd line. Runbooks are reviewed after every use that went wrong.
On call that people can sustain
Out of hours, 2nd line and 3rd line share a rota with a primary and a backup, a paging tool, a clear rule for what wakes someone, and time off after a long night.
The first checks 2nd line runs
| Platform | Check | Command |
|---|---|---|
| Windows Server | Is the service running? | Get-Service -Name Spooler |
| Windows Server | Recent system errors | Get-WinEvent -LogName System -MaxEvents 50 |
| Windows Server | Free disk space | Get-Volume |
| Active Directory | Replication health | repadmin /replsummary and dcdiag /q |
| Linux | Service state and recent logs | systemctl status nginx and journalctl -u nginx --since "1 hour ago" |
| Linux | Disk and memory | df -h and free -h |
| VMware ESXi | Host CPU, memory and storage latency | esxtop |
| VMware ESXi | Can this host reach the vMotion network? | vmkping -I vmk1 10.0.17.12 |
How servers, hypervisors and clusters work is on the servers and virtualisation page, and cloud platforms are on the cloud architecture page. The vMotion address above is an example, on a VLAN set aside for vMotion as VLAN 17 is in my home lab.
Desktop support
Desktops and laptops, fixed from a distance
Most desktop faults are fixed remotely by 1st or 2nd line, with deskside engineers for hardware and new kit. Remote support is powerful and easy to abuse, so I set it up with identity checks, consent, least privilege and a record of every session.
Swipe sideways to see the whole diagram.
Every remote session starts from a ticket, so it is recorded and linked. Before I connect to anyone's device, I check who they are in the way the security policy sets out. Caller ID or a familiar voice is not enough, because attackers pose as staff to get remote access.
The analyst signs in to the remote tool with their own work identity. With Quick Assist, the helper must sign in with a Microsoft account or Entra ID, and the tool gives a time limited code, which I read out over the phone.
The user enters the code and chooses to allow screen sharing. They can see everything I do and stop the session at any moment. I start with view only and explain what I am looking at.
If I need to click, I ask for control and the user allows it. The session is encrypted and runs through the provider's relay over HTTPS (port 443), so no inbound ports are opened on the user's network.
For an admin task I never ask for the user's password, and I never type a shared admin password. I use the device's own local admin password from Windows LAPS (Local Administrator Password Solution), read under my role. LAPS can reset that password automatically after it has been used.
The ticket gets the session times, what I changed and the result, and the user confirms the fix. Quick Assist keeps almost no logs, so where audit matters I use a managed tool such as Intune Remote Help or BeyondTrust Remote Support, which keep session records.
Remote support tools
| Tool | What it is | What I watch |
|---|---|---|
| Quick Assist | Microsoft's remote help app for Windows, installed from the Microsoft Store. The helper signs in and shares a time limited code. The user allows sharing and control. | Microsoft keeps only basic session data and no logs are made on either device, so I avoid it where an audit trail is needed. |
| Intune Remote Help | Remote help built into Intune, with role based access, elevation and session records in the Intune admin centre. | Licensing and the platforms it supports have changed several times, so I check the current terms before I plan on it. |
| BeyondTrust Remote Support | A remote support platform, known as Bomgar until 2018. Cloud or appliance, with session recording and support for many platforms. | Who may connect to which devices, and how long recordings are kept. |
| TeamViewer and similar | Widely used remote access tools with unattended access. | Attackers use the same tools. I allow only the corporate version, with single sign on and an allow list, and block personal copies. |
Common desktop faults and first checks
| Fault | First checks | Command or place |
|---|---|---|
| Cannot sign in to apps | Is the device joined and healthy? Is the user's token current? | dsregcmd /status |
| Policies not applying | Which Group Policy objects applied, and which were filtered out? | gpresult /r |
| Access denied to a share | Is the user in the right group, and has their Kerberos ticket refreshed since? | whoami /groups and klist |
| BitLocker recovery screen | Identity check, then the recovery key from Entra ID, Intune or Active Directory | manage-bde -status once the device starts |
| Corrupt system files | Repair the Windows image, then the system files | DISM /Online /Cleanup-Image /RestoreHealth, then sfc /scannow |
| Device not compliant | Which compliance rule fails, and has the device checked in recently? | The device record in Intune, then a sync from the device |
Fix or replace?
For a laptop, a swap from the loan pool usually beats an hour of fixing. The user is working again in minutes, and the faulty one is rebuilt or repaired off the clock.
Rebuild, not repair
When software is badly broken, 2nd line wipes and rebuilds the laptop, for example with Autopilot reset or a fresh enrolment. User files in the cloud make this a short job.
Assets in the ticket
Every swap updates the asset record: who has which device, which went for repair, and what came back. The end user computing page covers imaging, enrolment and asset management.
Tools
The tools that turn alerts into tickets and fixes
A support model runs on a handful of linked tools: the ITSM platform, monitoring, event correlation and paging, remote support, knowledge and chat. The value is in the links between them, so that one fault becomes one ticket with the right owner, without anyone retyping it.
Swipe sideways to see the whole diagram.
Monitoring sends events, not tickets. Event rules drop the noise, merge duplicates that share a message key, and group events with one cause, such as fifty port alarms behind one failed switch. One incident is raised with its CI (configuration item) and group already set. When the clear event arrives on the same key, the alert closes.
The tool set behind a support desk
| Kind of tool | Examples | What I look for |
|---|---|---|
| ITSM platform | ServiceNow, Jira Service Management, Freshservice, TOPdesk, ManageEngine ServiceDesk Plus, BMC Helix | Incidents, requests, problems, changes and CIs in one linked record set, an SLA engine with business calendars, built in knowledge, and an API (application programming interface) |
| Monitoring | SolarWinds, PRTG, LogicMonitor, Zabbix, and each cloud's own monitor | An integration that opens and closes tickets, and dependency maps so one failure raises one alert |
| Event correlation and paging | ServiceNow Event Management, PagerDuty, or the ITSM tool's own on call features | Deduplication, correlation, on call rotas and escalation if a page is not acknowledged |
| Remote support | Intune Remote Help, BeyondTrust Remote Support, Quick Assist | Identity, consent, role based access and session records (see desktop support) |
| Knowledge | The ITSM tool's knowledge base, or a wiki such as Confluence | Search from inside the ticket, article states, feedback and review dates |
| Collaboration | Microsoft Teams or Slack, linked to the ITSM tool | Swarm channels created from a ticket, with the conversation saved back to it |
| Discovery and assets | ServiceNow Discovery, Lansweeper, Intune device inventory | An accurate CMDB, so tickets route by CI and show the impact |
How I join the tools up
- Monitoring opens and closes its own tickets. Nobody retypes an alert, and a fault that clears itself closes itself, with the record kept.
- Every alert names a CI. The CI comes from the CMDB, so the ticket routes to the right group and shows which services are hit.
- Deduplicate before ticketing. Fifty alarms from one site make one incident, not fifty.
- Every chat ends in the ticket. A fix agreed in a chat is copied into the work notes before the ticket is resolved.
- One sign on for every tool. Support staff use single sign on with MFA, and leavers lose access to every tool at once.
Tools have lifecycles too. ServiceNow ships two family releases a year, and each instance must stay on a supported release. Atlassian has set 28 March 2029 as the end of life for its Data Center products, including Jira Service Management Data Center, which then become read only. I plan tool upgrades and migrations like any other change.
Metrics and staffing
Measure what users feel, and staff for the peaks
A support model needs a few measures that show speed, quality and cost, read together. It also needs enough people at the busiest times, which is a queuing problem with a well known answer. MTTA (mean time to acknowledge), MTTR (mean time to restore) and the other service measures are defined on the support and service management page.
Swipe sideways to see the whole diagram.
Contacts arrive at random, not evenly, so even a desk with enough analysts on average builds a queue in a burst. Erlang C, the standard queuing formula for contact centres, turns arrivals, handle time and a target such as 80% answered within 20 seconds into the analysts needed. Callers who wait too long give up, and many call back later, adding to the load.
Try it: how many analysts for the busy hour?
An Erlang C model of a phone queue. Workload is in Erlangs: one Erlang is one person busy for a whole hour. Shrinkage is the share of paid time analysts are not taking contacts: breaks, training, meetings and leave. The result is indicative, because real desks also handle chats and tickets between calls.
- Workload
- 8.0 Erlangs
- Analysts taking contacts
- 12
- Analysts on the rota
- 18
- Answered in target
- 88%
- Average wait
- 17 seconds
- Occupancy
- 67%
With 12 analysts taking contacts, 88% are answered within 20 seconds. With one fewer it falls to 78%, because the last analyst does the most to cut waiting. The rota needs 18 people to cover shrinkage of 30%.
The measures I report, and how they mislead
| Measure | What it shows | Indicative target | Watch out for |
|---|---|---|---|
| First contact resolution | Fixed during the first contact, with no callback or escalation | Set from the ticket mix, and tracked as a trend | Analysts closing tickets too early to hit it |
| First level resolution | Fixed by 1st line, even if it took a callback | Rising as shift left works | Tickets held at 1st line too long |
| Average speed of answer | How long callers wait | Under a minute | Averages hide the long waits. I also look at the worst 10%. |
| Abandon rate | Callers who hang up before an answer | Under 5% | Very short abandons are often wrong numbers |
| MTTA and MTTR by priority | Mean time to acknowledge and to restore | Inside the SLA for each priority | Clock pauses that are not genuine |
| Reassignment count | How often tickets move between groups | One move or fewer on average | Groups refusing work they should accept |
| Reopen rate | Fixes that did not hold | Under 5% | Users opening a new ticket instead of reopening |
| Backlog age | How long open tickets have waited | Nothing older than a month without a reason | Tickets parked on hold for ever |
| User satisfaction | A short survey after each ticket | Rising, with comments read every week | Only unhappy or only happy users answering |
Targets are indicative starting points. Each organisation agrees its own, and the trend matters more than any single month. First contact resolution follows the definition from HDI, the support industry body that began as the Help Desk Institute.
Fixing support
When the support model is the fault
Sometimes the network is fine and the support model is broken: tickets bounce, the backlog grows, or the reports are green while users are angry. I troubleshoot it like any other fault, from symptom to evidence to cause. Choose a symptom to see where it fails, the report that proves it and what I change.
Swipe sideways to see the whole diagram.
Tickets bounce between groups. I run a report of tickets reassigned more than twice, grouped by category and the groups involved. The usual causes are unclear group boundaries, categories that route to the wrong team and thin escalation notes. The fix is written acceptance rules for each group, routing by CI, the note template, and an early swarm for cross domain faults.
The backlog keeps growing. I chart tickets created against tickets resolved each week, with the open ones in age bands. Common causes are too few people at the peaks, project work taking resolver time, and tickets left on hold with no date. I ring fence time for support work, triage the queue daily and chase every ticket on hold for its next action.
SLAs are green, but users are unhappy. This is the watermelon effect: green outside, red inside. I compare satisfaction scores and comments with SLA results, and look at the reopen rate. Usually tickets are resolved before users confirm, or clocks measure the tool, not the experience. I add user confirmation before resolving, and XLAs (experience level agreements) beside the SLAs.
The same fault keeps coming back. I count repeat incidents per CI and per category over 90 days. If the desk applies the same workaround every week, nobody owns the cause. After the third repeat I raise a problem record, as set out on the support and service management page, and the workaround becomes a known error article.
Big outages are noticed late. I measure the time from the first alert, or the first call, to a major incident being declared. Causes are alert noise that hides the real one, no service map linking devices to services, and a desk that waits for permission. I correlate alerts, map services in the CMDB, and let the desk declare a major incident itself.
Only one person can fix it. A report of tickets per resolver shows one name on every fault of a kind. That person is a single point of failure and will burn out. I pair them with others on live tickets, capture their fixes as knowledge, rotate people between lines, and make sure runbooks name a team, not a person.
The reports I read every week
| Weekly report | What it finds |
|---|---|
| Tickets reassigned more than twice | Routing and boundary problems, and thin notes |
| Open tickets by age band and group | Backlog building up before it shows in the SLA |
| On hold tickets with no update for a week | Tickets parked to stop the clock |
| Repeat incidents per CI, last 90 days | Candidates for problem records |
| Escalations by category, 1st to 2nd line | Shift left candidates: fixes the desk could do with knowledge |
| Breaches and near misses by group | Where the next breach will come from |
| Survey comments, lowest scores first | What users actually feel, in their words |
Engagement
How I set up a support model, from the first ticket review to steady state
Support work usually starts with a complaint about the desk, a new service going live, a merger or a contract renewal. I follow the same path each time: agree what good support means, read the ticket data before changing anything, design the lines and the routing, prove it with a pilot, then keep shifting work left.
Swipe sideways to see the whole diagram.
I start by agreeing what good support means for this organisation and for whom: office staff, a warehouse on shifts, executives travelling, or a plant that never stops. I record who decides and who is consulted in a RACI (responsible, accountable, consulted, informed) chart, with the services in scope.
I turn that into requirements: which channels, which hours, which languages, and how fast each priority must be answered and fixed. Security sets the identity checks before any reset or remote session. Each target has an owner who signs it off, and each supplier contract must fit inside it.
Before designing anything I read the data: a year of tickets by hour, channel, category and group, reassignments, reopens and breaches, plus call statistics and survey comments. I sit with the desk for a day and listen to calls. The data nearly always changes the design.
The design sets the lines and their assignment groups, the routing rules from category and CI, acceptance rules for each group, the escalation note, the knowledge plan, the clocks and the reports. It also names the shift left backlog: the first fixes to move to the desk and to self service.
The ITSM platform team configures the workflows, routing, calendars and integrations. Analysts train on the new knowledge and shadow the resolver groups. A pilot with one site or one department proves the routing and the clocks against real tickets before go live.
In hypercare, the period of extra support after go live, I run a short daily review of the backlog, breaches and misrouted tickets, and tune the routing and categories. Hypercare ends only when the agreed exit criteria have held for a set period, and the service owner signs operational acceptance.
Support is never finished. Each quarter I review the measures and survey comments, move the next fixes left, retire stale knowledge and catalogue items, plan the tool upgrades, and check that supplier contracts still fit the SLAs before they renew.
Functional requirements
What it must do.
- Give users one point of contact through the portal, chat, phone and walk up, with every contact recorded as a ticket.
- Route every ticket to the right group from its category and CI, with written acceptance rules for each group.
- Run SLA clocks per priority on the right calendar, with pauses only for the reasons the contract allows.
- Verify identity before any password reset, access change or remote session.
- Raise tickets from monitoring automatically, and close them when the fault clears.
- Report speed, quality and cost measures to the service owner every month.
Non functional requirements
How well it must do it, with a number wherever one can be agreed.
- Answer time
- 80% of calls answered within 20 seconds in the busy hour (typical contact centre target).
- Abandon rate
- Under 5% of calls (typical).
- Response
- P1 within 15 minutes and P2 within 30 minutes, around the clock (example targets).
- Support hours
- Set per service: business hours for most, 24 by 7 for critical ones.
- Accessibility
- Portal and chat meet WCAG (Web Content Accessibility Guidelines) 2.2 at level AA.
- Data protection
- Tickets hold personal data, so access, retention and redaction follow UK GDPR (General Data Protection Regulation).
- Auditability
- Every remote session, reset and elevation is logged against a ticket.
- Resilience
- The desk can take calls if a site or the ITSM tool is down, with a manual fallback.
Numbers are typical starting points. Each organisation agrees its own, and the example targets match the support and service management page.
Who I talk to
- Service desk analysts and team leads, who know the calls behind the numbers
- Resolver group leads, who see what arrives badly routed
- Users at each site, including shift workers and those who never call
- Suppliers, for their contracted response times and escalation contacts
- Security, for identity checks and remote access rules
How I find out
- A year of ticket data by hour, channel, category, group and priority
- Reassignment, reopen, breach and backlog age reports
- Call statistics: answer time, abandons and handle time by half hour
- A day sitting with the desk, listening to calls
- Survey comments, read in full rather than scored
Discovery tools
| Tool or source | What it tells me |
|---|---|
| ServiceNow reports and Performance Analytics | Trends in volume, routing, breaches and backlog |
| Contact centre statistics | Arrivals, answer times, abandons and handle times for staffing |
| Knowledge usage reports | Which articles are used, which are missing, which are stale |
| Monitoring event volumes | How much noise reaches the desk, and from where |
| Survey results and comments | How users feel, beyond the SLA |
| The CMDB and discovery data | Whether tickets can route by CI at all |
Whatever the line, I want every analyst to work a "cannot work" ticket the same way: scope first, then the layers from the bottom up, with a workaround before the root cause.
My approach
- Scope. Who, where and since when? One user or many? What changed: a device, a move, an update, a password?
- Known issues. Check monitoring, the status page and open major incidents before touching the device.
- Reproduce. Watch the fault happen, on a remote session or in person, and record the exact error.
- Layers. Work from the cable up to the application, recording each test and its result.
- Workaround. Get the user working first: Wi-Fi instead of wired, a loan laptop, a web version of the app.
- Fix and record. Fix it, or escalate with a full note, and leave knowledge behind for the next one.
Faults I see most
- Expired passwords cached on phones and mapped drives
- Ports shut down by port security
- Devices out of compliance after a missed update
- DNS answers pointing at an old address
- Expired certificates on internal services
- Full disks on servers and laptops
Layer by layer
| Layer | What I check |
|---|---|
| 1 · Physical | Cable, dock, power, Wi-Fi radio switched off, damaged ports and cables. |
| 2 · Data link | Port state, VLAN, 802.1X result, Wi-Fi association and roaming. |
| 3 · Network | IP (Internet Protocol) address, gateway and DHCP, with ipconfig /all and a ping to the gateway. |
| 4 · Transport | Firewall and proxy rules, with Test-NetConnection to the service port. |
| 5 to 7 · Application | Sign in, licence, permissions, the application's own status and logs. |
My general method, with worked faults, is on the troubleshooting page.
A support model needs its own support model: who runs it, who watches the numbers, and how it improves.
Service model
The lines, groups and owners on one page, with escalation contacts for every supplier, kept current and linked from the ITSM tool.
Rotas and on call
Desk rotas built from the arrival pattern, and on call rotas for 2nd and 3rd line with a primary, a backup and rest rules.
Knowledge
Articles written during fixes, reviewed on a schedule, with feedback from every reuse.
Reporting
A monthly service report with speed, quality, cost and user comments, and a weekly operational review of the backlog and breaches.
Suppliers
Service reviews with real data, escalation contacts tested, and contracts that fit inside the SLAs.
Coaching
Weekly review of a sample of escalations and calls, fed into training and knowledge.
Support models drift as services, staff and tools change. I plan the upkeep from the start.
- Shift left. Each quarter, the most common escalations become knowledge or automation, and the effect is measured.
- Catalogue. Request items are added for new services and retired for old ones, so users find only what exists.
- Knowledge. Articles past their review date are checked, updated or archived.
- Tools. ITSM and monitoring upgrades are planned like any change. ServiceNow ships two family releases a year, and Atlassian ends its Data Center products on 28 March 2029.
- Skills. Analysts rotate into resolver groups and engineers spend time on the desk, so both understand each other's work.
- Contracts. Supplier contracts and SLAs are checked against the service before every renewal.
Projects
Related work behind this page
These are the projects closest to this topic, and they show the skills this page draws on. They cover leading engineers alongside day to day support, cutting support and operations costs, and running managed infrastructure for many customers. They also cover governing change with several vendors, and keeping a way in when things break.
Leading engineers alongside day to day work Related
Directed architecture and delivery across AWS (Amazon Web Services), Google Cloud, Azure, disaster recovery, Catalyst SD-WAN (software defined WAN), SD-Access and security, and led and mentored a team of 4 engineers alongside BAU (business as usual) work.
Support and operations after a merger Related
Post merger infrastructure integration across a multi site estate, including distribution centres. Rationalising infrastructure, support and technology overheads saved £700k a month across support and operations.
Managed infrastructure for 300 customer sites Related
A Tier 3 data centre (a resilience rating, not a support line) and managed infrastructure for over 300 customer sites on Cisco ACI (Application Centric Infrastructure) and Nexus. Provider IP space and AS (autonomous system) numbers were managed through RIPE NCC, the regional internet registry for Europe.
Change governance with four vendors Related
Worked with a blended team of 5 engineers and 4 vendors on the EMEA (Europe, the Middle East and Africa) network refresh, advising on change governance and architecture standards. The estate stayed compliant with MiFID II (the Markets in Financial Instruments Directive) throughout, with no service outages.
Systems engineer across the group Related
LAN, WAN, VoIP, virtualisation and security across the group, including warehouse, cold chain and temperature monitoring systems at the food depots, linked to the group ERP (enterprise resource planning) system.
A way in when the network is down Related
From my home network I reach a terminal server, then a console session on any router or switch, even when routing is broken. iLO ports give remote consoles on the HP servers, and Windows Server runs Active Directory, DNS, DHCP and TACACS (Terminal Access Controller Access Control System) for device logins. See the topology.
Backed by ITIL (IT Infrastructure Library) v3 and v4, and ServiceNow, which is in my core skills. See all credentials
Explore
More areas I design and deliver
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.