Skip to main content

​
Le escalation risolte per sbaglio si riaprono, ma solo da Operator

Se un gruppo di escalation è stato portato a risolto e il raggruppamento ha smesso di funzionare, non è tutto perduto. Confermato dal supporto Conduit il 09/09/2026.
Nella pagina Escalations non esiste un bottone «riapri». È una lacuna del prodotto, non un permesso che ti manca: chi cerca il bottone conclude che non si possa fare, e si ferma. Si passa solo da Operator.
1

1 · Apri Operator nel workspace giusto

Il permesso ce l’hanno già sia il ruolo Admin sia il ruolo Member: non serve chiedere niente a nessuno.
2

2 · Chiedi di riportare gli insight a Pending

Chiedigli di rimettere in Pending gli insight di escalation risolti del workspace in cui ti trovi. Parla di insight, non di escalation: sono due oggetti diversi e solo il primo si riapre.
3

3 · Approva quando te lo chiede

Operator chiede conferma prima di applicare. È il momento in cui controlli che stia toccando il workspace giusto.
4

4 · Ripeti sull'altro workspace

Si fa uno alla volta: Operator agisce solo su quello in cui sei.
5

5 · Verifica al passaggio successivo

Tornati in Pending, il passaggio successivo del raggruppamento può riagganciarli. La prova è che tornano a comparire raggruppati, non che il comando sia andato a buon fine.
Quello che non torna indietro. Le escalation grezze chiuse via API restano fuori dal raggruppamento, per sempre. Parole del supporto: «Those stay out of grouping».È il motivo per cui la regola resta quella che è: non si cambiano stati in massa via API su escalation, gruppi, ticket, contatti o workflow. Prima di qualunque scrittura in blocco si passa dalla chat di supporto AI di Conduit.
Se il raggruppamento non si è mai visto, potrebbe non essere rotto: potrebbe non essere mai partito. Al 09/09/2026 il supporto ha dichiarato che su alcuni workspace il raggruppamento non è mai stato eseguito, mentre su altri gira regolarmente. Prima di cercare una causa nel workspace, chiedi al supporto se su quel workspace il raggruppamento sia mai partito: è una domanda da una riga che evita mezza giornata di diagnosi.
Usa questa pagina come prima tappa quando qualcosa non funziona nell’agente Conduit di uno studente. I problemi più frequenti rientrano in due categorie: errori di scope sulla KB (l’AI risponde con informazioni dell’appartamento sbagliato) e tool ignorati perché la skill abbinata è assente o mal formulata. Per la maggior parte dei casi puoi risolvere senza aprire un ticket al supporto Conduit, segui la colonna “Soluzione” nell’ordine indicato.
Regola di processo (Francesco, 24/09/2026): quando il dubbio è strutturale, prima si passa dalla chat di supporto Conduit.Non solo prima delle scritture in massa via API (regola già in vigore, vedi sotto): ogni volta che il dubbio va oltre la nostra soluzione del momento — cioè riguarda come funziona davvero la piattaforma Conduit, non solo come aggirare un sintomo — si passa prima dalla chat di supporto AI dentro Conduit, prima di decidere la soluzione finale. Risponde in minuti, non consuma crediti, e spesso dà chiarimenti che cambiano la diagnosi (vedi il caso del raggruppamento escalation “mai partito” sotto: senza chiederlo, si sarebbe cercata una causa che non esisteva).In pratica: se stai per applicare un fix basandoti su un’ipotesi su come Conduit è fatto — non su un log letto e verificato — quella è la definizione di dubbio strutturale. Chiedilo prima.

​
Tabella sintomo → causa → soluzione

​
Bug noti

Comportamento: metti un listing su isActive: false e l’assistente continua a rispondere agli ospiti che ci prenotano, in autopilot, come se niente fosse. Confermato da Conduit: il trigger dell’agente è su tutta la inbox del canale, non per listing, quindi isActive: false non lo stacca. Riprodotto su un workspace: un listing disattivato ha ricevuto tre risposte automatiche in quattro giorni.Due limiti strutturali che restano anche dopo il fix vero (sotto): (1) se il PMS collegato continua a mandare le prenotazioni di quel listing (es. non l’hai anche delistato lì), il sync in Conduit continua comunque — disattivare in Conduit non lo filtra a monte; (2) qualunque fix per listing copre solo le conversazioni legate a una prenotazione (Airbnb, Booking.com, PMS). Un ospite che scrive su un canale diretto (WhatsApp, SMS, email) non è associato a nessun listing e resta scoperto da qualunque toggle.Fix vero: ogni listing ha un interruttore AI dedicato in Settings → Listings, separato dallo stato Active/Inactive. Su un listing Inactive questo interruttore è disabilitato (non editabile): va riattivato, spento l’interruttore AI, verificato che sia spento, poi ridisattivato. Active conta ai fini della fatturazione per-listing: tieni la finestra di riattivazione la più corta possibile, e verifica lo stato finale di ogni listing (Inactive e AI off) prima di passare al successivo — non fidarti dell’esito dell’azione, rileggi.Non è raggiungibile via API/MCP. Il tool set_listing_active (attiva/disattiva un listing, con anteprima dry_run e log d’uso) esiste nell’MCP Conduit, ma non esiste nessun tool separato per l’interruttore AI per-listing: va fatto a mano, nel pannello Conduit, da chi ha accesso admin al workspace.Tampone nel frattempo (via MCP, reversibile): aggiungi un guardrail sull’agente coinvolto con l’elenco esplicito dei listing_id disattivati — «se la conversazione riguarda uno di questi listing, non rispondere, passa a una persona» — con create_agent_guardrail / patch_agent_guardrail. Copre Airbnb/Booking/PMS, non i canali diretti. Non sostituisce il fix vero, e se scopri altri listing disattivati dopo aver già messo il tampone, l’elenco nel guardrail va aggiornato: non si estende da solo.Controlla sempre anche la fatturazione, per QUALUNQUE studente, non solo per questo caso. Un listing disattivato ma ancora “attaccato” all’AI spesso continua a contare nei billed_units del workspace (conduit_workspace_config su Supabase, progetto achiwzbnbnmttvaijjzy) anche quando non dovrebbe. Confronta billed_units con il numero di listing realmente attivi (list_listings, filtro active:true): se non coincidono, non correggerlo tu — non è raggiungibile via API/MCP e tocca soldi/carta dello studente. Segnalalo a chi decide la fatturazione (oggi: platform-mattone / Francesco) con i due numeri e la data in cui li hai letti. Aggiorna anche la scheda dello studente in mattone-delivery-private/studenti/<nome>.md con lo stato trovato: è lì che il prossimo che lavora sul suo caso guarda per primo, prima di rifare la stessa diagnosi da zero.
Comportamento: quando modifichi un articolo KB esistente e salvi, la UI mostra un feedback positivo ma le modifiche non vengono persistite. L’articolo rimane con il contenuto originale.Workaround: non aggiornare articoli esistenti. Crea sempre un nuovo articolo con il contenuto aggiornato e archivia o elimina il vecchio. Apri un ticket al supporto Conduit includendo workspace ID e nome dell’articolo per tracciare il bug.
Comportamento: il passaggio settimanale che raggruppa le escalation in cluster (tab Pending della pagina Escalations) aggiunge i pattern nuovi solo ai gruppi ancora Pending. Se tutti i gruppi di un workspace vengono risolti (per esempio con un batch via API), ogni pattern nuovo viene abbinato a un gruppo Resolved e scartato: la pagina resta vuota per sempre anche se le escalation continuano ad arrivare. Le escalation grezze risolte via API vengono escluse dal raggruppamento da quel momento in poi. Confermato da Conduit il 07/09/2026: non c’è un controllo nella UI per riportare un gruppo a Pending, serve il loro engineering, senza data.Regola: non risolvere mai escalation o gruppi in massa via API, neanche per «pulire». In Conduit si chiude una escalation alla volta, dalla UI, chi l’ha lavorata. Lo stato «gestita» per il team si tiene in Notion o Slack, non cambiando lo stato in Conduit.Come si leggono le escalation vere quando la pagina è vuota: dall’API, con list_escalations (stato pending, ultimi 7 giorni, raggruppate per conversazione) e list_tickets con waiting_on=team. Prima il rischio (acqua, gas, porta, sicurezza, rimborsi), poi l’età.Prima di cambiare in massa qualunque stato via API (escalation, ticket, contatti, workflow): chiedi alla chat di supporto AI dentro Conduit cosa dipende da quello stato. Risponde in minuti e non consuma crediti; il ticket al supporto umano solo se l’AI non sa.
Sintomo: un ospite scrive di una prenotazione che ha in programma fra qualche settimana, o che ha appena cancellato. L’assistente risponde di aver trovato informazioni in conflitto e passa la conversazione a una persona, senza dare nessuna risposta utile. Cercando la prenotazione, l’assistente non la trova né per nome né per codice — mentre il gestionale ce l’ha, regolarmente registrata.Causa: lo strumento con cui l’assistente verifica le prenotazioni guarda solo le prossime due settimane e gli ospiti attualmente in casa. Tutto quello che sta più avanti nel tempo, e tutto quello che è già stato cancellato, per lo strumento non esiste. L’assistente si trova quindi con la conversazione che parla di una prenotazione e lo strumento che dice «nessuna corrispondenza»: legge le due cose come un conflitto e chiama una persona. Misurato in produzione l’08/09/2026 su una prenotazione con arrivo fra due mesi, poi cancellata.Cosa NON fare: non rigenerare le credenziali del gestionale e non rifare il collegamento. Non è quello — nel caso misurato il gestionale rispondeva correttamente con i suoi alloggi e le sue prenotazioni — e ci si perde mezza giornata, con il rischio di rompere un collegamento che funziona.Come verificarlo in trenta secondi: chiedi all’assistente lo stato di una prenotazione in arrivo nei prossimi giorni (deve trovarla) e poi di una oltre il mese (non la trova). Se l’unica differenza fra le due è la data, è questo bug e non un problema di collegamento.Cosa fare intanto: rispondi a mano. Apri la prenotazione nel gestionale, o nel canale da cui è arrivata, e di’ all’ospite quello che vedi lì — date, stato, eventuale cancellazione e rimborso.Stato: correzione in corso. La ricerca passa a una finestra ampia e le prenotazioni cancellate verranno restituite con il loro stato, così l’assistente può dirlo all’ospite invece di escalare.

​
Quando aprire un ticket al supporto Conduit

Per problemi non presenti in questa tabella o per bug Conduit confermati, apri un ticket al supporto Conduit includendo obbligatoriamente:
  • Workspace ID dello studente
  • listing_id dell’appartamento coinvolto
  • Timestamp della conversazione o dell’evento anomalo
  • Log della conversazione (screenshot o export)
Senza questi dati il supporto Conduit non può diagnosticare il problema. Raccoglili prima di aprire il ticket.
Prima di aprire un ticket, controlla sempre se il problema è nella tabella sopra e se il workaround risolve il caso. Il supporto Conduit ha tempi di risposta variabili, risolvere in autonomia quando possibile evita blocchi operativi durante l’onboarding.
▷ Prompt Claude Code: Debug Conduit · incolla in Claude Code:

Metodo troubleshooting

Le 5 mosse

Custom tools (regola tool↔skill)

Perché ripiega sul nativo