Standard: un solo numero, zero chiamate perse

​

Il principio

• Un numero solo, ovunque. Stesso numero per chat WhatsApp, SMS e chiamate: è il numero frontend. Nessun secondo recapito ospite. Il numero backend su cui vive il voice agent non è un secondo recapito: l’ospite non lo vede mai, e riceve le chiamate per inoltro dal frontend (Numero backend e numero frontend).
• Detto, non solo presente. Il numero va pronunciato e ripetuto: benvenuto, pre-arrivo, giorno del check-in, durante il soggiorno.
• Ogni chiamata persa genera un’azione, non un buco: alert al team più risposta automatica all’ospite.

​

Prerequisiti

• Il numero definitivo già collegato come sender WhatsApp e come sender SMS di default del workspace.
• Il numero definitivo come numero pubblico ospite (il frontend), con l’inoltro delle chiamate verso il numero backend dove risponde il VoiceAI. Non è un’opzione, è lo standard: il voice agent resta sempre sul backend, così un cambio di numero pubblico non tocca l’agente vocale.
• Un canale Slack dove il team riceve le escalation.

curl -s "https://api.conduit.ai/v1/workspaces/$WS/senders" \
  -H "Authorization: Bearer $CONDUIT_TOKEN"

​

Ordine di esecuzione

curl -s -X POST "https://api.conduit.ai/v1/call-groups" \
  -H "Authorization: Bearer $CONDUIT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "workspace_id": "'"$WS"'",
    "name": "Guest Line — Overflow",
    "strategy": "simultaneous",
    "member_user_ids": ["<user_id>", "..."],
    "phone_number_ids": ["<phone_number_config_id>"]
  }'

​

Come si verifica

1. Nessun residuo. Riesegui il dump del passo 1 e cerca il numero vecchio. Gli unici risultati ammessi sono le regole negative che hai scritto tu (“non dare mai questo numero”) e l’eventuale caller ID in uscita.
2. Recupero semantico. Interroga la KB con la domanda di un ospite vero:
   # MCP: semantic_knowledge_search
   { "query": "what number can I call you on, how do I reach you on WhatsApp" }
   
   Il nodo del numero unico deve essere il primo risultato con un punteggio alto (su Dubai: 0.906). Se non lo è, il nodo è scritto male o ce n’è un altro che gli fa concorrenza.
3. Rilettura dopo ogni scrittura. Ogni PUT /v1/workflows/{id} crea una nuova versione con nuovi id di step: gli id che avevi in mano prima della scrittura non valgono più. Rileggi il workflow dal server e conta le occorrenze del numero nuovo e di quello vecchio.
4. Prova dei canali. Chiamata e WhatsApp al numero frontend, ed escalation, da un telefono del team: è la verifica finale dei canali. La configurazione letta dice che il percorso esiste; solo la prova dice che arriva a qualcuno.

​

Errori che abbiamo già fatto

• Fidarsi dello stato del workflow. ACTIVE + enabled: true non dice nulla sul fatto che il messaggio parta. Su Dubai due workflow in produzione puntavano a un sender WhatsApp scollegato.
• runOnData cablato. Se il destinatario di uno step è un contatto fisso invece di quello della prenotazione, il workflow manda il messaggio sempre alla stessa persona, con dentro i dati di ospiti diversi. Non produce nessun errore e nessun alert: lo vedi solo aprendo le esecuzioni. Controlla il destinatario di ogni step che invia.
• Nome host cablato nel template. Le variabili dei template con un nome di persona scritto a mano restano lì anche quando la persona non lavora più con noi. Controllale a ogni giro.
• Lasciare un numero ritirato come caller ID in uscita. Se il concierge chiama da un numero diverso da quello unico, l’ospite richiama quel numero. Se non ha né voice agent né inoltro, la chiamata si perde in silenzio. Se per qualsiasi ragione il caller ID resta diverso, aggancia comunque quel numero al gruppo di chiamata e assicurati che il workflow chiamata persa lo copra.

​

Replicare su Italia e sugli studenti