El problema
Casi todo el mundo aprende soporte trabajando, con usuarios reales esperando. Los laboratorios enseñan los comandos, pero no el ticket: leer lo que el usuario dice de verdad, encontrar la causa y no el síntoma, comprobar que funciona antes de cerrar y dejar una nota que le sirva al siguiente técnico. El error clásico es el arreglo que parece bueno. Desbloqueas la cuenta que se bloquea cada mañana, el usuario está contento una hora y el ticket vuelve, porque la contraseña antigua sigue guardada en el móvil. Quería un sitio para practicar ese ciclo sin una empresa real detrás.
Qué he hecho
- Una cola de tickets con prioridad, SLA (20, 30 o 45 minutos) y estado. Al asignarte un ticket empieza a correr el reloj y se abre la consola.
- Una ficha del ticket con el solicitante y su equipo, tarjetas que cambian según avanza el caso y acciones desde la ficha que hacen lo mismo que el comando, trampas incluidas.
- 18 tickets de Active Directory, DNS, Windows, impresoras, Exchange Online, Intune y BitLocker, VPN, licencias de Microsoft 365, Azure AD Connect, Veeam, MECM, Red Hat, Citrix, acceso condicional, inicio de sesión único con SAML, Linux unido a AD y SQL Server. Cada uno tiene una causa raíz, un arreglo tentador que no lo cierra y una comprobación para demostrar que funciona.
- Para cerrar un ticket hay que elegir un código de resolución y escribir una nota de trabajo. La nota se corrige por causa, cambio, verificación y seguimiento, y el resultado es Resuelto, Resuelto con observaciones o No resuelto, con lo que falta.
- Un Active Directory simulado con OU, usuarios, grupos y equipos, donde cada botón ejecuta un comando de PowerShell visible; un escritorio para los tickets que se arreglan en la máquina del usuario, con visor de eventos; y un inventario de servidores e impresoras ligado a los tickets abiertos.
- Una base de conocimiento que se crea con tus propias notas aprobadas y se descarga en Markdown, progreso con racha, objetivo semanal e insignias, y un buzón interno con peticiones reales y phishing que hay que saber distinguir.
- Un bloque «Practícalo» en 17 de las guías de esta web, que abre el ticket correspondiente en el idioma de la guía.
Cómo está hecho
Un sitio estático con JavaScript sin frameworks y una pequeña base de datos para las cuentas y los resultados. Cada ticket tiene tests automáticos, para que el arreglo tentador nunca pueda cerrarlo. Todo es ficticio: una empresa inventada y ningún sistema real. Es práctica, no experiencia laboral.
Qué aprendí
De trabajar tickets y enseñar a otros a trabajarlos: la nota de trabajo es parte del arreglo, un ticket no está cerrado hasta que el usuario confirma que funciona, y el arreglo que parece bueno es la forma más habitual de reabrirlo.
Siguientes pasos
- Contactar con el solicitante desde el ticket con preguntas guionizadas, donde algunas pistas solo salen preguntando, y corregir la nota al usuario aparte de la nota de trabajo.
- Estados de flujo (pendiente del usuario, pendiente del proveedor) con el SLA en pausa, y restablecer la contraseña de la cuenta por email.
- Una sala de red con switches, routers y cortafuegos, una CLI de switch y tickets de red; después, envíos y RMA ligados a los tickets.
¿Quieres llevarlo a tu entorno o adaptarlo a tu caso? Escríbeme y lo vemos.
The problem
Most people learn support on the job, with real users waiting. Labs teach the commands, but not the ticket: reading what the user really says, finding the cause instead of the symptom, checking that it works before closing, and leaving a note the next engineer can use. The classic mistake is the fix that looks right. You unlock the account that locks every morning, the user is happy for an hour, and the ticket comes back because the old password is still saved on the phone. I wanted a place to practise that loop without a real company behind it.
What I built
- A ticket queue with priority, SLA (20, 30 or 45 minutes) and status. Assigning a ticket starts the clock and opens the console.
- A ticket page with the requester and the device, cards that change as the scenario changes, and actions from the page that do the same as the command, traps included.
- 18 tickets across Active Directory, DNS, Windows, printers, Exchange Online, Intune and BitLocker, VPN, Microsoft 365 licences, Azure AD Connect, Veeam, MECM, Red Hat, Citrix, Conditional Access, SAML single sign-on, Linux joined to AD and SQL Server. Each one has a root cause, a tempting fix that does not close it and a check to prove it works.
- Closing a ticket asks for a resolution code and a work note. The note is marked on cause, change, verification and follow-up, and the result is Resolved, Resolved with remarks or Not resolved, with what is missing.
- A simulated Active Directory with OUs, users, groups and computers, where every button runs a visible PowerShell command; a desktop for the tickets that are fixed on the user's machine, with an event viewer; and an inventory of servers and printers linked to the open tickets.
- A knowledge base built from your own approved notes, downloadable as Markdown, progress with a streak, a weekly goal and badges, and an internal mailbox with real requests and phishing to tell apart from them.
- A "Practise it" box in 17 of the guides on this website, which opens the matching ticket in the right language.
How it is built
A static site with plain JavaScript and a small database for accounts and results. Every ticket has automated tests, so the tempting fix can never close it. Everything is fictional: a made-up company, no real systems. It is practice, not work experience.
What I learned
From working tickets and teaching others to work them: the work note is part of the fix, a ticket is not closed until the user confirms it works, and the fix that looks right is the most common way to reopen one.
Next steps
- Contact the requester from the ticket with scripted questions, where some clues only come out by asking, and mark the note to the user apart from the work note.
- Workflow states (pending user, pending vendor) with the SLA paused, and password reset by email for accounts.
- A network room with switches, routers and firewalls, a switch CLI and network tickets, then shipments and RMA linked to tickets.
Want to bring it to your environment or adapt it to your case? Get in touch and we can look at it together.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →