Buscar «la mejor empresa de soporte IT» en Google devuelve listas patrocinadas y rankings interesados. El criterio útil no es «quién está en el top 10»: es qué características debe tener el proveedor para que encaje con tu caso concreto. Elegir bien consiste en evaluar cinco cosas comprobables antes de firmar: si el equipo domina tu stack concreto (no «tecnología en general»), si existe un SLA por escrito con tiempos por severidad, si pueden enseñarte casos con métricas de antes y después, si trabajarás con personas identificables que retengan el contexto de tu infraestructura, y si el día que quieras irte podrás hacerlo sin rehenes. Todo lo demás —la web bonita, el comercial simpático, el precio agresivo— es ruido que no predice cómo responderán un sábado a las tres de la mañana.
Esta guía sirve para evaluar candidatos con criterios objetivos antes de firmar, e incluye las preguntas concretas que conviene llevar a la reunión de evaluación.
¿Qué es un soporte IT especializado de verdad?
Un soporte IT especializado es un equipo con perfiles técnicos concretos (sistemas, cloud, redes, seguridad), procesos documentados y compromisos medibles, que conoce tu infraestructura antes de que falle. La diferencia con un técnico generalista no es de tamaño sino de método: el generalista reacciona cuando algo se rompe; el especializado monitoriza, documenta y suele detectar el problema antes de que lo notes. Un ejemplo real de nuestra operación lo ilustra bien: en un mismo año atendimos a seis clientes distintos con el mismo síntoma —»el servidor no envía mis correos»— y detrás había cinco causas raíz diferentes (registros SPF mal configurados, greylisting del destinatario, adjuntos sobre el límite, envío sin cifrar por el puerto 25 y un envío masivo involuntario). Un soporte generalista habría aplicado la misma receta seis veces; diagnosticar cada causa por separado es exactamente lo que se paga cuando se contrata especialización.
Las características distintivas:
- Equipo con perfiles concretos: sysadmin Linux/Windows, cloud (AWS, Azure, GCP), redes, ciberseguridad, DevOps. No «técnicos polivalentes» en general.
- SLA por escrito con tiempo de respuesta y resolución por severidad.
- Monitorización proactiva: detectan el problema antes de que tú lo notes.
- Procesos documentados de gestión de cambios e incidentes.
- Casos reales con métricas: uptime conseguido, MTTR, ahorro de coste, no testimonios vagos.
Sin esto, lo que tienes es «alguien que arregla cuando llamas», no soporte estructural.
Ocho criterios objetivos para evaluar
1. Especialización en tu stack
¿Trabajan habitualmente con la tecnología que usas? WordPress gestionado, AWS, Kubernetes, SAP, Oracle, lo que sea. Un proveedor genérico puede acabar aprendiendo a tu costa: pagarás sus horas de formación disfrazadas de horas de soporte, y los errores de aprendizaje ocurrirán en tu producción, no en un laboratorio. Pide que te digan cuántos entornos como el tuyo operan hoy y desde cuándo.
2. SLA contractual
Tiempos de respuesta y resolución por nivel de severidad. Penalización si no se cumplen. Sin SLA escrito, no hay compromiso real: «responderemos lo antes posible» significa lo que el proveedor quiera que signifique el día que tengas la urgencia.
3. Modelo de comunicación
A quién escribes, qué canal (correo, ticket, llamada), cuál es el escalado y a partir de qué severidad se activa la guardia. Si «depende del caso», es señal mala.
4. Casos con métricas comprobables
Pide ejemplos concretos: cliente similar al tuyo, problema concreto, métrica antes y después, tiempo invertido. Si solo hay «muchos clientes satisfechos», desconfía. En nuestro análisis del sector, de 16 competidores directos solo 2 publicaban casos con detalle y 8 no mostraban ni un cliente; quien tiene resultados los enseña.
5. Equipo nominal vs bolsa anónima
¿Trabajarás con un equipo identificable que conozca tu infraestructura, o cada ticket lo coge alguien distinto? Un equipo asignado retiene contexto; una bolsa rotativa no. El contexto acumulado es precisamente lo que acorta los diagnósticos: quien conoce tu histórico no repite las mismas comprobaciones cada vez.
6. Documentación e infraestructura como código
¿Documentan lo que hacen? ¿Las configuraciones quedan reproducibles? Si toda la operación está en la cabeza del técnico que lleva tu cuenta, el día que se vaya tienes un problema.
7. Modelo de precios
Tarifa por horas, por mensualidad, por incidentes resueltos, mixto. No hay modelo «correcto», pero asegúrate de que entiendes qué pasa cuando:
- Hay un pico de incidentes en un mes (¿cobran extra?).
- No hay incidentes en un mes (¿hay mínimo de gasto?).
- Necesitas un proyecto puntual (¿se incluye o se factura aparte?).
8. Salida limpia
¿Qué pasa si decides cambiar de proveedor? Si tu infraestructura está documentada y reproducible, la salida es rápida. Si solo ellos saben cómo funciona, estás atado por dependencia, no por valor.
Red flags habituales
Las señales de alarma más fiables no están en lo que el proveedor dice, sino en lo que evita concretar. Estas son las que más veces hemos visto preceder a una mala experiencia, tanto en clientes que llegaron a nosotros desde otro proveedor como en evaluaciones en las que hemos participado. Ninguna por sí sola descalifica, pero dos o más juntas casi siempre terminan igual: en un incidente serio sin nadie competente al otro lado. Un patrón que se repite: la empresa cuyo proveedor solo sabía responder a cada problema de rendimiento «añadiendo más servidor», sin auditar nunca la causa; o la web hackeada dos veces en pocos meses porque la primera «limpieza» no corrigió el fallo de origen. Limpiar sin actualizar, ampliar sin diagnosticar y prometer sin firmar son variantes del mismo defecto de fondo: un servicio sin método.
- Precios muy por debajo del mercado. Soporte IT especializado tiene coste; un proveedor 50% más barato suele equivaler a subcontratación opaca, perfiles junior o falta de cobertura real.
- Sin SLA por escrito. «Responderemos lo antes posible» no es un compromiso.
- No comparten métricas de operación (uptime medio, MTTR, número de tickets resueltos por mes).
- Comerciales sin perfil técnico. Si no puedes hablar con alguien técnico antes de firmar, no sabrás qué estás contratando.
- Promesas universales («expertos en todo»). Nadie es experto en todo. Un proveedor honesto reconoce sus límites.
- Sin referencias contactables. Casos en la web sin nombre, sin testimonio real verificable.
- Soluciones que siempre pasan por facturar más. Si cada incidencia se resuelve «ampliando recursos» y ninguna con un diagnóstico, el proveedor está tratando síntomas.
Preguntas para hacer en la reunión de evaluación
Una reunión de evaluación bien llevada no va de escuchar la presentación del proveedor, sino de hacerle preguntas cuya respuesta no pueda improvisar. Estas diez funcionan porque obligan a concretar; apunta las respuestas y compáralas entre candidatos:
- ¿Cuántos entornos con mi mismo stack operáis hoy y desde cuándo?
- ¿Cuál es vuestro tiempo de respuesta y de resolución por severidad, por contrato?
- ¿Qué pasa si incumplís el SLA? ¿Hay penalización?
- ¿Quién llevará mi cuenta? ¿Puedo conocer al equipo técnico antes de firmar?
- Contadme la última incidencia grave que gestionasteis: qué falló, cuánto tardasteis, qué cambiasteis después.
- ¿Qué monitorización pondréis sobre mi infraestructura y qué alertas me llegarán a mí?
- ¿Cómo documentáis los cambios? ¿Tendré acceso a esa documentación?
- ¿Qué incluye exactamente la cuota y qué se factura aparte?
- Si mañana quiero cambiar de proveedor, ¿qué me llevo y en cuánto tiempo?
- ¿Qué NO hacéis? (La respuesta honesta a esta pregunta vale más que todo el catálogo.)
Desconfía del candidato que responde a todo sin dudar y sin matices. En infraestructura, la respuesta honesta a varias de estas preguntas empieza por «depende», seguido de los factores concretos de los que depende.
¿Quieres comparar opciones?
En Elimática ofrecemos soporte IT especializado para empresas B2B con SLA por escrito, equipo nominal y casos con métricas. Si estás evaluando opciones, puedes pedirnos un diagnóstico inicial sin compromiso y comparar.
Servidores gestionados | Diagnóstico gratuito.
Antes de comparar proveedores, conviene entender el modelo de servicio: qué es un MSP.