Catálogos de Servicio por Área: Legal, Finanzas y Mantenimiento
September 23, 2026
Piensa en la última vez que necesitaste algo simple de otra área: la revisión de un contrato, la aprobación de un gasto, el mantenimiento de una oficina. Es probable que hayas terminado llenando un formulario que te pedía describir una "falla", elegir un nivel de "prioridad" y seleccionar una categoría pensada para un computador dañado, no para una revisión legal. Así que cerraste la pestaña y enviaste un correo en su lugar.
Ese no es un problema de capacitación. No es que Legal, Finanzas o Mantenimiento "se resistan" a usar las herramientas que TI les entrega. Es que la herramienta que les dieron nunca fue pensada para ellos.
La mayoría de las empresas que amplían su mesa de servicio más allá de TI lo hacen de la misma forma: toman el portal construido para reportar fallas técnicas y lo abren a todos los demás. La lógica parece razonable: TI ya tiene un sistema de tickets funcionando, una taxonomía de categorías, SLAs definidos y un equipo que sabe operarlo, así que ¿por qué no dejar que Legal y Finanzas también lo usen?
En la práctica, esto casi nunca funciona como se espera. El portal pregunta lo que no corresponde. Una solicitud de NDA no encaja en campos diseñados para "hardware", "red" o "falla de software". Los niveles de prioridad calibrados para una caída de sistema no tienen sentido frente a la fecha límite de un contrato. Las categorías, el lenguaje, incluso la identidad visual del formulario le comunican una sola cosa a quien lo está llenando: este es el sistema de TI, no el mío.
Es la misma dinámica que mantiene creciendo el atraso de tickets de la propia mesa de servicio de TI, ahora repitiéndose en tres o cuatro áreas a la vez, cada una con su propia cola invisible. Entonces lo usan una vez, deciden que no encaja con su forma de trabajar, y regresan silenciosamente a lo que ya les funcionaba: hilos de correo, mensajes de WhatsApp y hojas de Excel compartidas para llevar el seguimiento a mano. Cada área termina operando su propio proceso informal y sin documentar para resolver exactamente lo que una plataforma de gestión de servicios debería resolver. Nadie tiene claro cuántas solicitudes están abiertas, quién es responsable de cada una, o cuánto tiempo llevan pendientes. Un gerente de Finanzas siguiendo aprobaciones de gastos en una hoja de cálculo, un coordinador de Mantenimiento gestionando solicitudes por correo, un equipo Legal atendiendo revisiones de NDA por WhatsApp: nada de esto es visible, nada se mide, y todo ocurre en paralelo a una plataforma de gestión de servicios que la empresa ya paga.
Lo incómodo es que esto no es un problema de resistencia a la tecnología. Es un problema de idioma. La tecnología que le entregaron a estos equipos simplemente no habla su idioma, y ningún recordatorio interno de "por favor usen el portal" arregla un formulario que nunca fue diseñado pensando en cómo trabajan realmente Legal, Finanzas o Mantenimiento.
Este es exactamente el escenario que GB Advisors y Halo recorrieron en vivo, con pantallas reales y un ticket real, en una sesión de 45 minutos pensada específicamente para líderes de Legal, Finanzas y Mantenimiento, no de TI. Mira la grabación completa aquí para ver el catálogo, la demo y las preguntas y respuestas en contexto antes de seguir leyendo.
La Gestión de Servicios Empresariales (ESM, por sus siglas en inglés), la práctica de aplicar los principios de gestión de servicios más allá de TI, no es una idea nueva, y la mayoría de las empresas que la intentan no se equivocan al intentarlo. Una encuesta global reciente encontró que dos tercios de las organizaciones (67.6%) ya tienen una estrategia de ESM en marcha, un salto importante frente a hace pocos años, y que las capacidades de catálogo de servicios y portal de autoservicio ya están presentes en más de la mitad de ellas. La intención está. Lo que suele fallar es la ejecución, y el error más común es tratar "darle acceso a otras áreas a la herramienta de TI" como si fuera lo mismo que "construirles una experiencia de gestión de servicios que encaje con su trabajo".
Esto también explica por qué la adopción del portal de autoservicio se estanca muy por debajo de lo esperado en tantas empresas: la gente no está rechazando el autoservicio como concepto, está rechazando un portal específico que no se construyó pensando en su trabajo. La distinción importa porque la mayoría de las plataformas de ESM venden el mismo argumento de fondo: una sola herramienta, extendida hacia afuera desde TI. El portal es el mismo, los tipos de ticket se heredan de la taxonomía de TI, y se espera que cada área se adapte a una estructura que nunca fue pensada para ella. Es un default comprensible, reutilizar lo que ya existe es más barato que construir algo nuevo, pero pone el peso de la adaptación sobre quienes menos están en posición de absorberlo: líderes de área que no eligieron el software y no tienen ninguna razón para aprender su lógica.
Este es también el punto donde muchas implementaciones de ESM pierden impulso sin que nadie lo note del todo. Un catálogo de servicios construido sin la participación del área que lo va a usar tiende a usarse exactamente una vez, la primera vez que alguien está obligado a hacerlo, y luego se abandona en cuanto existe un canal informal más rápido, que para la mayoría de las áreas no-TI es un correo o un WhatsApp a alguien que ya conocen. La adopción no falla porque la gente se niegue a cambiar cómo trabaja; falla porque el sistema nuevo les pide describir su trabajo en términos que no corresponden a cómo realmente lo piensan. Resolver eso no es un problema de capacitación. Es una decisión de diseño, tomada una sola vez, a nivel del catálogo mismo.
Nosotros trabajamos al revés cuando diseñamos programas de ESM para nuestros clientes en Legal, Finanzas, RR. HH. y Mantenimiento: en lugar de un solo portal estirado para cubrir a todos, cada área tiene su propio catálogo, construido alrededor de cómo esa área realmente habla de su trabajo, corriendo sobre una sola plataforma por debajo.
Aquí está la diferencia práctica, y es un punto de partida distinto al enfoque más común de intentar unificar las solicitudes de TI, RR. HH. y otras áreas detrás de una sola puerta de entrada genérica. Con el enfoque de HaloITSM para gestión de servicios empresariales, Legal ve su propio catálogo. Finanzas ve su propio catálogo. Mantenimiento ve su propio catálogo. Nadie en esos equipos necesita saber, ni le tiene que importar, que hay una sola plataforma funcionando detrás de los tres. Lo que ven es una experiencia de servicio diseñada alrededor de su vocabulario, sus categorías y sus tiempos.
Para Legal, ese catálogo puede incluir solicitudes de revisión de contratos, generación de NDA y consultas de cumplimiento normativo: categorías que reflejan el trabajo legal real, no tickets de TI adaptados. Para Finanzas, son aprobaciones de gastos, órdenes de compra y solicitudes de reembolso, cada una con los campos que un controller realmente necesita para decidir. Para Mantenimiento, son solicitudes de mantenimiento, reserva de espacios y gestión de activos físicos, con la opción de adjuntar directamente una foto de una tubería con fuga en lugar de describirla en un párrafo escrito para alguien que nunca la va a ver.
En el recorrido en vivo del webinar, estos tres catálogos se ven así:
Nada de esto es genérico. Cada área configura las categorías, el lenguaje y los tiempos de respuesta que corresponden a su propio negocio, no una versión de las categorías de TI con las etiquetas cambiadas. Y cuando más adelante se suma RR. HH. o Compras, el patrón se repite: un catálogo nuevo, no una herramienta nueva, ni una nueva relación con un proveedor, ni algo más que TI tenga que operar.
Los formularios se construyen sin código, lo que significa que Legal o Finanzas pueden diseñar exactamente la pantalla de ingreso que su proceso necesita, sin esperar a un desarrollador ni abrir un ticket propio a TI para pedirlo (una ironía que aparece más seguido de lo que uno esperaría cuando los catálogos de servicio se tratan como un proyecto de ingeniería). Los flujos de aprobación siguen la misma lógica: Finanzas puede configurar doble aprobación para gastos sobre cierto monto, y un contrato que necesite el visto bueno tanto de Legal como de Finanzas puede enrutarse automáticamente por una cadena de aprobación cruzada, en lugar de perseguirse manualmente por correo.
Las notificaciones y los SLA funcionan igual: cada catálogo define sus propios tiempos de respuesta y resolución, en lugar de heredar los tiempos que TI configuró originalmente para incidentes de hardware. Una solicitud de mantenimiento por una lámpara dañada y una solicitud legal de revisión de contrato nunca debieron compartir un SLA razonable, así que ahora no tienen que hacerlo.
Nada de esto saca a TI de la ecuación; cambia de qué es responsable. TI sigue siendo dueño y administrador de la plataforma, de la misma forma en que un equipo de Mantenimiento es dueño de un edificio sin aprobar personalmente cada reunión agendada adentro. Lo que cambia es que TI deja de ser quien opera las solicitudes de Legal o aprueba los procesos de Finanzas, trabajo que nunca fue realmente suyo, aunque terminara cayendo en su escritorio por default por ser dueños del sistema de tickets. Y como cada área nueva corre sobre su propio catálogo dentro de la misma plataforma, sumar RR. HH. o Compras más adelante no le agrega carga operativa a TI, como sí lo haría montar una herramienta separada para cada área.
Vale la pena recorrer la misma solicitud bajo ambos modelos, de principio a fin.
Con el portal único de TI: alguien en Legal necesita revisar un NDA antes de una llamada con un proveedor mañana. Abre el portal de la empresa, se encuentra con un formulario hecho para fallas de hardware y red, e intenta forzar la solicitud en campos que no le quedan: "categoría: otro", "prioridad: alta", un cuadro de texto libre donde explica, en un párrafo, en qué consiste realmente una revisión de contrato. La envía, recibe una confirmación automática que suena a ticket de red, y no tiene forma de saber si llegó a la persona correcta. Por la tarde, sin novedades a la vista, termina escribiéndole directamente a la gerencia legal por correo, y el ticket queda abierto y sin tocar, una entrada más en una cola que nadie del lado legal está revisando.
Con el modelo de catálogo por área: la misma persona abre la pantalla de solicitudes propia de Legal, elige "Revisión de Contrato" de una lista de categorías que ya corresponden a cómo Legal habla de su trabajo, adjunta el borrador del NDA y marca la fecha límite de la llamada en un campo pensado exactamente para eso. La solicitud se enruta automáticamente al equipo de operaciones legales responsable de las revisiones, que recibe una respuesta sugerida basada en la propia base de conocimiento de Legal. Si el contrato también necesita el visto bueno de Finanzas por superar cierto monto, la cadena de aprobación lo enruta ahí automáticamente, sin necesidad de un correo aparte. Quien hizo la solicitud puede revisar el estado en cualquier momento sin preguntarle a nadie, porque el ticket, no un hilo de correo, es el registro.
La tecnología de base puede ser la misma en ambos casos. Lo que cambia por completo es el diseño de la entrada, las categorías y el flujo alrededor de ella, que es el argumento real a favor de un catálogo por área frente a un portal compartido: no es una herramienta más grande, es una mejor ajustada.
La brecha entre "el portal que nos dio TI" y "un sistema que encaja con cómo realmente trabajamos" tiende a ser más amplia en organizaciones que operan en varios países de la región, por razones específicas de cómo funcionan día a día los equipos de Legal, Finanzas y Mantenimiento aquí. Los equipos legales suelen gestionar contratos y requisitos de cumplimiento que varían país por país, algo que una categoría genérica de ticket de TI nunca fue pensada para capturar. Los equipos de Finanzas a menudo manejan cadenas de aprobación que involucran visto bueno regional y corporativo entre zonas horarias distintas, justo el tipo de flujo de aprobación de varios pasos que primero se rompe en un hilo de correo. Y en toda la región, WhatsApp suele ser el canal por defecto para cualquier cosa que necesite respuesta rápida, que es precisamente por qué tantas solicitudes de área terminan ahí en lugar de en un sistema sobre el que alguien pueda reportar después.
Con más de 15 años implementando TI y gestión de servicios empresariales para más de 1,600 clientes en América Latina y el Caribe, este es un patrón que vemos repetirse en distintas industrias: rara vez es que una empresa carezca de una plataforma de gestión de servicios. Es que la plataforma que tiene fue definida para TI y nunca se extendió, de una forma que realmente encaje, hacia las áreas que hoy están pidiendo el mismo tipo de estructura que TI ha tenido por años.
Una capa de IA que corre sobre toda la plataforma cambia cómo se mueven las solicitudes una vez enviadas, de tres formas concretas. Primero, la clasificación y el enrutamiento automático hacen que una solicitud llegue al equipo correcto sin que quien la envía necesite saber a quién dirigirse: el sistema lee la solicitud y la envía a Legal, Finanzas o Mantenimiento sin un paso de triage humano en el medio. Segundo, los agentes que atienden las solicitudes reciben respuestas sugeridas basadas en la base de conocimiento propia de cada catálogo, así que un agente de Finanzas respondiendo una consulta de reembolso no está improvisando de memoria ni buscando en correos antiguos. Tercero, un agente virtual puede resolver solicitudes comunes de cualquier área directamente, desde un solo punto de entrada, sin que el ticket llegue nunca a una cola humana.
Nada de esto exige que cada área entienda de IA, escriba prompts o administre una herramienta aparte. Corre por debajo del catálogo que ya usan, de la misma forma en que la plataforma misma permanece invisible para ellos.
La forma más clara de ver la diferencia entre un catálogo por área y un portal genérico de TI es verlo en uso. En el recorrido en vivo, una solicitud de Mantenimiento arranca desde una pantalla simple de "¿En qué te podemos ayudar hoy?" con opciones directas (solicitar algo, reportar una falla, mis tickets, artículos de ayuda), nada que asuma conocimiento técnico. De ahí, un formulario específico de Mantenimiento pide exactamente lo que necesita un problema de plomería: una descripción y una foto, no un número de serie de un equipo ni un diagnóstico de red. El ticket resultante, generado automáticamente como una "Solicitud de Plomería", confirma el punto: la categoría en sí fue escrita para Mantenimiento, no adaptada de un tipo de ticket de TI.
Del lado del administrador, la misma plataforma muestra un catálogo completo de áreas (TI, RR. HH., Mantenimiento, Compras), cada una configurable de forma independiente, junto con detalle operativo real: una notificación automática por correo en el momento en que se registra un ticket, un dashboard del agente en vivo con incidentes abiertos, tickets sin asignar y SLA por vencer, y un tipo de ticket de Legal construido específicamente alrededor de los campos de revisión de contratos, asignado a su propio equipo de agentes. Las integraciones cierran el cuadro: la plataforma se conecta con herramientas como DocuSign y los sistemas ERP existentes en lugar de reemplazarlos, algo que importa para los equipos de Legal y Finanzas que ya tienen sistemas documentales y financieros que no están buscando abandonar.
Cada pantalla descrita arriba se muestra en vivo en la grabación: el ticket de mantenimiento con la foto adjunta, el catálogo de revisión de contratos de Legal, la configuración de SLA para Finanzas y toda la sesión de preguntas y respuestas que siguió. Mira la sesión completa de 45 minutos aquí si quieres ver la mecánica antes de leer los resultados a continuación.
Los equipos que pasan a un catálogo propio por área suelen describir la misma lista corta de cambios. Pueden resolver lo que necesitan sin tener que aprender primero el vocabulario de TI. El seguimiento manual por correo, WhatsApp y hojas de cálculo baja, porque la solicitud misma ahora queda registrada en algún lado en lugar de vivir en la bandeja de entrada de alguien. Los líderes obtienen visibilidad real de qué está pendiente, quién es responsable y desde cuándo, una visibilidad que simplemente no existe cuando las solicitudes están dispersas en canales personales. Y el equipo recupera tiempo, porque nadie gasta parte de su semana persiguiendo el estado de una solicitud que debería tomar cinco minutos consultar.
Ese último punto se conecta con algo que va más allá de esta plataforma en particular: investigaciones sobre automatización liderada por TI muestran que eliminar el seguimiento manual repetitivo a escala puede liberar miles de horas al año incluso en una sola área, una vez que las solicitudes dejan de depender de que alguien recuerde hacer seguimiento. La misma lógica aplica a la escala de un equipo de Legal o Finanzas, solo que con números más pequeños y un retorno más rápido.
Vale la pena también ser honestos sobre por qué tantos esfuerzos de ESM se estancan antes de llegar a este punto. Investigaciones más amplias sobre implementaciones de gestión de servicios empresariales han encontrado que buena parte de las iniciativas no logran entregar el valor esperado, y la razón más común no es el software: es tratar ESM como el despliegue de una herramienta en lugar de un cambio de modelo operativo que necesita trabajo real de diseño sobre categorías, responsables y lógica de aprobación antes de encender cualquier plataforma. Un enfoque de catálogo por área evita buena parte de ese riesgo por diseño, porque cada catálogo se construye desde el principio alrededor del proceso real de un equipo, en lugar de una sola estructura genérica estirada para cubrir cinco áreas distintas a la vez.
Hay algunas preguntas que suelen surgir cada vez que este modelo se presenta a líderes de área fuera de TI, y vale la pena responderlas directamente.
¿Se va a sentir que estamos usando el sistema de TI? No: cada catálogo puede tener su propio nombre y su propia identidad visual, así que la experiencia se lee como "el formulario de solicitudes de Legal", no como "un ticket en la herramienta de TI".
¿Cuánto tiempo toma tener un catálogo funcionando? Como los formularios son sin código, un catálogo básico por área puede estar activo en cuestión de días, no en los meses que tomaría una herramienta construida a la medida desde cero.
¿Quién lo configura, nosotros o TI? En la práctica, ambos. El área define lo que necesita, y un partner o TI puede acompañar el diseño para que el catálogo refleje cómo el equipo realmente trabaja, en lugar de una plantilla genérica.
¿Pagamos licencia por cada empleado que hace una solicitud? No: la licencia se calcula por los agentes que resuelven solicitudes, no por cada empleado que eventualmente podría hacer una, lo que cambia bastante la ecuación para áreas con un equipo de atención pequeño y una base grande de usuarios.
¿Esto compite con herramientas como DocuSign o nuestro ERP? No: está pensado para integrarse con los sistemas que Legal y Finanzas ya usan, no para reemplazarlos.
¿En qué se diferencia realmente de otras plataformas de ESM? Menos en la tecnología de fondo y más en la experiencia de quien pide el servicio: la mayoría de las plataformas se diferencian por capacidad técnica; esta se diferencia por si la persona que llena el formulario siente que el formulario fue hecho para ella.
¿TI pierde control de la plataforma cuando otras áreas tienen su propio catálogo? No: TI mantiene la propiedad administrativa de la plataforma completa, de la misma forma en que un administrador de edificio es dueño del edificio sin aprobar cada reunión agendada adentro. Lo que cambia es operativo, no administrativo: TI deja de ser el equipo que atiende las consultas contractuales de Legal o aprueba las cadenas de gastos de Finanzas, trabajo que rara vez fue un buen uso del tiempo de un equipo de TI.
¿Qué pasa con las solicitudes que ya están en correos y hojas de cálculo hoy? No hace falta migrarlas todas de golpe antes de arrancar. La mayoría de los equipos empiezan con las solicitudes nuevas entrando por el catálogo desde el primer día, mientras lo que ya está en curso en los canales antiguos se cierra como siempre se ha hecho. El backlog no bloquea el cambio, solo deja de crecer.
Nada de esto arranca comprando software. Arranca mapeando cómo se vería realmente un catálogo para tu equipo: las categorías, los formularios, la cadena de aprobación, los SLA que tienen sentido para cómo Legal, Finanzas o Mantenimiento operan de verdad en el día a día. Esa conversación de mapeo vale la pena tenerla antes de tomar cualquier decisión de plataforma, porque un catálogo construido alrededor de un proceso real se sostiene; uno construido alrededor de una plantilla genérica no.
Si el escenario descrito aquí (el portal que pregunta lo que no corresponde, el regreso silencioso al correo y las hojas de cálculo, las solicitudes que nadie puede contabilizar) te suena familiar, los más de 15 años de GB Advisors implementando ESM en América Latina y el Caribe significan que ya hemos mapeado esta misma conversación para equipos de Legal, Finanzas y Mantenimiento, no solo para departamentos de TI. Conversemos sobre el mapeo del catálogo de tu área, y revisamos juntos cómo se vería específicamente para tu equipo, no una demo genérica.
