This chapter covers documentation and ticketing systems, which are essential for IT support operations and a key topic in the 220-1102 exam under Objective 4.1 (Operational Procedures). Proper documentation and ticketing ensure accountability, traceability, and efficient issue resolution. Expect approximately 5-10% of exam questions to touch on ticketing workflows, documentation types, and best practices. Mastering this material will help you manage support processes effectively and pass the exam.
Jump to a section
Think of a ticketing system like a hospital emergency room (ER). When a patient arrives, the triage nurse assesses the severity of their condition (symptom description, impact). The nurse assigns a priority level: immediate (critical), urgent, semi-urgent, or non-urgent. This is like a ticket's priority field. The nurse then registers the patient, creating a record with their name, symptoms, time of arrival, and assigned doctor. This is like creating a ticket with an ID, description, timestamp, and assignee. The patient is placed in a queue (waiting room) and is moved to a treatment room when a doctor becomes available. The doctor updates the patient's chart with diagnosis, treatment, and status changes (e.g., 'in progress', 'discharged'). Similarly, a technician updates the ticket with notes, status changes, and resolution details. If the patient needs a specialist, the doctor consults them, analogous to escalating a ticket to a higher-level support group. Finally, when the patient is discharged, the record is closed, but the hospital retains it for follow-up (like a closed ticket for historical reference). The ER's tracking board shows all active patients, their status, and wait times, just like a dashboard in a ticketing system shows open tickets, SLAs, and response times.
What is Documentation and Ticketing?
Documentation refers to the creation and maintenance of records that describe IT systems, processes, and incidents. Ticketing systems are software platforms used to track, manage, and resolve support requests (incidents, service requests, changes). Together, they form the backbone of IT service management (ITSM) based on frameworks like ITIL (Information Technology Infrastructure Library).
Why It Matters
Without documentation and ticketing, support teams would lose track of issues, duplicate work, and fail to meet service-level agreements (SLAs). Proper documentation enables knowledge transfer, root cause analysis, and compliance. Ticketing systems provide a single source of truth for all support activities, ensuring nothing falls through the cracks.
Types of Documentation
Network diagrams: Physical and logical diagrams showing connections, IP addresses, device names, and locations. Use tools like Microsoft Visio, draw.io, or Lucidchart. Keep them updated; outdated diagrams cause troubleshooting errors.
Knowledge base (KB) articles: Self-help guides, known error workarounds, and procedures. Example: 'How to reset a password in Active Directory'. Use a wiki or integrated KB in the ticketing system.
Standard operating procedures (SOPs): Step-by-step instructions for common tasks (e.g., provisioning a new user). SOPs ensure consistency and reduce errors.
Asset inventory: List of all hardware and software assets with serial numbers, purchase dates, warranty status, and location. Often managed in a CMDB (Configuration Management Database) or integrated with the ticketing system.
Change management records: Documentation of planned changes, approvals, rollback plans, and post-implementation reviews.
Incident reports: Detailed records of major incidents, including timeline, impact, root cause, and resolution.
Ticketing System Components
- Ticket fields: - Ticket ID: Unique identifier (e.g., INC0012345). - Subject/Summary: Brief description (e.g., 'Unable to access email'). - Description: Detailed information, including steps to reproduce. - Priority: Based on urgency and impact (e.g., Low, Medium, High, Critical). - Status: Open, In Progress, Resolved, Closed, etc. - Assignee: Technician or group responsible. - Category: Type of issue (e.g., Hardware, Software, Network). - SLA: Service-level agreement targets (e.g., respond within 1 hour, resolve within 4 hours). - Creation date/Time. - Last updated. - Resolution notes: What was done to fix the issue. - Workflow: States and transitions (e.g., Open -> Assigned -> In Progress -> Resolved -> Closed). Automated actions like email notifications when status changes. - Escalation: - Functional escalation: Transferring to a higher-level support group (e.g., from Level 1 to Level 2). - Hierarchical escalation: Notifying management when SLA is at risk. - Automation: Rules that auto-assign tickets, send reminders, or close tickets after inactivity.
Ticketing Workflow (Step-by-Step)
Ticket Creation: User submits a request via email, web portal, phone, or chat. The system generates a ticket with a unique ID and timestamp.
Categorization and Prioritization: The system or technician assigns category and priority based on impact (number of users affected) and urgency (how quickly it needs resolution).
Assignment: The ticket is assigned to a technician or group. Automatic assignment can be based on round-robin, skill set, or load balancing.
Investigation and Diagnosis: Technician reviews the description, checks knowledge base, and gathers additional information. They update the ticket with findings.
Resolution and Recovery: Technician implements the fix (e.g., password reset, reboot server). They document the resolution steps in the ticket.
Ticket Closure: The ticket is marked Resolved. The user is notified and asked to confirm. If no response within a set period (e.g., 3 days), the ticket auto-closes.
Post-Closure Review: Optionally, a post-mortem is conducted for major incidents. The ticket is archived for future reference.
Best Practices
Keep documentation current: Update network diagrams after any change. Outdated docs are worse than none.
Use standardized templates: For tickets, KB articles, and change requests. This ensures completeness.
Enforce mandatory fields: Priority, category, description, and affected user should be required before submission.
Implement SLAs: Define response and resolution times for each priority. Monitor compliance.
Regularly review tickets: Identify recurring issues to create KB articles or initiate changes.
Integrate with other systems: CMDB, monitoring tools, and communication platforms (Slack, Teams) to automate updates.
Common Ticketing Systems
ServiceNow: Enterprise ITSM platform with ITIL-aligned modules.
Jira Service Management: Popular in agile environments, integrates with Jira Software.
Zendesk: Cloud-based, user-friendly for customer support.
Freshservice: Modern ITSM with AI capabilities.
osTicket: Open-source, free ticketing system.
Spiceworks: Free with ad-supported model, includes inventory.
Security Considerations
Access control: Role-based access (e.g., technician vs. manager vs. user). Users should only see their own tickets.
Audit logs: Track who changed what and when. Essential for compliance (e.g., GDPR, HIPAA).
Data encryption: Encrypt sensitive data in transit (TLS) and at rest.
Backup: Regularly backup the ticketing database.
Exam Relevance (220-1102)
The exam tests your understanding of:
The purpose and benefits of documentation and ticketing.
Common documentation types (network diagrams, KB, SOPs).
Ticketing workflow steps (ticket creation, escalation, closure).
Best practices for documentation and ticketing.
How documentation supports change management and incident management.
You will not be asked to configure a specific ticketing system but will need to identify correct procedures and recognize common mistakes.
User Submits a Ticket
The user contacts the service desk via phone, email, web portal, or self-service kiosk. They describe the issue or request. The system automatically creates a ticket with a unique ID and timestamp. Mandatory fields like 'Description' and 'Category' ensure completeness. The ticket is initially in 'New' status. An email notification is sent to the user confirming receipt.
Categorization and Prioritization
The technician or automated rules assign a category (e.g., Software, Hardware, Network) and priority (e.g., Low, Medium, High, Critical). Priority is based on impact (number of users affected) and urgency (deadline). For example, a server outage affecting all users is Critical; a single user's printer issue is Low. This step determines SLA targets and escalation paths.
Assignment to Technician
The ticket is assigned to the appropriate support group or individual. Automatic assignment can be round-robin, based on skill set, or load balancing. The technician receives a notification. If not assigned manually, the ticket remains in 'Open' state until a technician picks it up. Unassigned tickets may breach SLA if not attended promptly.
Investigation and Diagnosis
The technician reviews the ticket details, checks the knowledge base for known issues, and gathers additional information from the user if needed. They may reproduce the problem or use monitoring tools. All findings are documented in the ticket notes. The status changes to 'In Progress'. This step may involve escalating to Level 2 support if the issue is complex.
Resolution and Closure
The technician implements the fix (e.g., reset password, reboot server, install patch). They update the ticket with resolution steps and change status to 'Resolved'. The user is notified to confirm the fix. If the user does not respond within a set period (e.g., 3 days), the ticket auto-closes. The ticket is archived for historical reference and possible use in knowledge base articles.
In a large enterprise with thousands of employees, a ticketing system like ServiceNow is used to manage IT support. For example, a user reports 'Unable to connect to VPN'. The ticket is created with priority 'High' because remote work is critical. The system automatically assigns it to the Network Security team based on category. The technician checks the VPN logs, finds an expired certificate, and renews it. The ticket is updated with the resolution and closed. The knowledge base is updated with a new article on certificate renewal to prevent future tickets.
Another scenario: A company uses Jira Service Management for internal IT and development teams. A developer submits a request for a new server. The ticket is categorized as 'Service Request' with priority 'Medium'. It goes through an approval workflow: first, the project manager approves, then the infrastructure team provisions the server. The ticket tracks each step, with comments and attachments. Once the server is ready, the ticket is closed. This ensures audit trail and accountability.
Common issues: Technicians forget to update tickets, leading to duplicate work. To mitigate, enforce mandatory status updates before closing. Another problem: users submit tickets via email without proper details, causing delays. A well-designed portal with required fields and validation reduces this. Also, SLAs can be missed if priority is not set correctly; automated prioritization based on keywords can help. For example, 'server down' triggers Critical priority. Performance: A large enterprise may process hundreds of tickets daily. The system must handle concurrent updates without locking. Cloud-based solutions like Zendesk scale well. On-premise systems like osTicket require proper database tuning. Misconfiguration: If ticket auto-assignment is not set correctly, tickets may remain unassigned, causing SLA breaches. Regular reports on ticket aging help identify such issues.
The 220-1102 exam tests Operational Procedures (Objective 4.1) with a focus on documentation and ticketing systems. You need to know: - Purpose: Why document? To ensure consistency, enable knowledge transfer, and support compliance. - Types: Network diagrams, KB articles, SOPs, asset inventory, change records. - Ticketing workflow: Creation, categorization, assignment, investigation, resolution, closure. - Best practices: Keep docs updated, use templates, enforce mandatory fields, implement SLAs. - Common mistakes: Not updating documentation, ignoring priority, failing to escalate.
Common wrong answers: 1. 'Documentation is optional for small teams.' Reality: Documentation is essential regardless of team size; it prevents knowledge silos. 2. 'Ticketing is only for incident reporting.' Reality: Ticketing handles service requests, changes, and problems too. 3. 'Priority should be set by the user.' Reality: Priority is determined by the service desk based on impact and urgency, not by user's personal urgency. 4. 'Closed tickets can be deleted.' Reality: Closed tickets are archived for historical reference and analysis; deletion loses audit trails.
Specific numbers/values:
SLA response times: often 1 hour for Critical, 4 hours for High, 8 hours for Medium, 24 hours for Low (varies by organization).
Auto-closure timeout: typically 3 days after resolution.
Escalation thresholds: if ticket is not updated within 2 hours for Critical, it escalates to manager.
Edge cases:
What if a ticket is reopened after closure? The system should allow reopening with a new status, and the old resolution notes remain.
What if the user is the CEO? Priority may be higher due to impact, but still follow the same process.
What if multiple users report the same issue? Create a problem ticket linked to multiple incident tickets.
Eliminating wrong answers: Understand the mechanism: documentation supports the entire ITSM lifecycle; ticketing ensures traceability. If an answer suggests skipping documentation or ignoring ticketing, it's wrong. Look for keywords like 'mandatory fields', 'SLA', 'escalation', 'knowledge base' in correct answers.
Documentation includes network diagrams, knowledge base articles, SOPs, and asset inventory.
Ticketing systems track incidents, service requests, problems, and changes.
A ticket workflow: creation -> categorization -> assignment -> investigation -> resolution -> closure.
Priority is based on impact and urgency, not user's personal urgency.
SLAs define response and resolution time targets per priority.
Closed tickets are archived, not deleted, for historical reference.
Documentation must be kept updated; outdated docs are worse than none.
Escalation can be functional (to higher-level support) or hierarchical (to management).
Common ticketing systems: ServiceNow, Jira Service Management, Zendesk, osTicket.
Best practices: mandatory fields, standardized templates, regular reviews, integration with CMDB.
These come up on the exam all the time. Here's how to tell them apart.
Ticketing System
Centralized tracking of all support requests.
Automatic assignment and escalation based on rules.
SLA monitoring and reporting.
Knowledge base integration for self-service.
Audit trail for compliance.
No Ticketing System
Requests lost in email or verbal conversations.
No accountability; tasks may be forgotten.
No metrics to measure performance.
Duplication of effort; no history of past fixes.
No way to prove compliance during audits.
Mistake
Documentation is only needed for large enterprises.
Correct
Documentation is critical for teams of any size. It prevents knowledge loss when employees leave, ensures consistency, and aids troubleshooting. Even a small team benefits from basic network diagrams and SOPs.
Mistake
Ticketing systems are just for tracking bugs.
Correct
Ticketing systems handle incidents (unplanned interruptions), service requests (standard changes), problems (root cause analysis), and changes (planned modifications). They are not limited to bug tracking.
Mistake
Priority should be set by the user submitting the ticket.
Correct
Priority is determined by the service desk based on impact (number of users affected) and urgency (business need). Users often inflate priority; the technician must assess objectively.
Mistake
Once a ticket is closed, it can be deleted.
Correct
Closed tickets are archived for historical reference, trend analysis, and compliance. Deleting them would lose audit trails and impede future problem management.
Mistake
Updating documentation is a one-time effort.
Correct
Documentation must be continuously updated to reflect changes in the environment. Outdated documentation can cause more harm than none, leading to incorrect troubleshooting steps.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An incident is an unplanned interruption or reduction in quality of an IT service (e.g., server down, can't print). A service request is a pre-defined request for a standard service (e.g., password reset, new user account). Both are tracked in a ticketing system but follow different workflows. Incidents prioritize restoration of service; service requests follow approval processes if needed.
Documentation should be updated whenever a change is made to the environment. For example, after adding a new server, update the network diagram and asset inventory. For knowledge base articles, review them quarterly to ensure accuracy. Outdated documentation can lead to incorrect troubleshooting and wasted time.
A knowledge base contains self-help articles, known error workarounds, and procedures. It empowers users to resolve common issues without contacting support, reducing ticket volume. For technicians, it provides quick solutions and ensures consistent responses. It also preserves organizational knowledge.
SLA stands for Service-Level Agreement. It defines the expected response and resolution times for different priority levels. For example, a Critical incident may require a response within 1 hour and resolution within 4 hours. SLAs set expectations, help prioritize work, and measure service desk performance. Breaching SLAs can result in penalties or loss of trust.
Functional escalation transfers the ticket to a higher-level support group with more expertise (e.g., from Level 1 to Level 2). Hierarchical escalation notifies management when SLA is at risk or when the issue requires authority approval (e.g., a change request). Both are important for timely resolution and accountability.
Yes, if the user reports that the issue is not resolved or has recurred, the ticket can be reopened. The system should allow reopening with a new status (e.g., 'Reopened') and preserve the original resolution notes. The technician then investigates again. This ensures continuity and prevents duplicate tickets.
A good ticket description includes: what is not working, when it started, who is affected, any error messages, steps to reproduce, and what has been tried already. This helps the technician diagnose quickly. Avoid vague statements like 'it doesn't work'. Use specific details: 'I get error 0x80070002 when trying to open Outlook'.
You've just covered Documentation and Ticketing Systems — now see how well it sticks with free 220-1102 practice questions. Full explanations included, no account needed.
Done with this chapter?