El modelo de datos decide si el contexto se comparte o se pierde

En soporte B2B, casi todas las herramientas heredan un modelo pensado para helpdesk de producto: un ticket pertenece a un usuario final y poco más. Eso basta para responder incidencias, pero no para entender una cuenta. Cuando el modelo no relaciona empresa, contactos, productos y conversaciones, el contexto no se comparte: se reconstruye a mano en cada interacción.

La ontología de datos —cómo se modelan y enlazan las entidades— es lo que determina si el conocimiento fluye o se queda encerrado en silos. Un buen modelo no es solo más ordenado: es la condición para que la IA y el equipo puedan razonar sobre la relación con el cliente.

El núcleo: empresa → contacto → ticket → producto

Elevatia parte de un núcleo pequeño y explícito:

  • Empresa (la cuenta B2B) es la raíz. Todo cuelga de ella.
  • Contacto pertenece a una empresa; un contacto sin empresa no tiene contexto.
  • Ticket se abre por un contacto y se asocia a una empresa; no es un objeto suelto.
  • Producto es lo que la empresa tiene contratado, y los tickets se pueden vincular a un producto concreto.

Esta cadena de relaciones es lo que permite responder a “¿qué le pasa a esta cuenta?” en lugar de solo “¿qué dice este ticket?”. La diferencia es entre gestionar incidencias y gestionar relaciones.

Cómo se enlaza el conocimiento

Sobre ese núcleo, la base de conocimiento no es un apéndice aislado: sus artículos se vinculan a productos, empresas y temas con enlaces bidireccionales (estilo wiki). Un artículo sobre cómo configurar una integración puede referenciar al producto al que aplica, y desde la ficha del producto se llega a ese artículo y a sus enlaces relacionados.

El resultado: cuando un agente abre un ticket de un producto, ve no solo el historial de incidencias, sino el conocimiento relevante ya conectado. Y la IA puede proponer respuestas citando artículos que sí están enlazados a la realidad de esa cuenta, no fragmentos sueltos.

Compartido vale más que aislado

La tentación en muchas herramientas es aislar: cada módulo con su tabla, su lógica y su export. Es limpio a corto plazo y caro a largo plazo, porque cada aislamiento es un contexto que después hay que volver a unir a mano.

El principio de Elevatia es el contrario: compartido > aislado. El mismo registro de empresa alimenta al soporte, al comercial, al panel de salud y al asistente. La ontología es la que permite que cada módulo lea y escriba sobre entidades comunes sin duplicarlas ni desincronizarlas.

Y como cada cuenta es distinta, la ontología base es definible por tenant: cada organización puede extender sus enlaces y sus tipos sin romper el modelo común que comparten todos los módulos.

El modelo es el producto

Un helpdesk se diferencia por su interfaz; una plataforma operativa se diferencia por su modelo de datos. Si el modelo relaciona bien, todo lo demás (IA, automatizaciones, cuadros de mando) se construye encima sin fricción. Si el modelo aísla, ninguna capa superior arregla la fragmentación.

Si quieres ver el modelo aplicado a tu caso, solicita el piloto gratuito (~4 semanas, sin coste) o lee qué es Elevatia. También puedes escribirnos a info@elevatia.io — respondemos en español.