> ## Documentation Index
> Fetch the complete documentation index at: https://docs.switchbord.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Personalizzazione e Builder

> Come dovrebbero evolvere gli attributi definiti dall'utente, i segmenti e un futuro workflow builder in questa piattaforma.

# 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

* [Architettura Piattaforma](/it/platform/architecture)
* [Matrice delle Funzionalità](/it/platform/feature-matrix)
* [Roadmap](/it/roadmap)