Case file 003 / Python & IT operations
From ticket exports
to useful review findings.
A Python tool that counts support tickets, highlights missing resolution notes, and groups repeated subject wording for a person to investigate.
Working local prototype. This case study uses fictional training tickets. The tool does not connect to a live service desk or execute repairs.
01 / Findings
A small, reproducible baseline.
Results from the fictional sample checked on October 27, 2026. These describe the training dataset, not workplace performance.
- Valid fictional tickets
- 38
- Missing resolution notes
- 3
- Repeated subject groups
- 4
- Automated tests passed
- 9
These downloads are dated snapshots; they do not update automatically when the local dataset changes.
02 / Brief
A closed ticket is not the whole story.
A ticket list can show that work is closed without explaining what fixed the problem. Repeated subjects can also be easy to miss when reviewing rows one at a time.
This project makes those review candidates visible while practicing Python file handling, dictionaries, loops, and functions.
03 / Method
A workflow I can inspect.
- ReadLoad a CSV with six defined columns.
- ValidateCheck fields, labels, and unique IDs; report excluded rows.
- AnalyzeCount categories and look for missing notes and matching subject wording.
- ReportWrite an Excel-readable CSV and a Markdown findings report.
Subject comparison ignores capitalization, punctuation, and extra spacing. It does not infer that two tickets share a root cause.
04 / Example
Same words.
Different review questions.
The fictional sample includes two tickets about file-share access and the Windows Workstation service. One contains a documented service restart; the other remains in progress.
The analyzer groups their subject wording, but does not copy the fix to the open ticket or assume the cause is identical. The scenario was inspired by an issue I described from IT work; public identifiers and records are fictional.
05 / Contribution & learning
Practical direction.
Transparent assistance.
I chose a support-ticket workflow relevant to my IT experience and contributed the file-share scenario. The Python implementation, tests, and initial documentation were developed with AI coding assistance.
My learning work is to trace the functions, change the fictional inputs, explain the results, and document changes I make myself. This prototype is a learning checkpoint, not a claim of independently authored production software.
06 / Validation & limits
What the checks do—and do not—establish.
Checked behavior
- Expected results for the 38-ticket sample.
- Blank required values, duplicate IDs, and unsupported labels.
- Missing columns and missing files.
- Quoted and multiline CSV content.
- Subject normalization, empty input, and report output.
- Investigation, fix, and verification notes in all 20 added scenarios.
Known limitations
- Different wording can hide related problems.
- Similar wording is not proof of a duplicate incident.
- A resolution note is not proof that a repair was verified.
- The schema is defined for this project; arbitrary exports need mapping.
- There is no AI diagnosis, live integration, or automatic remediation.
07 / Next checkpoint
Explain it.
Then extend it.
Next: complete the hands-on exercises, draw the workflow, and publish a dedicated source repository with setup instructions. Later work can compare AI suggestions against a tested baseline.
The browser-based IT Ticket Assistant is a separate project: it reviews one request and drafts a response. This Python analyzer reviews a collection of ticket records.
Back to selected work ↗