¿Qué debe decir realmente la carta de presentación de un técnico de soporte IT?

Dónde se lee esta carta y dónde no

Depende mucho del tamaño y la estructura del empleador, más que en la mayoría de las profesiones.

En un proveedor pequeño de servicios gestionados o en un equipo IT interno de unas pocas personas, quien contrata suele ser el ingeniero principal o el propio responsable de IT, y leen todas las solicitudes porque no hay muchas. En ese contexto la carta se lee de verdad, porque es la única muestra escrita que tienen de cómo sonarías en una llamada con un cliente o un usuario enfadado.

En un service desk grande —un equipo corporativo de primera línea, un call centre externalizado, un trust del NHS o una administración local que gestiona cientos de tickets al día— las solicitudes suelen pasar primero por un reclutador o un sistema de seguimiento de candidatos. Ese sistema, y el triaje humano detrás de él, está diseñado para filtrar según el CV: herramientas nombradas, años de experiencia, certificaciones. El archivo de la carta de presentación a menudo no se abre en esa fase, y algunas configuraciones de ATS ni siquiera lo procesan. Si te presentas a un puesto así, asume que el CV hace el filtrado y la carta, si se lee, llega después.

No hay forma fiable de saber en qué situación estás solo por el anuncio, pero una señal aproximada: si el anuncio nombra un sitio específico, un número específico de usuarios, o fue claramente redactado por alguien técnico en lugar de Recursos Humanos, probablemente hay una persona más cerca del proceso.

Las dos cosas que realmente tiene que responder

La mayoría de los consejos sobre cartas de presentación son lo bastante genéricos como para aplicarse a cualquier trabajo. Para soporte IT específicamente, un responsable de contratación que lee una está comprobando dos cosas, y poco más.

Si puedes hablar con alguien que no es técnico sin condescendencia ni perderlo en jerga. Este es el trabajo real, más que la resolución de problemas. Una viñeta del CV que dice "resolví más de 40 tickets diarios" no les dice nada sobre cómo manejaste la llamada. Un ejemplo breve sí: un usuario que no podía imprimir, ya estaba frustrado, y qué dijiste para pasar de "está roto" a un diagnóstico sin hacerle sentir estúpido. Eso vale más que cualquier adjetivo.

Si tu alcance técnico coincide con lo que ellos ejecutan. No "sólidas habilidades de resolución de problemas" —qué entorno, qué herramientas. Primera o segunda línea. Solo remoto o presencial con componente de hardware. Parque solo Windows o mixto con macOS. Si el anuncio nombra ServiceNow, Freshservice, Zendesk o Jira Service Management, di cuál has usado y cómo, porque esas herramientas difieren lo suficiente en cómo encolan y escalan el trabajo como para que "experiencia con sistemas de ticketing" por sí solo no diga nada a un responsable de contratación.

Si tu carta responde a ambas cosas en los dos primeros párrafos, ha cumplido su función. Todo lo demás es decoración.

Nombrar el stack, no solo reclamar competencia

Esta es la sección que la gente omite porque parece repetir el CV, pero es la parte que realmente diferencia a un candidato de otro en este campo. Compara:

"Tengo excelentes habilidades de resolución de problemas y un fuerte enfoque en el cliente."

contra

"He trabajado tickets de primera línea en ServiceNow contra un SLA de cuatro horas para incidentes P2, gestionado bloqueos de cuentas AD y restablecimientos de contraseñas, y creado imágenes y desplegado portátiles a través de Intune para un parque de 300 usuarios."

La segunda frase es verificable y específica de este trabajo. La primera sobreviviría siendo pegada en una carta de presentación para un puesto de dependiente con casi ninguna edición, que es exactamente la prueba que un responsable de contratación aplica sin pensarlo —¿pertenece este párrafo a este trabajo, o a cualquier trabajo?

Si tienes CompTIA A+ o Network+, MD-100/MD-101 de Microsoft, o un certificado ITIL Foundation, y el anuncio menciona algo de proceso ITIL, gestión de cambios o una estructura formal de SLA, dilo por su nombre. Si el anuncio no menciona ITIL, no lideres con ello —señala que estás haciendo pattern-matching de tu carta en lugar de leer su anuncio.

Dónde la carta tiene poco peso —y dónde se toma realmente la decisión

Para puestos de primera línea de alto volumen, el filtro real suele ser una llamada de cribado o un ejercicio práctico: un ticket simulado, una demostración de control remoto, a veces una prueba de velocidad de escritura o registro de tickets. La carta no predice nada de eso, y los responsables de contratación que dirigen service desks de alto volumen generalmente lo saben. Algunos no la solicitan en absoluto.

Para puestos que son explícitamente de cara al cliente —ingenieros de MSP que van a sitio, técnicos IT de educación que tratan con personal y estudiantes, puestos en organizaciones pequeñas donde eres la única persona técnica con la que la mayoría habla— la carta tiene más peso genuino, porque la escritura en sí misma es una pequeña muestra de la habilidad de comunicación que el trabajo necesita.

Vale la pena ser honesto sobre el límite en cualquier caso: una carta bien escrita no te conseguirá una entrevista si el CV no muestra las herramientas y el entorno correctos, porque en la mayoría de los procesos el CV se criba primero y la carta solo se lee una vez que ya has pasado ese filtro. Pon el esfuerzo en asegurarte de que el stack específico del anuncio —el SO, el sistema de ticketing, la escala del parque— aparece claramente en el CV antes de pulir la carta alrededor de ello.

Qué poner en ella, en orden

Mantenla en tres párrafos cortos, media página como máximo.

Primero: el puesto, dónde lo viste, y una línea sobre por qué este empleador específicamente —su flota de dispositivos, su sector, su número de sedes, algo que muestre que leíste el anuncio en lugar de hacerlo con mail-merge.

Segundo: la coincidencia técnica, nombrada con precisión, más el ejemplo único de gestionar bien a un usuario difícil o no técnico. Este párrafo hace el trabajo real descrito arriba.

Tercero: cualquier cosa procedimental que el puesto necesite —una verificación DBS si es una escuela o trust del NHS, derecho a trabajar si es relevante, disponibilidad para patrones de turnos si el service desk funciona en horario extendido, disposición a viajar entre sedes si es un puesto de MSP en campo. Esto es administrativo, no persuasivo, y va al final.

Qué no molestarse con

No replantees el CV cronológicamente —el lector tiene el CV. No abras con "Soy un trabajador responsable con excelentes habilidades de comunicación"; cada palabra de esa frase es una afirmación que el resto de la carta debería estar demostrando con específicos, no aseverando por adelantado. No expliques qué son ITIL o Active Directory —el lector ya lo sabe, y explicarlo se lee como relleno. Y no te disculpes por vacíos en tu stack; si el anuncio pide soporte de macOS y solo has trabajado Windows, di qué has trabajado y deja que el resto de la carta lleve el argumento, en lugar de llamar la atención sobre el vacío en la línea de apertura.

Qué hacer a continuación

Desglosa el anuncio antes de escribir nada: lista cada herramienta nombrada, SO, sistema de ticketing y certificación que menciona. Empareja cada una con lo que realmente has usado, y escribe el párrafo técnico desde esa lista, no desde el recuerdo de lo que sueles decir. Luego escribe el ejemplo único de una llamada o ticket difícil, en dos o tres frases, no más. Envíala como PDF si la estás enviando por correo electrónico directamente, ya que el texto plano pegado en el cuerpo de un correo pierde formato y a veces es marcado por filtros de spam como inusual. jobmarket.pro lee el anuncio para las herramientas específicas, sistemas y entorno que nombra y redacta la carta desde tu perfil existente sin inventar herramientas o certificaciones que realmente no tienes.