​

Customização e Builder

Esta página resume como o gb-fu-charles deve abordar a customização orientada pelo usuário e um futuro builder gráfico de journeys.

​

A resposta curta

Devemos pegar de referência o padrão do gbcrm e do ElevenLabs, mas sem copiar as plataformas completas deles para este repositório. O que se encaixa:

• atributos de contato definidos pelo workspace
• tags normalizadas
• segmentos dinâmicos salvos
• visualizações configuráveis de inbox e de contatos
• um builder gráfico de journeys tipado
• um futuro catálogo de ferramentas e uma camada de knowledge base

O que ainda não se encaixa:

• criação completa de objetos personalizados
• um motor de metadados amplo no estilo CRM
• uma plataforma de automação no-code de uso geral
• complexidade de agentes de IA antes que o plano de mensagens esteja consolidado

​

Por que isso importa

Sem um modelo real de customização, toda solicitação de:

• novas tags
• novas propriedades de contato
• novas colunas de segmento
• novos campos no painel lateral da inbox

se torna uma tarefa para desenvolvedores. Isso é operacionalmente lento e força trabalho de produto para dentro da engenharia, mesmo quando o requisito é específico de um workspace.

​

A direção recomendada

​

Fase 1: Customização controlada

Comece com:

• definições de atributos customizados de contato
• tags normalizadas em contatos e conversas
• definições e snapshots de segmento
• visualizações configuráveis de contato e de inbox

​

Fase 2: Schema de automação tipado

Antes de adicionar um canvas, defina:

• um modelo tipado de nó de journey
• um modelo tipado de condição
• referências estáveis a tags, segmentos, templates e atributos customizados
• regras de validação no momento da publicação

​

Fase 3: Builder gráfico ✅

Lançado (sprint de abril de 2025). Usa um módulo de grafo React Flow dedicado, com um pequeno catálogo de nós:

• trigger
• condição
• wait
• enviar template
• atualizar atributo
• adicionar/remover tag
• webhook de saída
• etapa de agente de IA
• saída

O editor está em /journeys/[id], com validação inline, detecção de ciclos e um pipeline de publicação que cria snapshots imutáveis de journey.

​

Fase 4: Knowledge e ferramentas ✅

Lançado (sprint de abril de 2025). Agora que o runtime de mensagens é durável:

• assets de knowledge para fatos de FAQ/política/produto (baseados no armazenamento de assets, BORD-187)
• um catálogo de ferramentas controlado (permissões de uso de ferramentas do agente na tabela ai_agents)
• ferramentas de prévia e simulação (renderizador em formato de telefone no construtor de templates, validação de nós de journey)

​

Por que não copiar o modelo completo do gbcrm?

O CRM irmão suporta um motor de metadados muito mais amplo:

• objetos personalizados
• campos personalizados em todo o produto
• visões gerais em grafo do modelo de dados
• infraestrutura de workflow builder

Essa amplitude é útil em um CRM. Seria pesado demais aqui se adotada por completo antes que o plano de controle do WhatsApp esteja estável.

​

Por que o ElevenLabs ainda é útil

As melhores coisas a se pegar de referência são os padrões de UX:

• entrada orientada por template
• catálogo na barra lateral esquerda mais canvas central
• fluxo de uso de template
• prévia/teste antes de publicar
• catálogos separados de knowledge e ferramentas

Essa é uma experiência de operador melhor do que jogar os usuários direto em JSON puro ou em um canvas de nós vazio.

​

Ordem recomendada

1. Atributos customizados
2. Tags normalizadas
3. Segmentos salvos
4. Visualizações configuráveis
5. Schema tipado de journey
6. Builder gráfico
7. Knowledge e ferramentas

​

Leia a seguir

• Arquitetura da Plataforma
• Matriz de Funcionalidades
• Roadmap