Tras poner en orden la infraestructura de un contact center multicliente, el paso más delicado: sustituir el gestor de tickets. Un programa nacido en 2008, crecido por acumulación, con más de tres millones de tickets y una configuración imposible de gobernar sin el proveedor. Lo rehicimos sobre Odoo Community — pero mirando antes qué se usa de verdad.
01Antes de diseñar: mirar qué se usa de verdad
El primer documento no era un proyecto: era un análisis del uso real, consultando la base de datos. Los números cambiaron las prioridades: el 93% de los tickets no los abre una persona sino la centralita, al llegar la llamada — la integración telefónica es el corazón, no un accesorio. De los seis mil motivos configurados, el último año se usaron unos pocos cientos. Casi un ticket de cada tres no estaba atribuido a ningún cliente. Cinco estados nunca se habían usado. De ahí el principio: reproducir el núcleo que se usa, bien, y dejar el resto.
02Las decisiones de fondo
Todo open source y sin licencias: Odoo Community con los módulos helpdesk de la comunidad OCA, en un servidor en sede — sin cuotas, sin datos fuera de la empresa. Acceso con la cuenta de dominio. Separación rigurosa por cliente: cada empresa cliente ve solo sus tickets y clientes. Configurable por quien lo usa: estados, motivos, textos y wiki los gestionan las responsables — cuanto más se adapta solo el sistema, menos desarrollos hacen falta.
03Qué construimos
Una ficha de ticket pensada para el teléfono: sigue la secuencia de la llamada, los motivos más usados aparecen primero, las frases repetidas se volvieron textos rápidos de un clic. Un historial de cambios con valor legal: cada campo entra en el registro con valor anterior, autor y hora; tickets y notas no se borran, se corrigen añadiendo. Conectores directos a las bases de datos de los clientes: se busca al cliente por código, nombre o suministro y la ficha entra en el ticket, sin pasar por un servicio externo.
04API REST y wiki dentro del ticket
El nuevo sistema expone una API REST documentada (OpenAPI) con claves separadas por sistema externo, permisos por cliente, webhooks firmados. Y la base de conocimiento — más de tres mil artículos — se reordenó y se llevó dentro de la ficha del ticket: muestra los artículos del cliente y del motivo en curso, se busca con una palabra, se abre allí. El objetivo era uno: que las operadoras no tengan que abrir diez ventanas para responder a un cliente.
05Los datos: poblar antes de validar
Un sistema nuevo se valida con datos reales. Importamos todo el año en curso — unos 175.000 tickets y casi 80.000 fichas — con fechas originales, motivos múltiples y referencias. La importación completa tarda un cuarto de hora y es repetible: solo añade lo que falta. Sirve también para sacar los campos que se nos habían escapado.
06Lo que aprendimos
1. Los datos de uso valen más que cualquier requisito escrito. 2. Rehacer el núcleo, no todo. 3. La configurabilidad es una inversión: cada decisión dejada a quien usa el sistema es un desarrollo menos. 4. Tenerlo todo dentro del ticket: una información a un clic es una información que se usa.