
Gestión de incidencias IT — Autotask, Webroot y Datto RMM
Autotask PSA · Splashtop · Webroot · Datto RMM · MIDRANGE GROUP
Contexto
En MIDRANGE GROUP, dentro del equipo de Soporte Técnico junto al administrador de sistemas y redes del equipo, atendía las solicitudes de soporte de los clientes gestionados, recibidas a través de tres canales: llamadas telefónicas directas a la línea de soporte, correos electrónicos a la dirección de soporte y alertas automáticas generadas por el agente Datto RMM instalado en los equipos de los clientes.
Una vez abierto un ticket en Autotask, se enruta al equipo de Soporte Técnico (incidencias de usuario) o al equipo de Explotación (infraestructura y supervisión). A continuación, el tratamiento de un ticket real de cliente, de la recepción a la resolución.
Retos técnicos
- Los tickets llegan por tres canales distintos (teléfono, correo electrónico, alertas de Datto RMM) con tres niveles de detalle diferentes, así que la primera tarea en cada ticket es completar la información antes de empezar el diagnóstico real.
- Un ticket debe enrutarse correctamente desde la primera lectura — las incidencias de usuario van a Soporte Técnico, las de infraestructura a Explotación — y un enrutamiento incorrecto cuesta tiempo a ambos lados.
- Reproducir el síntoma exacto en remoto, antes de tocar cualquier configuración, es la única forma de evitar cambiar el ajuste equivocado en un equipo de cliente en producción.
- Una herramienta de seguridad que marca un sitio legítimo como malicioso (falso positivo de Webroot) resulta indistinguible de un bloqueo real desde el punto de vista del usuario — diferenciarlos exige comprobar la reputación real del dominio, no solo confiar en la alerta.
- Cada corrección debe documentarse en Autotask con claridad suficiente para servir tanto de justificante de facturación como de referencia de resolución futura — una nota de ticket vaga genera trabajo para el siguiente técnico.
Cómo llegan los tickets al equipo de soporte
- Teléfono: el cliente llama directamente a la línea de soporte. El técnico crea el ticket manualmente en Autotask y comienza el triaje de inmediato.
- Correo electrónico: el cliente envía un mensaje a la dirección de soporte. Autotask lo procesa automáticamente y crea el ticket, que luego se asigna a la cola correspondiente.
- Agente Datto RMM: el agente instalado en los equipos gestionados supervisa el dispositivo en tiempo real y puede generar alertas automáticamente (pico de CPU, disco lleno, evento de seguridad). Estas generan tickets en Autotask sin ninguna acción del cliente.
Resolución del incidente — paso a paso
- 1Paso 1 — Ticket recibido en AutotaskUn cliente informó que no podía acceder a un sitio web específico. Webroot mostraba una advertencia de sitio bloqueado en su equipo. El ticket me fue asignado, con Théo como apoyo.
- 2Paso 2 — Acceso remoto vía Datto RMMContactamos al cliente y solicitamos permiso para tomar el control remoto de su equipo vía Datto RMM. Esto nos permitió reproducir el problema en tiempo real, ver el mensaje exacto de advertencia de Webroot y confirmar qué URL estaba siendo bloqueada.
- 3Paso 3 — Diagnóstico: falso positivo de WebrootTras inspeccionar la URL bloqueada, determinamos que se trataba de un sitio profesional legítimo, incorrectamente marcado por la inteligencia de amenazas de Webroot. El sitio no era malicioso — Webroot lo había clasificado como sospechoso según su puntuación de reputación de dominio.
- 4Paso 4 — Exclusión de URL en la consola de gestión de WebrootNos conectamos a la consola de gestión de Webroot (CE 23.2) y navegamos hasta la lista de exclusión de URL dentro de la política del cliente. Añadimos el dominio bloqueado a la lista de exclusión (lista blanca). El cambio se propagó al equipo del cliente en pocos minutos, y el sitio quedó accesible sin ninguna intervención adicional en la máquina.
- 5Paso 5 — Resolución registrada en AutotaskSe creó una entrada de tiempo en Autotask con un resumen del problema, la causa raíz (falso positivo) y los pasos de resolución realizados. El ticket se cerró como Completado. El tiempo trabajado se registró para la facturación del cliente y como parte de la trazabilidad de auditoría.
Impacto
Incidencia resuelta en una única sesión, totalmente en remoto, sin desplazamiento ni reinstalación de software en el equipo del cliente.
Cifras clave
Buenas prácticas
- Los falsos positivos de Webroot en sitios profesionales legítimos son un escenario de soporte recurrente: el primer reflejo debe ser siempre revisar la lista de exclusión de URL antes de escalar o reconfigurar el equipo.
- El acceso remoto vía Datto RMM elimina la necesidad de desplazamientos in situ para la mayoría de incidencias de usuario, reduciendo significativamente el tiempo de resolución.
- Las entradas de tiempo en Autotask no son opcionales: sirven tanto de justificante de facturación para el cliente como de base de conocimiento consultable para incidencias recurrentes.
- El enrutamiento importa: distinguir desde la primera descripción un ticket de Soporte Técnico (usuario) de un ticket de Explotación (infraestructura) ahorra tiempo y evita asignaciones incorrectas.
- Reproducir siempre el problema de forma remota antes de tocar cualquier configuración — confirmar el síntoma exacto evita cambios prematuros o incorrectos.
Límites conocidos y decisiones
- Este caso cubre un ticket representativo de principio a fin, no el volumen completo de tickets que atendía — el flujo descrito (recepción → acceso remoto → diagnóstico → corrección → documentación) es el que se aplicaba a cada ticket, con distinta profundidad según la complejidad.
- La exclusión de URL en la consola de Webroot corrige el síntoma inmediato para el dominio señalado; no reentrena la puntuación de reputación subyacente de Webroot, por lo que un falso positivo similar puede repetirse en otra URL — es una limitación del propio fabricante, no algo corregible desde la consola.
- La resolución remota vía Datto RMM asume que el equipo del cliente es alcanzable y que el usuario está disponible para autorizar el acceso; un ticket en el que alguna de estas condiciones no se cumpla requeriría una visita in situ, fuera del alcance del flujo de Soporte Técnico descrito aquí.
- El enrutamiento entre Soporte Técnico y Explotación se basaba en la descripción inicial, lo cual sigue siendo una valoración; un ticket que a primera vista parece de usuario (como este) puede tener igualmente una causa raíz de infraestructura, y viceversa.
Herramientas utilizadas
Capturas de pantalla
