1 Escalation Types & Escalating to Engineering
There are several forms of escalation. Functional escalation moves the issue to a more specialised technical team (Help Desk → Network Team). Hierarchical escalation raises management attention because of business importance (Support Engineer → Support Manager → Director). Vendor escalation sends the issue to a technology supplier (Company → Microsoft Support, or Company → Cisco TAC).
Engineering teams expect a specific quality of technical information: problem statement, environment, version, reproduction steps, expected vs. actual behaviour, logs, timestamps, correlation IDs, troubleshooting performed, workaround, business impact, frequency, first occurrence, and recent changes. Avoid escalating simply because "I don't know what to do" — escalation should be evidence-based, e.g.:
Title: Authentication server crashes when processing malformed SAML response
Environment: Authentication Server 8.x, Linux, Production and UAT reproduced
Steps:
1. Submit SAML response containing malformed assertion.
2. Application processes response.
3. Authentication process terminates.
Expected: Invalid assertion should be rejected.
Actual: Authentication process crashes.
Logs: Exception reproduced at 13:42 UTC. Attached server logs.
Business Impact: Potential authentication service disruption.
Workaround: None identified.
Reproduction Rate: 5/5 attempts.2 Major Incidents, Parent/Child & Duplicate Tickets
Major incidents require more discipline than a routine ticket. A major incident record may track an incident commander, technical lead, communications lead, business impact, affected regions and applications, start time, incident timeline, bridge details, current hypothesis, workaround, recovery status, executive communication, and an RCA reference (Module 17, Lesson 3 covers running the actual bridge call).
During a major outage, multiple related tickets are usually linked to one parent:
Major Incident: MI000582 - Authentication platform unavailable
Related tickets:
INC0012341 - VPN login unavailable
INC0012342 - Citrix login unavailable
INC0012343 - Email SSO unavailableDuring real outages, hundreds of duplicate tickets can arrive for the same symptom ("Email unavailable") — rather than investigating each separately, they get linked to the master incident (Parent: MI000582, Duplicates: INC0012341, INC0012342, INC0012343...), which keeps the investigation from fragmenting across dozens of nearly-identical tickets.
3 Security, Vulnerability & Change Tickets
Security tickets carry their own fields — alert source, detection rule, severity, affected user, affected endpoint, source/destination IP, timestamp, MITRE ATT&CK technique, evidence, containment action, investigation status:
Alert: Impossible travel authentication
User: jsmith
First Login: London
Second Login: Singapore
Time Difference: 11 minutes
Investigation: User confirmed second authentication was not legitimate.
Action: Account disabled and sessions revoked.Vulnerability tickets track CVE, CVSS score, affected asset, software version, exploit availability, internet exposure, business criticality, patch availability, and remediation deadline — priority should never rely on CVSS alone; a high-CVSS vulnerability on an isolated test server can be far less urgent than an actively exploited one on an internet-facing production system.
Change tickets document the change description, reason, risk, impact, implementation steps, validation steps, rollback plan, maintenance window, and approvals. If a change fails, document that honestly rather than hiding it — "Change attempted at 22:05 UTC. Step 4 failed with database migration error. Rollback initiated at 22:18 UTC. Previous version restored at 22:31 UTC. Service validated successfully at 22:40 UTC." Accurate records protect both the organisation and the engineer who made the change.
4 Ticket Handover & Closure
Global companies often use follow-the-sun support (APAC → EMEA → Americas → APAC), so a P1 ticket may change owners several times in a single day. Before handing over, summarise the current state — the receiving engineer shouldn't have to reconstruct the whole incident from 100 comments. A handover should answer: where are we now, how did we get here, and what must happen next.
STATUS: P1 incident remains open.
IMPACT: Approximately 15,000 users unable to authenticate.
CURRENT FINDINGS:
Authentication requests reach application.
Database calls experiencing >20 second latency.
ACTIONS COMPLETED:
- Restarted node 1
- Restarted node 2
- Database team engaged
- Logs collected
CURRENT HYPOTHESIS: Database performance issue.
NEXT ACTION: Database team reviewing slow queries.
CONTACTS:
Incident Manager: Jane Smith
Database Engineer: Alex Jones
NEXT CUSTOMER UPDATE: 16:00 UTC.Closure is the same discipline in reverse — a ticket should never simply say "Fixed." Closure notes should explain what happened, in enough detail that reopening it later is unnecessary:
Root Cause: Intermediate certificate expired.
Resolution: New intermediate certificate installed on authentication servers.
Validation: Successful authentication confirmed for test account and
three affected production users.
Customer Confirmation: Customer confirmed service restored at 14:32 UTC.
Preventive Action: Certificate monitoring alert to be configured under
PRB001234.Resolution codes (Configuration Change, Software Defect, Hardware Failure, User Error, Duplicate, Known Issue, Third-Party Issue, No Fault Found, Unable to Reproduce, and similar) should be picked accurately, not just quickly — management uses this classification to answer questions like what causes the most incidents, which teams are overloaded, and what percentage of incidents trace back to changes. Bad classification data leads directly to bad business decisions.
5 Support Metrics & Backlog Health
Common support metrics include First Response Time, Mean Time to Acknowledge, Mean Time to Resolve/Repair (MTTR), First Contact Resolution, Ticket Reopen Rate, SLA Compliance, Backlog Size, Customer Satisfaction, and Escalation Rate. MTTR is a simple average: three tickets resolved in 2, 4, and 6 hours give an MTTR of 4 hours.
A backlog is unresolved work sitting in the queue — and a large one can quietly bury an important ticket under hundreds of low-priority ones, which is why teams run regular backlog reviews, ticket hygiene reviews, and aged ticket reviews. An aged ticket (open 147 days, say) usually means one of: waiting on a software fix, the customer stopped responding, an engineering backlog, an incorrect status, a genuinely long-term change, or the ticket was simply forgotten — each needs a different next action, so aged tickets deserve real review rather than a blanket bulk-close.
A high reopen rate is a signal worth taking seriously: if support closes a ticket with "Restarted server" and the problem returns three days later, that's evidence only the symptom was treated, not the cause — exactly the workaround-vs-fix distinction from Lesson 4.
6 Automation, ChatOps, MSPs & Ticket Etiquette
Modern platforms automate routine work: auto-assigning tickets by service, auto-raising priority when monitoring detects an outage, auto-notifying managers on SLA risk, auto-creating tickets from alerts (Prometheus → Alertmanager → ServiceNow, or Microsoft Sentinel → automation → ServiceNow ticket), auto-linking duplicates, and auto-closing stale resolved tickets. Ticketing systems also expose APIs so infrastructure and security tooling can create tickets directly — a monitoring system might POST /api/incidents with a JSON body containing title, priority, service and source.
Many organisations run incidents partly in chat tools (Teams, Slack) alongside PagerDuty or Opsgenie for paging — but the ticket, not the chat channel, remains the official record. Important decisions made in chat need to be copied back into the ticket, or they effectively never happened as far as the organisation's audit trail is concerned.
MSPs add one more risk: a support engineer might simultaneously manage tickets for Customer A, B, C, D and E, and mixing information between customer tickets can become a serious data breach — always confirm you're in the right customer's ticket before pasting anything in. Finally, basic etiquette matters more than it sounds: avoid blaming other teams or customers, avoid emotional or sarcastic comments, never write assumptions as facts, never copy secrets into a ticket, and never close a ticket without explanation. Remember tickets may later be read by managers, customers, auditors, lawyers, regulators, security investigators, or engineering teams — write accordingly, and if something was recorded wrong, correct it transparently ("Correction: previous update stated the restart occurred at 14:20 UTC. The correct restart time was 14:12 UTC.") rather than silently editing history.