O modelo de dados decide se o contexto é partilhado ou perdido
No suporte B2B, quase todas as ferramentas herdam um modelo pensado para helpdesk de produto: um bilhete pertence a um utilizador final e pouco mais. Isso chega para responder a incidentes, mas não para perceber uma conta. Quando o modelo não relaciona empresa, contactos, produtos e conversas, o contexto não é partilhado: é reconstruído à mão em cada interação.
A ontologia de dados — como as entidades são modeladas e ligadas — é o que determina se o conhecimento flui ou fica encerrado em silos. Um bom modelo não é só mais arrumado: é a condição para a IA e a equipa poderem raciocinar sobre a relação com o cliente.
O núcleo: empresa → contacto → bilhete → produto
A Elevatia parte de um núcleo pequeno e explícito:
- Empresa (a conta B2B) é a raiz. Tudo pende dela.
- Contacto pertence a uma empresa; um contacto sem empresa não tem contexto.
- Bilhete é aberto por um contacto e associado a uma empresa; não é um objeto solto.
- Produto é o que a empresa tem contratado, e os bilhetes podem ligar-se a um produto concreto.
Esta cadeia de relações é o que permite responder a “o que se passa com esta conta?” em vez de só “o que diz este bilhete?”. A diferença é entre gerir incidentes e gerir relações.
Como se liga o conhecimento
Sobre esse núcleo, a base de conhecimento não é um apêndice isolado: os seus artigos ligam-se a produtos, empresas e temas com ligações bidirecionais (estilo wiki). Um artigo sobre como configurar uma integração pode referenciar o produto a que se aplica, e da ficha do produto chegas a esse artigo e às suas ligações relacionadas.
O resultado: quando um agente abre um bilhete de um produto, vê não só o histórico de incidentes, mas o conhecimento relevante já ligado. E a IA pode propor respostas citando artigos que de facto estão ligados à realidade dessa conta, não fragmentos soltos.
Partilhado vale mais que isolado
A tentação em muitas ferramentas é isolar: cada módulo com a sua tabela, a sua lógica, o seu export. É limpo a curto prazo e caro a longo prazo, porque cada isolamento é um contexto que depois tem de ser reunido à mão.
O princípio da Elevatia é o contrário: partilhado > isolado. O mesmo registo de empresa alimenta o suporte, o comercial, o painel de saúde e o assistente. A ontologia é o que permite que cada módulo leia e escreva sobre entidades comuns sem as duplicar nem desse sincronizar.
E como cada conta é diferente, a ontologia de base é definível por tenant: cada organização pode estender as suas ligações e os seus tipos sem partir o modelo comum que todos os módulos partilham.
O modelo é o produto
Um helpdesk diferencia-se pela interface; uma plataforma operacional diferencia-se pelo seu modelo de dados. Se o modelo relaciona bem, tudo o resto (IA, automatizações, dashboards) constrói-se por cima sem atrito. Se o modelo isola, nenhuma camada superior conserta a fragmentação.
Se queres ver o modelo aplicado ao teu caso, pede o piloto gratuito (~4 semanas, sem custo) ou lê o que é a Elevatia. Também podes escrever-nos para info@elevatia.io — respondemos em português.