Incident Ticket Documentation Standards

LeanTech IT Solutions — Standard Operating Procedure

Document ID: SOP-7010

Effective Date: February 3, 2020

Last Reviewed: August 14, 2025

Classification: Internal — Tier 1 Support Staff

1. Purpose

This document defines the required standards for documenting incident tickets in the LeanTech IT Solutions ticketing system. Accurate and complete documentation is essential for tracking, auditing, quality assurance, and knowledge sharing.

2. Ticket Creation

A new incident ticket must be created for every client interaction, including:

  • Phone calls

  • Microsoft Teams messages or calls

  • Email inquiries

  • Walk-in requests (if applicable)

Start Live Incident Notes at first contact and update them with timestamps throughout investigation, resolution, or escalation.

Do not combine multiple unrelated issues into a single ticket. Each distinct issue requires its own ticket.

3. Required Ticket Fields

Every incident ticket must contain the following information:

3.1 Header Information

Field

Description

Example

Ticket ID

Auto-generated by the system

INC-2026-04-00142

Date/Time Created

Timestamp of ticket creation

2026-04-18 09:32 PHT

Client Name

Name of the person who reported the issue

Juan Dela Cruz

Company

Client company name

LeanTech IT Solutions

Company Code

Internal company code

leantech

Contact Method

How the client reached out

MS Teams / Phone / Email

Assigned Engineer

Your name and employee ID

Timothy Stephen Liu-Zhao (LT-T1-001)

3.2 Issue Details

Field

Description

Issue Summary

One-line summary of the reported problem

Issue Description

Detailed description of the issue as reported by the client, including any error messages or codes

Live Incident Notes

Time-stamped notes captured from first client contact through resolution or escalation

Severity

Low / Medium / High / Critical (refer to KB-601 for error code severity)

Affected System

Server hostname, service name, or application affected

Impact Scope

Number of users/companies affected

3.3 Resolution Details

4. Documentation Best Practices

Do:

  • Write in clear, concise, professional language

  • Include specific commands run and their outputs (redact sensitive data)

  • Document timestamps for key actions

  • Note any client preferences or special instructions

  • Record the client’s confirmation that the issue is resolved

Don’t:

  • Use abbreviations or jargon that other engineers may not understand

  • Leave any required field blank — enter “N/A” if a field is genuinely not applicable

  • Copy-paste generic notes — each ticket should reflect the specific incident

  • Include personal opinions about the client’s behavior or demeanor

  • Record client passwords or other sensitive credentials in ticket notes

5. Ticket Lifecycle

[New] → [Assigned] → [In Progress] → [Resolved] → [Closed]
                           ↓
                     [Escalated to T2/T3]
                           ↓
                  [Returned to T1 / Resolved by T2/T3]
                           ↓
                        [Closed]

  • Open → In Progress: When you begin actively working on the issue

  • In Progress → Resolved: When the technical fix has been applied and verified

  • Resolved → Closed: After the client confirms the issue is resolved (or after 48 hours with no client response)

  • In Progress → Escalated: Only when escalation criteria per KB-155 are met

5.1 Live Incident Notes and EIR Flow

  1. Start of call: Open the ticket and begin Live Incident Notes.

  2. If the incident remains Tier 1: Complete documentation in the ticket; no separate EIR is required.

  3. If the incident is escalated to Tier 2/Tier 3: Convert Live Incident Notes into an Escalated Incident Review (EIR) and submit it through your team’s current process.

5.2 EIR Required Format

All EIR submissions must follow the page sequence and section naming in KB-612 EIR Template.

  • Page 1 - Incident Overview: call reference and title, priority, date, authors, status, stakeholders, summary, impact, decisions, root and cause trigger, resolution, and supporting information.

  • Page 2 - Lessons Learned: performance factors, scored assessment areas, additional information, and action items.

  • Page 3+ - Appendix: detailed timestamped timeline and supporting evidence list.

6. Quality Assurance

Tickets are subject to random QA review. The QA team evaluates tickets on:

Criteria

Weight

Completeness (all required fields populated)

30%

Accuracy (root cause correctly identified)

25%

Resolution quality (proper fix applied)

25%

Documentation clarity (readable by another engineer)

10%

Timeliness (within SLA targets)

10%

A QA score below 70% on any reviewed ticket will be flagged for coaching with your Team Leader.