Week 01 · lesson
Lesson 5: Your First Service Ticket
This is where the week turns into a technician record.
A service ticket is not a worksheet stapled to a repair. It is the memory of the investigation: what the user reported, what you observed, what you believed, what you tested, what changed, and how you verified the result.
A weak ticket says, "Fixed computer."
A useful ticket lets another technician reconstruct your path without guessing.
The scenario
A desktop user reports:
"It turns on, but nothing works."
Your supplied evidence says:
- power LED turns on;
- case fans spin;
- monitor is powered;
- monitor shows No Signal;
- keyboard LEDs flash briefly at startup;
- no operating-system screen appears;
- the system recently had a graphics card removed and reinstalled.
That is enough to begin, but not enough to finish.
Translate the complaint
The user statement is too broad. "Nothing works" hides the actual boundary.
A stronger problem statement is:
System appears to receive power but produces no visible display output during startup after recent graphics-card service.
That sentence is narrower. It keeps the facts we have and removes the fog.
It also keeps the recent change in view. Recent changes matter because many failures happen near the last thing that was touched.
Separate evidence from theory
Evidence is what you can observe or verify.
Theory is your current explanation for that evidence.
Do not mix them.
| Evidence | Theory it may support |
|---|---|
| Monitor says No Signal | Display path may be broken before the monitor receives video |
| Case fans spin | Some system power is present |
| GPU was recently removed and reinstalled | GPU seating, output choice, or auxiliary power deserves attention |
| Keyboard LEDs flash briefly | Some startup activity may be occurring |
None of those facts proves the final cause by itself. Together they point to a smaller set of tests.
Build three reasonable theories
Create at least three plausible theories that fit the evidence.
Good examples:
- display cable is connected to the wrong output;
- monitor is on the wrong input;
- discrete GPU is not fully seated;
- GPU auxiliary power is disconnected;
- RAM was disturbed during service;
- firmware is producing diagnostics the user did not notice.
Bad examples:
Everything is broken.
Replace motherboard.
Computer dead.
Those are not theories. They are panic wearing a lab coat.
Choose the least invasive useful test
A good test changes as little as possible.
Reasonable order:
- verify monitor power and input;
- verify the cable is in the intended graphics output;
- try a known-good display cable or monitor if available;
- power down and inspect GPU seating and auxiliary power;
- inspect diagnostic indicators;
- continue deeper only if the evidence requires it.
Why this order?
Because checking the external display path is safer than opening the system. Reseating hardware creates risk and new variables. Start with the tests that can eliminate simple boundary problems first.
Write the ticket as a trace
Use this structure:
User report
What the user says happened.
Observed evidence
What you actually verified.
Recent changes
Anything installed, removed, updated, moved, cleaned, dropped, or reconnected.
Theory
The failure you currently think best explains the evidence.
Test
What you will do to challenge that theory.
Result
What happened after the test.
Action
What you changed, if anything.
Verification
How you proved normal functionality returned.
Prevention / follow-up
Anything the user or technician should do next.
This format is not about paperwork. It keeps the investigation honest.
Three possible outcomes
Variation A: wrong output
The display cable is connected to an inactive motherboard video output while a discrete GPU is installed.
A useful action statement:
Moved display cable from motherboard HDMI to discrete GPU DisplayPort using approved adapter. Verified firmware logo and operating-system login screen appeared on restart.
Do not write:
Fixed monitor.
The monitor was not the proven fault.
Variation B: GPU power
The GPU is seated, but its required auxiliary power connector is disconnected.
This explains why fans and case LEDs can operate while graphics output fails. The entire PC does not need to be unpowered for one subsystem to fail.
A useful note names the specific connector, the safety step before reconnecting it, and the verification after startup.
Variation C: RAM disturbed
The graphics path checks out, but a diagnostic LED or beep pattern points toward memory.
Now RAM becomes a better next test. Inspect seating with ESD-safe procedure. Do not reseat every component because you ran out of ideas. Follow the evidence.
Verification matters
A repair is not complete because the screen lights up once.
Verify enough of the original complaint to show the system is functional:
- POST completes;
- firmware or boot logo appears;
- the expected operating system loads;
- display remains stable;
- no new diagnostic indicators appear;
- the user-facing symptom no longer occurs.
Then document what changed.
Week 1 evidence package
By the end of Week 1, preserve:
- technician workspace record;
- component census;
- port/interface map;
- firmware/POST observation;
- completed service ticket.
The important separation is this:
What the user said
What you observed
What you believed
What the test proved
What you changed
How you verified it
That separation is the habit we care about.
Next week we go deeper into motherboards, processors, RAM, storage, power, and compatibility.
Read it. Prove it.