Skip to main content

​
Personalizzazione e Builder

Questa pagina riassume come gb-fu-charles dovrebbe affrontare la personalizzazione guidata dall’utente e un futuro journey builder grafico.

​
La risposta breve

Dovremmo prendere in prestito il pattern da gbcrm e ElevenLabs, ma senza copiare interamente le loro piattaforme in questo repository. Cosa si adatta:
  • attributi contatto definiti dal workspace
  • tag normalizzati
  • segmenti dinamici salvati
  • viste configurabili per inbox e contatti
  • un journey builder grafico tipizzato
  • un futuro catalogo di tool e un livello di knowledge-base
Cosa non si adatta ancora:
  • creazione completa di oggetti custom
  • un ampio motore di metadata in stile CRM
  • una piattaforma di automazione no-code general purpose
  • complessità da agente AI prima che il message plane sia reale

​
Perché è importante

Senza un vero modello di personalizzazione, ogni richiesta per:
  • nuovi tag
  • nuove proprietà contatto
  • nuove colonne di segmento
  • nuovi campi nel side-panel dell’inbox
diventa un task per gli sviluppatori. Questo è operativamente lento e spinge il lavoro di prodotto nell’engineering anche quando il requisito è specifico del workspace.

​
La direzione consigliata

​
Fase 1: Personalizzazione controllata

Iniziare con:
  • definizioni di attributi contatto custom
  • tag normalizzati su contatti e conversazioni
  • definizioni e snapshot di segmenti
  • viste configurabili per contatti e inbox

​
Fase 2: Schema di automazione tipizzato

Prima di aggiungere una canvas, definire:
  • un modello tipizzato di nodo journey
  • un modello tipizzato di condizione
  • riferimenti stabili a tag, segmenti, template e attributi custom
  • regole di validazione al momento della pubblicazione

​
Fase 3: Builder grafico ✅

Rilasciato (sprint di aprile 2025). Usa un modulo grafico React Flow dedicato con un piccolo catalogo di nodi:
  • trigger
  • condizione
  • attesa
  • invia template
  • aggiorna attributo
  • aggiungi/rimuovi tag
  • webhook in uscita
  • step agente AI
  • uscita
L’editor si trova su /journeys/[id] con validazione inline, rilevamento di cicli e una pipeline di pubblicazione che crea snapshot immutabili delle journey.

​
Fase 4: Knowledge e tool ✅

Rilasciato (sprint di aprile 2025). Ora che il runtime dei messaggi è stabile:
  • asset di knowledge per fatti su FAQ/policy/prodotto (basati sull’asset storage, BORD-187)
  • un catalogo di tool controllato (permessi di tool-use dell’agente nella tabella ai_agents)
  • strumenti di anteprima e simulazione (renderer phone-frame nel template builder, validazione dei nodi journey)

​
Perché non copiare interamente il modello di gbcrm

Il CRM affine supporta un motore di metadata molto più ampio:
  • oggetti custom
  • campi custom in tutto il prodotto
  • panoramiche a grafo del modello di dati
  • infrastruttura per workflow builder
Quell’ampiezza è utile in un CRM. Sarebbe troppo pesante qui se adottata in blocco prima che il control plane WhatsApp sia stabile.

​
Perché ElevenLabs è comunque utile

Le cose migliori da prendere in prestito sono i pattern UX:
  • ingresso template-first
  • catalogo a rail sinistro più canvas centrale
  • flusso use-template
  • anteprima/test prima della pubblicazione
  • catalogo separato di knowledge e tool
Questa è un’esperienza operatore migliore rispetto a gettare gli utenti in JSON crudo o in una canvas di nodi vuota.

​
Ordine consigliato

  1. Attributi custom
  2. Tag normalizzati
  3. Segmenti salvati
  4. Viste configurabili
  5. Schema journey tipizzato
  6. Builder grafico
  7. Knowledge e tool

​
Leggi anche