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.

EvidenceTheory it may support
Monitor says No SignalDisplay path may be broken before the monitor receives video
Case fans spinSome system power is present
GPU was recently removed and reinstalledGPU seating, output choice, or auxiliary power deserves attention
Keyboard LEDs flash brieflySome 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:

  1. verify monitor power and input;
  2. verify the cable is in the intended graphics output;
  3. try a known-good display cable or monitor if available;
  4. power down and inspect GPU seating and auxiliary power;
  5. inspect diagnostic indicators;
  6. 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.

Lesson knowledge checks

Answer from the lesson you just completed. Results stay in this browser and are not submitted.
Knowledge check 1

What makes a service-ticket note useful?

Knowledge check 2

After applying a repair, what should happen before closing the ticket?