1 Ticket Ownership & Avoiding Ping-Pong
Every active ticket should have an owner. Poor ownership causes tickets to bounce — Network Team → Identity Team → Application Team → back to Network Team — a pattern sometimes called ticket ping-pong. A good engineer avoids unnecessary reassignment. Before transferring a ticket, explain why another team is required, what evidence supports the transfer, and what has already been tested. That one habit is the difference between an escalation that gets picked up immediately and one that bounces straight back with "not us."
2 Good Escalation & Tickets That Tell a Story
Compare "Authentication broken. Please investigate." against a full escalation with issue, impact, start time, findings, attached logs, an example affected user, a request ID, the relevant recent change, a suspected area, and what assistance is required. Which gets the receiving team working immediately, and why?
Reveal the answer
The full version, because it removes every question the receiving engineer would otherwise have to ask before they could start (Module 17 covers this same principle from the communication side). A good ticket should also read chronologically, like a timeline:
09:02 Customer reports authentication failure.
09:05 Engineer acknowledged issue.
09:10 Confirmed service reachable.
09:18 Authentication logs reviewed.
09:25 Found certificate validation errors.
09:32 Identity team engaged.
09:45 Expired intermediate certificate identified.
10:00 Replacement certificate approved.
10:15 Certificate replaced.
10:20 Authentication successful.
10:35 Customer confirms service restored.This becomes extremely valuable during incident reviews — the whole investigation is reconstructable from the ticket alone.
Vague notes undermine all of this. "Checked logs. Everything looks fine" tells the next reader nothing. Compare: "Reviewed authentication.log between 14:00 and 14:30 UTC. No authentication errors observed for user jsmith. Requests for correlation ID 83ad521e returned HTTP 200. Requested client-side logs to determine whether failure occurs before the authentication request reaches the server." Every sentence in the second version either rules something out or points at the next step.
3 Timestamps, Timezones & Correlation IDs
Time is essential during investigations. "User tried logging in earlier" is nearly useless; "User reproduced the login failure at approximately 2026-08-30 13:42 UTC" lets engineers correlate authentication logs, firewall logs, application logs, SIEM events, database logs, load balancer logs, and cloud audit logs against the same moment.
Global companies operate across timezones, so "the problem occurred at 3 PM" is ambiguous — it could mean 15:00 BST, CET, EST, IST, or JST. Record timestamps in UTC whenever possible; if a customer gives you local time, record both ("Customer reported: 15:42 CEST. Equivalent: 13:42 UTC").
Modern distributed systems generate identifiers like Request ID, Transaction ID, Session ID, Correlation ID, or Trace ID — e.g. 4f35b8b2-74f2-4ee5-91a1-b7e76239d8fb. These matter because a single user transaction may cross browser → load balancer → API gateway → application → authentication service → database, and the same correlation ID is often the only thing that lets an engineer trace that one transaction across every one of those systems.
4 Evidence, Sensitive Data & Personal Data
Useful evidence includes screenshots, logs, packet captures, HAR files, configuration exports, diagnostic bundles, database output, Event Viewer logs, SIEM queries, API responses, error messages, and command output. But engineers must consider data sensitivity before attaching any of it.
Never casually place secrets into a ticketing system — passwords, private keys, API secrets, bearer tokens, session cookies, database credentials, cloud access keys, encryption keys, or MFA recovery codes. Even internal ticketing systems can have thousands of users with access. Redact: instead of Authorization: Bearer eyJhbGciOi..., write Authorization: Bearer [REDACTED].
Tickets also routinely contain personal data — names, email addresses, phone numbers, IP addresses, user IDs, device information, authentication history, financial information — and organisations operating globally may need to comply with GDPR, UK GDPR, CCPA/CPRA, industry-specific privacy rules, banking regulations, or healthcare regulations. Only collect what the investigation actually needs.