Service & Support gestiona el ciclo de vida completo del contacto con el cliente a través de cada canal de entrada. La recepción omnicanal recibe incidencias por correo electrónico, portal web, chat, teléfono, formulario de autoservicio y alerta generada por máquina, y las registra como casos estructurados en la cola correspondiente. La gestión de casos y tickets impulsa después cada elemento a través de la clasificación, la categorización, la asignación, el trabajo y la resolución, con la conversación completa y las notas de trabajo internas asociadas al registro.

Por encima del helpdesk se sitúan las tres disciplinas alineadas con ITIL. La gestión de incidencias restablece el servicio con rapidez y registra cada paso dado. La gestión de problemas investiga la causa subyacente de las incidencias recurrentes o graves y mantiene una biblioteca de errores conocidos y soluciones provisionales. La gestión de cambios gobierna cualquier alteración del entorno de servicio mediante una solicitud de cambio, una evaluación de riesgos y una aprobación formal. Los acuerdos de nivel de servicio y la escalada operan por debajo de todo ello, cronometrando cada caso frente a sus objetivos comprometidos de respuesta y resolución, y escalando antes de que se produzca un incumplimiento. El servicio de campo y las actuaciones de campo extienden el mismo control al trabajo que debe realizarse en las instalaciones, despachando técnicos, registrando lo que se hizo y cerrando el ciclo de vuelta al caso de origen.

En el centro del módulo está el caso: una única incidencia de cliente con un responsable, un estado, una prioridad, un canal de origen y un historial completo. Cualquier otro concepto del módulo o bien genera un caso, o bien rige cómo debe tratarse, o bien registra lo que se hizo para resolverlo. Los casos se agrupan en colas de servicio, cada una un flujo de trabajo para un equipo, una línea de producto o un segmento de cliente concretos, de modo que el enrutamiento y la carga de trabajo sean explícitos en lugar de accidentales.

Cada caso está regido por un acuerdo de nivel de servicio, la promesa que define con qué rapidez debe responderse y resolverse un caso de una determinada prioridad. El acuerdo no es un documento estático, sino un reloj activo: calcula los objetivos frente a calendarios laborales, se detiene cuando un caso está a la espera del cliente e impulsa la escalada a medida que se acercan los plazos. Esto es lo que hace que un compromiso sea medible en lugar de una mera aspiración.

Mientras que el helpdesk gestiona los contactos individuales, las prácticas ITIL gestionan los patrones. Una incidencia es una única interrupción del servicio. Un problema es la causa subyacente detrás de una o muchas incidencias, y su investigación da lugar a un error conocido: un fallo documentado con una solución provisional probada que los agentes aplican de inmediato mientras avanza la solución permanente. Un cambio es una modificación controlada del entorno de servicio, que lleva asociada su propia evaluación de riesgos y su cadena de aprobaciones, de modo que nada altere el entorno sin revisión. Por último, una actuación de campo representa el trabajo que sale del escritorio: una asignación a un técnico, planificada, despachada y reportada frente al caso al que da servicio. Estos conceptos se relacionan como una cadena natural, desde la pregunta formulada hasta la solución entregada y la recurrencia evitada.

El flujo de trabajo cotidiano es el recorrido del ticket. Un contacto llega por cualquier canal, se registra como un caso y se clasifica en una cola con una categoría y una prioridad que, a su vez, seleccionan el acuerdo de servicio que lo rige. Un agente toma el caso desde el escritorio impulsado por el conocimiento, lo trabaja con artículos sugeridos y resoluciones previas a mano, se comunica con el cliente y lo resuelve o lo escala. Los comentarios, tanto los orientados al cliente como los internos, construyen una auditoría completa del intercambio.

Cuando una interrupción es significativa, toma el relevo el flujo de trabajo de incidencias: se establece la gravedad, se publican actualizaciones a intervalos adecuados al impacto y se mantiene informados a los interesados hasta que se restablece el servicio. La recurrencia o el impacto grave desencadenan el flujo de trabajo de problemas, donde el análisis de causa raíz produce un error conocido y, en última instancia, una solicitud de cambio. Ese cambio avanza por el flujo de trabajo de cambios: se plantea una solicitud de cambio, se evalúa su riesgo, se planifica y se somete a un comité de aprobación antes de su implementación, y después se revisa una vez completada. El flujo de trabajo de campo despacha el trabajo en las instalaciones, hace un seguimiento de la asignación y el desplazamiento, y registra la finalización, las piezas y el tiempo de vuelta frente al caso. Cada flujo de trabajo alimenta al siguiente, de modo que un único fallo reportado puede fluir con limpieza de la incidencia al problema y al cambio sin salir del módulo.

El módulo está construido según la esencia de las prácticas de gestión de servicio de ITIL, no como un simple guiño a su vocabulario. Incidencia, problema y cambio son disciplinas distintas con sus propios estados, roles y registros, y los límites entre ellas se hacen cumplir en lugar de difuminarse. El cambio lleva un régimen de control genuino: cada solicitud de cambio incluye una categorización de tipo y riesgo, un plan definido de implementación y de vuelta atrás, y una secuencia de aprobación formal que hace las veces de un comité asesor de cambios, de modo que los cambios de emergencia, estándar y normales sigan cada uno el camino que su riesgo justifica.

La gestión del nivel de servicio es igual de exacta. Los objetivos se evalúan frente a calendarios de operación definidos y matrices de prioridad, de modo que un objetivo de cuatro horas significa cuatro horas laborables, contabilizando correctamente las pausas mientras un caso espera la aportación del cliente. La escalada es escalonada y basada en el tiempo, elevando la responsabilidad y la visibilidad a medida que se acerca un plazo, en lugar de hacerlo después de que expire. Cada caso, incidencia, problema, cambio y actuación de campo lleva una referencia duradera y legible por las personas, y se conserva el historial completo de estados, lo que ofrece un rastro completo y auditable de quién hizo qué y cuándo. La base de conocimiento se trata como una superficie de control de primer nivel: los errores conocidos y los artículos se presentan en contexto, de modo que una solución provisional probada llegue al agente en el momento de necesidad y la calidad de la resolución no dependa de la memoria individual.

Service & Support no es deliberadamente una isla. Extrae el contexto de cliente, contacto y titularidad que necesita del módulo CRM and Sales, de modo que cada caso quede anclado a una cuenta real y a su relación comercial. Los acuerdos de servicio se honran frente a las condiciones recogidas en Contract Management, de modo que la respuesta que recibe un cliente coincida con el servicio que compró. Cuando un caso resulta facturable, ya sea por trabajo fuera de alcance, por piezas o por una visita a las instalaciones, los costes fluyen a Finance para su facturación y reconocimiento de ingresos, en lugar de contabilizarse a mano.

Las actuaciones de campo se coordinan con Inventory and Asset Management para las piezas consumidas y los equipos objeto de servicio, y con los registros de personal de Human Resources para los técnicos despachados y las competencias que poseen. Los cambios que afectan al entorno de servicio se concilian frente a esos mismos registros de activos, de modo que la configuración que un cambio altera sea la configuración que ve el resto de la suite. Dado que cada módulo comparte un único tejido de identidad, permisos y datos, un agente de soporte, un controlador financiero y un técnico de campo actúan todos sobre el mismo registro subyacente, y una resolución registrada una sola vez es visible en todos los lugares en los que resulta relevante.

Los AI Workers son usuarios de primer nivel del módulo, con los mismos permisos y dejando el mismo rastro de auditoría que sus colegas humanos. Mediante consulta conversacional, un responsable pregunta en lenguaje natural qué acuerdos están en riesgo esta tarde o cuántas incidencias se remontan a un único problema, y recibe una respuesta extraída de datos de casos en vivo en lugar de un informe obsoleto. Los Workers ejecutan acciones directamente: clasificando y enrutando un caso entrante, redactando una respuesta al cliente a partir de la base de conocimiento, publicando una actualización de una incidencia o despachando una actuación de campo al técnico cualificado más cercano.

Vigilan de forma continua en busca de anomalías y excepciones. Un Worker señala un caso que deriva hacia un incumplimiento de servicio, un grupo de incidencias que apunta a un problema emergente, o un cambio planificado en una ventana de riesgo, y lo eleva antes de que se convierta en un fallo. En la recepción, los Workers realizan la extracción de documentos y datos, leyendo un correo electrónico entrante o un informe adjunto para rellenar la categoría, la prioridad y el activo afectado sin introducción manual. Ofrecen apoyo a la decisión a los agentes y a los gestores de cambios, resumiendo el historial de un caso, proponiendo una causa raíz probable a partir de errores conocidos previos, o evaluando el riesgo de un cambio propuesto frente a resultados pasados. Un Worker también puede actuar como nodo de aprobación o revisión en un flujo de trabajo: situándose en una secuencia de comité asesor de cambios para aprobar cambios estándar de bajo riesgo dentro de la política y escalar a una persona cualquier cosa que quede fuera de ella, de modo que el rendimiento rutinario siga siendo rápido y las decisiones que requieren juicio genuino sigan llegando a una persona.