Jornada del usuario en ITSM
ServiceNow como plataforma de transformación de la experiencia de servicio — gobernanza y buenas prácticas convirtiendo la resistencia en adopción estructurada y duradera.
Contexto
Una plataforma robusta. Subutilizada.
ServiceNow estaba implementado. Los procesos existían. El catálogo de servicios estaba estructurado. Las directrices de gobernanza seguían las buenas prácticas del framework de gestión de servicios de TI. Y aun así, los usuarios no operaban el sistema como debían — o simplemente no lo utilizaban.
El problema no era la herramienta. Era la distancia entre el usuario y el servicio: templates que no dialogaban con los problemas reales, una taxonomía desconectada del vocabulario cotidiano de quien necesitaba abrir un ticket, y la percepción difusa de que esquivar el portal era más eficiente que utilizarlo correctamente.
En un entorno corporativo de gran porte, esa distancia tiene un costo medible: tickets mal clasificados, reasignaciones en cadena, reaperturas recurrentes, tiempos de atención dilatados y equipos de soporte sobrecargados con un triaje que debería resolverse en el origen.
“El usuario no se resistía al sistema. Se resistía a la fricción que el sistema imponía — y al desconocimiento del costo que esa resistencia generaba para todos.”
El proyecto nació de la necesidad de invertir esa ecuación — no solo técnicamente, sino a través de la lente de la experiencia y la gobernanza. Hacer de ServiceNow un portal que el usuario elegiría usar, comprendiendo por qué importaba para sí mismo y para la organización.
Diagnóstico
Dónde estaba la fricción
El punto de partida fue mapear los puntos de fricción reales en la jornada — sin asumir el problema a priori, sino identificando sistemáticamente dónde el comportamiento se desviaba del flujo esperado y cuáles eran las consecuencias operativas de esa desviación.
Punto de fricción 01
Tickets abiertos con los templates incorrectos, generando reasignaciones sucesivas y prolongando el tiempo de resolución, con impacto directo en los SLAs.
Punto de fricción 02
Baja adherencia al portal: los usuarios preferían el contacto directo por e-mail o canales informales, esquivando el flujo estructurado y comprometiendo la trazabilidad y la gobernanza.
Punto de fricción 03
Reaperturas recurrentes — síntoma de atención prestada sin resolución efectiva, frecuentemente causada por un triaje impreciso desde la apertura.
Punto de fricción 04
Ausencia de correspondencia entre el vocabulario natural del usuario y la taxonomía del sistema. El usuario no sabía nombrar su problema en los términos del portal.
Punto de fricción 05
Templates con campos excesivos o desalineados con el proceso real, aumentando la fricción en la apertura y contribuyendo al abandono o al llenado inadecuado.
Punto de fricción 06
Desconocimiento de la lógica del proceso ITSM: cómo se enrutan los tickets, el impacto de la clasificación correcta y el papel de cada etapa en la resolución.
El diagnóstico evidenció que la fricción no estaba concentrada en un único punto, sino distribuida a lo largo de toda la experiencia de apertura y seguimiento — desde la intención inicial del usuario hasta la resolución efectiva y el cierre con calidad.
Enfoque
La adopción no se impone. Se estructura.
La hipótesis central fue que la adopción sostenida exige intervención simultánea en tres capas. Actuar en una sola produciría resultados parciales y no sostenibles.
Capa 01
Sistema
Estructura, templates y automatización. Hacer que el camino correcto sea genuinamente más fácil de recorrer.
Capa 02
Usuario
Comprensión, comportamiento y autonomía. Claridad sobre por qué el nuevo camino es mejor que el atajo.
Capa 03
Proceso
Flujo, gobernanza y buenas prácticas de gestión de servicios, alineadas con los requisitos de la organización.
“Ningún cambio de comportamiento se sostiene sin claridad sobre por qué el nuevo camino es mejor que el atajo — y sin que el sistema haga ese camino genuinamente más fácil de recorrer.”
Iniciativas
Los pilares de ejecución
Análisis comportamental y mapeo semántico
La investigación reveló un patrón consistente: al acceder al portal, el usuario quería escribir el problema con sus propias palabras y encontrar el template a partir de ahí, sin conocer la taxonomía del sistema. Ese insight fundamentó el mapeo semántico — el relevamiento de las expresiones y variaciones lingüísticas usadas para describir cada categoría, vinculadas directamente a los templates correspondientes. El resultado fue una capa de facilitación que eliminó la dependencia del conocimiento previo de la estructura del catálogo.
Reestructuración y racionalización de los templates
Auditoría completa del catálogo, revisando cada template en cuanto a su adherencia al proceso real y a la calidad del llenado. Se eliminaron campos redundantes, preguntas fuera de alcance y etapas que creaban fricción sin agregar valor. La racionalización redujo el tiempo de apertura, disminuyó los errores de clasificación y aumentó la completitud de la información entregada a los equipos.
Automatización de procesos e integración de plataformas
Mapeo y automatización de flujos de alto volumen — incidentes y solicitudes de distintas complejidades — para reducir el tiempo de resolución y garantizar consistencia. Una parte esencial fue mapear plataformas externas a integrar con ServiceNow: la integración con SailPoint IdentityIQ (IIQ), por ejemplo, automatizó tickets de identidad y acceso, eliminando etapas manuales. La priorización siguió el volumen, la criticidad y el impacto en el SLA.
Programa de educación, comunicación y gestión del cambio
Programa estructurado de comunicación interna y gestión del cambio — campañas dirigidas, comunicaciones por e-mail, materiales de apoyo y guías de uso. La estrategia fue más allá del “cómo usar”: explicó la lógica del proceso ITSM, el impacto de la clasificación correcta en el tiempo de atención y las consecuencias de esquivar el flujo. Hacer visible la lógica para el usuario final fue condición para que el cambio de comportamiento se sostuviera.
Capacitación de proveedores
Formación de los equipos proveedores responsables de la atención, garantizando que las mejoras en la jornada de apertura tuvieran correspondencia en la calidad y consistencia de la atención prestada. La adopción solo se consolida cuando ambos extremos de la jornada operan con el mismo entendimiento.
Expansión de la base de conocimiento
Estructuración de la base de conocimiento como infraestructura permanente de la jornada — no un recurso periférico, sino una capa de soporte disponible en cualquier fase. Artículos, documentación técnica por categoría y materiales de autoservicio hicieron al usuario progresivamente más autónomo, reduciendo la dependencia del contacto directo con el soporte.
Sostenimiento
No un proyecto. Un proceso.
Uno de los riesgos más comunes en las iniciativas de adopción es tratar el cambio como un evento: algo que ocurre, produce resultados y se cierra. La lógica aquí fue estructuralmente diferente.
Ciclo de mejora continua
Desde los primeros cambios, se estableció un ciclo sistemático de monitoreo y ajuste — siguiendo métricas de uso, identificando nuevos puntos de fricción y revisando templates, automatizaciones y materiales a medida que el comportamiento de los usuarios evolucionaba. Ese ciclo sigue activo, incorporado a la rutina de gestión del portal.
El sostenimiento transforma un resultado puntual en madurez operativa. Lo que empezó como intervención se volvió práctica institucionalizada — y es esa distinción la que caracteriza una transformación real de proceso.
Impacto
Lo que cambió
de satisfacción en el NPS interno, midiendo la percepción de los usuarios sobre la calidad del soporte y la experiencia con el portal.
Aumento medible en la adherencia a ServiceNow como canal oficial de apertura y seguimiento de tickets.
Reducción del tiempo medio de atención, con caída en el volumen de reasignaciones y en las reaperturas por resolución incompleta.
Reducción de tickets mal clasificados en la apertura, con mejora en la precisión del enrutamiento y en la completitud de la información.
Más allá de los indicadores cuantitativos, la transformación más relevante fue estructural: el portal dejó de percibirse como una exigencia burocrática y pasó a reconocerse como el camino más eficiente para resolver un problema — que es, en esencia, el objetivo de cualquier iniciativa de adopción exitosa.
Equipos de soporte con triaje más preciso, usuarios con mayor autonomía operativa y un proceso de atención con más previsibilidad y trazabilidad de inicio a fin.
Aprendizaje
Lo que el proyecto consolidó
- i.La adopción es un problema de diseño y gobernanza, no solo de formación. Capacitar al usuario sin simplificar el sistema y estructurar el proceso produce esfuerzo sin resultado duradero — las tres dimensiones deben integrarse.
- ii.El lenguaje del usuario es dato de proyecto, no detalle de implementación. Un template técnicamente correcto con terminología desconocida sigue produciendo fricción y error. El mapeo comportamental partió de cómo piensa el usuario, no de cómo se organiza el sistema.
- iii.La transformación de proceso exige acción en ambos extremos de la jornada. Mejorar la experiencia de quien abre tickets sin capacitar a quien los recibe es intervenir en la mitad del sistema.
- iv.La automatización sin mapeo de integraciones es automatización incompleta. Identificar plataformas externas a conectar (como SailPoint IIQ) fue condición para generar impacto real, no solo desplazar trabajo manual.
- v.Un resultado sostenible exige infraestructura de escucha y revisión continua. El ciclo de monitoreo garantizó que las mejoras siguieran siendo relevantes a medida que el entorno evolucionaba.
Síntesis
La adopción sostenida no nace de un sistema impuesto, sino de un sistema que el usuario elige usar porque lo entiende, y porque el camino correcto es el más fácil.
El Service Design en ITSM es, al final, el trabajo de alinear sistema, usuario y proceso hasta que la gobernanza y la experiencia apunten al mismo lugar.