Skip to content

Lessons Learned

Overview

Building and operating this Service Desk lab provided practical experience with both technical troubleshooting and the processes that support effective IT Service Desk operations.

The project demonstrated that effective IT Support is not simply about finding a technical fix. A successful support process combines investigation, communication, documentation, verification, and appropriate ownership.

1. Troubleshooting Should Be Systematic

One of the main lessons from the project was the importance of following a structured troubleshooting process.

Instead of immediately applying a commonly suggested fix, the investigation should begin by understanding the symptoms and then testing possible causes.

A useful approach is:

Identify → Reproduce → Test → Diagnose → Resolve → Verify

This reduces unnecessary changes and makes troubleshooting more predictable.

2. User Reports Are Starting Points, Not Diagnoses

A user report describes what the user is experiencing, but it does not necessarily identify the underlying cause.

The Internet access ticket demonstrated this particularly well.

The diagnostic tests showed:

  • The workstation had a valid IP configuration.
  • DNS resolution was working.
  • External connectivity was working.
  • No packet loss was observed during the final connectivity test.

The appropriate response was therefore not to change the DNS configuration without evidence.

This reinforced the importance of distinguishing between the reported symptom and the technical findings.

3. Reproducing an Issue Provides Valuable Evidence

Whenever practical, reproducing a reported problem makes troubleshooting more reliable.

The completed scenarios provided opportunities to observe symptoms directly and compare system behavior before and after troubleshooting.

A reproducible issue allows the technician to move from assumptions toward observable evidence.

This approach can be applied broadly:

Observe → Test → Compare → Identify the difference → Take action → Verify

4. Simple Fixes Can Require Good Diagnosis

Some solutions in this project were technically simple.

For example, launching "explorer.exe" restored the Windows desktop after the black-screen condition.

However, knowing why to launch "explorer.exe" was more important than simply knowing the command.

Similarly, enabling microphone access in Windows resolved the Zoom issue, but identifying the privacy permission as the relevant control required understanding how Windows manages application access.

The lesson is that a simple resolution can still require structured diagnosis.

5. Verification Is Part of the Fix

A troubleshooting action should not automatically be considered successful simply because it completed without an error.

The original user-facing problem should be tested again.

Examples from the completed project included:

  • Confirming that the Windows desktop returned after launching "explorer.exe".
  • Repeating network diagnostics during the Internet-access investigation.
  • Testing the microphone again in Zoom after correcting permissions.
  • Confirming that Amharic text could be entered after configuring the keyboard.

Verification provides evidence that the resolution or configuration change produced the intended result.

6. Documentation Creates Continuity

An IT Support technician may not be the only person who works on a ticket.

Clear internal notes allow another technician to understand:

  • What the user reported.
  • What was tested.
  • What was discovered.
  • What actions were taken.
  • What the result was.

This makes the ticket history useful beyond the original incident and reduces the need to repeat troubleshooting unnecessarily.

7. Customer Communication Is Different From Technical Documentation

Technical notes can contain diagnostic information that would be unnecessary or confusing for an end user.

The project therefore separated:

Internal Technical Documentation

from

Customer-Facing Communication Internal notes focused on investigation, diagnostic findings, actions, and resolution.

Customer responses focused on explaining the outcome clearly and confirming what the user needed to know.

This distinction is an important part of professional Service Desk communication.

8. Knowledge Base Content Should Match the User

The Knowledge Base exercise reinforced the importance of writing documentation for its intended audience.

An end user generally does not need a detailed explanation of TCP/IP, DNS resolution, or Windows internals when a simpler graphical troubleshooting step can address the problem.

Effective self-service documentation should be:

  • Clear
  • Step-by-step
  • Safe
  • Easy to understand
  • Focused on practical actions
  • Clear about when to contact IT Support

The eight FAQs created for the project provided practical experience in organizing this type of user-focused support content.

9. Not Every Problem Requires a Configuration Change

Another important lesson was learning when not to change something.

Technicians can sometimes make a problem worse by changing settings without sufficient evidence.

The network troubleshooting case demonstrated that diagnostic results should guide the next action.

If the evidence shows that a component is functioning, the technician should investigate other possibilities rather than changing a working configuration simply because it appears related to the reported symptom.

10. Ticket Management Is Part of Technical Support

Technical troubleshooting and ticket management are closely connected.

A technician must not only address the technical issue but also manage the incident properly.

That includes:

  • Taking ownership when assignment is required.
  • Updating the ticket.
  • Recording technical findings.
  • Communicating with the user.
  • Verifying the outcome.
  • Closing the ticket appropriately.

The ticket is therefore more than an administrative record. It provides the documented history of the support process.

11. Reproducible Problems Are Valuable for Learning

Using issues that could be reproduced and tested on the workstation made the project more valuable than documenting entirely fictional troubleshooting results.

A reproducible issue allows the technician to:

  1. Observe the problem.
  2. Form a hypothesis.
  3. Perform a test.
  4. Apply a controlled change.
  5. Repeat the relevant test.
  6. Confirm the outcome.

This provides a practical way to develop troubleshooting skills in a controlled environment.

12. Building the Lab Was Also Part of the Learning

The project involved more than configuring an existing Service Desk system.

Building the environment required working with:

  • Virtual machines
  • Ubuntu Server
  • Apache
  • MariaDB
  • osTicket
  • Windows
  • Networking
  • Git
  • MkDocs
  • Material for MkDocs

This provided practical exposure to both infrastructure setup and end-user support.

It also demonstrated how different components can be combined to create a realistic IT Support environment.

Overall Reflection

The most important lesson from the project was that good IT Support combines technical knowledge with process discipline.

A technician needs to be able to:

Understand the user's problem → investigate systematically → use evidence to identify the likely cause → apply an appropriate resolution → verify the result → document the work → communicate clearly.

The project provided an opportunity to practice this complete process in a controlled environment.

It also highlighted an important professional principle: good troubleshooting is not about making the most changes; it is about making the right change based on evidence.