Skip to main content
I workflow Conduit (workflowsV2) sono grafi di step deterministici: a differenza dell’agente AI, che ragiona e decide autonomamente, un workflow esegue sempre la stessa sequenza di azioni quando viene attivato dal suo trigger. Questo li rende lo strumento giusto per le automazioni ripetibili dove il comportamento deve essere prevedibile e verificabile: conferma del late check-out, upsell di servizi extra, reminder per il portale check-in non completato. I workflow possono invocare i custom tool già montati sul workspace e inviare notifiche su Slack.

​
Struttura di un workflow

Ogni workflow è composto da quattro elementi fondamentali. Comprenderli è indispensabile per diagnosticare i problemi quando un workflow non si attiva o si comporta in modo inatteso.

​
Come si creano

I workflow possono essere creati in due modi equivalenti:
  • Via MCP (create_workflow): il team usa il tool MCP per creare o aggiornare workflow programmaticamente. Questo è il metodo preferito durante l’onboarding perché è riproducibile e documentabile.
  • Via dashboard Conduit: interfaccia visuale per creare e modificare workflow step per step. Utile per modifiche puntuali o per ispezionare un workflow esistente.
I workflow sono iniettabili agli studenti dalla piattaforma (come la KB bridge): il team può distribuire lo stesso workflow a più workspace studente senza riconfigurare da zero. I workflow attivi sono gestibili dalla dashboard Conduit del workspace.

​
Workflow tipici

Questi sono i workflow più frequentemente configurati durante l’onboarding. Usali come riferimento per la configurazione.
Trigger: richiesta ospite di posticipare il check-out (AI_TRIGGER o keyword)
  1. Chiama check-availability per verificare se lo slot post-checkout è libero
  2. Se disponibile: consulta la KB del listino per recuperare la tariffa late check-out
  3. Chiama stripe-payment-link con l’importo corretto e invia il link all’ospite
  4. Alla conferma del pagamento: invia SEND_SLACK_MESSAGE al canale pulizie con il nuovo orario
Se lo slot non è disponibile, il workflow risponde all’ospite che il late check-out non è possibile per quella data.
Trigger: richiesta ospite di anticipare il check-in (AI_TRIGGER o keyword)
  1. Chiama check-availability per verificare se lo slot pre-checkin è libero
  2. Se disponibile: recupera la tariffa early check-in dalla KB
  3. Genera il link Stripe e invia all’ospite
  4. Notifica il team pulizie tramite SEND_SLACK_MESSAGE con il nuovo orario di arrivo
Stesso pattern del late check-out, con trigger e parametri adattati.
Trigger: richiesta ospite di un servizio extra (parcheggio, kit bebè, late checkout, ecc.)
  1. Identifica il servizio richiesto tramite AI_TRIGGER
  2. Consulta la KB del listino dello studente (filtrata per listing_id) per trovare prezzo e disponibilità
  3. Genera il link Stripe con l’importo corretto
  4. Invia il link all’ospite con un messaggio di conferma
Trigger: pianificato, X ore prima del check-in della prenotazione
  1. Chiama check-portal-status per verificare se il portale check-in è completato
  2. Se non completato: invia un messaggio di reminder all’ospite con il link al portale
  3. Se ancora non completato a Y ore dal check-in: invia un secondo reminder e notifica lo studente via Slack tramite SEND_SLACK_MESSAGE
Questo workflow riduce drasticamente i check-in bloccati per portale non completato.
Per i casi operativi dettagliati su late check-in/out e upsell, vedi le Casistiche. Per domande sullo schema tecnico dei workflow, apri un ticket al supporto Conduit.