El problema que queríamos resolver​

Varias de nuestras aplicaciones necesitaban un canal de soporte en vivo. Un ejemplo concreto es nuestro modulo Yurumi, para control de flota, que usa el personal de campo para registrar despachos y partes diarios: cuando algo no funciona, necesitan poder escribirle a soporte sin salir de la app.

No queríamos reinventar un sistema de chat ni sumar otra herramienta externa (tipo Intercom o Zendesk) que termine fragmentando los datos de los clientes en silos separados del ERP. Odoo ya tiene Live Chat, así que la pregunta era: ¿cómo lo usamos desde nuestras apps?

El problema: el widget de Live Chat, embebido en una app externa, abre siempre como “Visitante” anónimo y no se puede vincular con un contacto. El operador no sabe quién está del otro lado y la conversación no queda asociada a ningún contacto, falta contexto. Queríamos que, cuando un usuario ya identificado en nuestra app inicia una charla, esa conversación quede vinculada automáticamente a su contacto en Odoo — sin pedirle que se loguee de nuevo y sin romper la charla en curso.

Por qué usar el Live Chat de Odoo (y no otra cosa)​

• Ya está donde vive el negocio: ventas, proyectos, inventario, contactos… todo está en Odoo. El soporte también debería estar ahí.
• Sin herramientas ni licencias nuevas: los operadores atienden desde Discuss, el mismo lugar donde ya trabajan.
• Embebible en cualquier app: el widget se inserta con un par de scripts, en un app, un portal web o una app móvil.
• Datos centralizados: historial, métricas y contactos quedan dentro de Odoo, no en un tercero.

El desafío técnico​

Resolverlo tuvo su complejidad. Tres restricciones marcaron el diseño:

• El widget abre como invitado. Embebido cross-origin, el único identificador que el navegador expone de la charla es un guest_token que Odoo guarda en localStorage.
• Los usuarios no son usuarios de Odoo. En nuestras apps la gente se autentica con sus credenciales propias (empleado, magic link). No se puede usar el login nativo de Odoo.
• No se puede romper la charla viva. Un primer intento “fuerte” —reasignar el miembro de la conversación del invitado al contacto— rompía la sesión: al recargar, el widget perdía la charla y abría una nueva. Ese fue el gran aprendizaje.

La solución: un addon chico y genérico​

Construimos un módulo de Odoo, livechat_partner_link, cuyo único trabajo es vincular una charla en curso a un contacto (un res.partner). Es deliberadamente pequeño y genérico: depende solo de im_livechat, así que se puede reutilizar en cualquier app de la empresa.

El recorrido es simple: el usuario abre el chat, el navegador guarda el guest_token, el backend de la app resuelve (o crea) el contacto y llama al endpoint del módulo para asociar la charla. A partir de ahí, el operador ve quién es el cliente.

Los aspectos técnicos interesantes​

Una solución no invasiva​

La clave del diseño final: el “miembro vivo” de la charla sigue siendo el invitado. Nunca lo reasignamos. Así, todo lo que el widget necesita sigue funcionando intacto: la membresía del canal, la restauración de la sesión al recargar, el bus en tiempo real y el envío de mensajes.

El contacto se agrega en la capa de reporting: se apunta el historial del visitante al res.partner, se renombra al invitado con el nombre del contacto y se expone un botón “View Contact” en el panel del operador. El visitante simplemente sigue chateando, ahora identificado.

El endpoint​

La app, autenticada como un usuario técnico, llama a un único endpoint:

{ "guest_token": "42|<token>", "partner_id": 17 }

{ "ok": true, "data": { "linked": true, "thread_id": 42, "...": "..." } }

Es idempotente (volver a vincular la misma charla no hace nada) y genérico: resolver o crear el contacto —por ejemplo, buscándolo por email y dándolo de alta si no existe— lo hace cada app con la API estándar de res.partner. El módulo no se mete en eso, por eso sirve para cualquier integración.

Casos de uso​

• Apps totalmente separadas de Odoo: Los usuarios abre soporte desde la app y el equipo de soporte ya sabe quién escribe y desde qué app.
• Portal de clientes / sitio web: el cliente logueado chatea y la conversación queda atada a su ficha del CRM.
• Apps móviles o satélites: cualquier app con sus propios usuarios puede ofrecer soporte sin duplicar contactos.
• Post-venta y onboarding: seguimiento conversacional con el historial completo del cliente a mano.

La gran ventaja: todo centralizado en Odoo​

Más allá de la comodidad, el verdadero valor está en la centralización de datos. Cada app de la empresa embebe su propio canal de soporte, y todo termina en un solo lugar.

• Un solo contacto por persona: sin datos duplicados ni desincronizados entre aplicaciones.
• Conversaciones e historial en un solo lugar: el equipo de soporte trabaja desde Discuss, con el contexto completo del CRM (ventas, proyectos, tickets).
• Reporting y trazabilidad: métricas de soporte y seguimiento por cliente, nativos de Odoo.
• Menos costos y menos integraciones frágiles: nada de licencias de terceros ni sincronizaciones que se rompen.

Conclusión​

Con un addon chico, genérico y no invasivo, cualquier aplicación de la empresa puede ofrecer soporte en vivo usando el Live Chat de Odoo, dejando cada conversación atada a su contacto. Reutilizable, sin herramientas externas y con todos los datos donde tienen que estar: dentro de Odoo.

¿Tenés un desafío parecido con Odoo?​

En TechSed trabajamos con Odoo todos los días. Este módulo nació de una necesidad concreta de un proyecto y lo dejamos genérico como para reutilizarlo; nos pasa seguido que un requerimiento puntual, bien resuelto, termina siendo una pieza sólida y reutilizable.

Si estás pensando en algo así —conectar Odoo con una aplicación propia, automatizar un proceso o una customización a medida— escribínos y lo vemos juntos. Preferimos entender bien el problema antes de proponer: muchas veces la mejor solución es la más simple y, a veces, lo más honesto es recomendar no desarrollar nada.

¿Charlamos? Escribinos a hola@tech-sed.com y contanos qué necesitás.