Casi d'uso
Costruisci workflow di approvazione con ingegneria assistita da AI
Trasforma le approvazioni a thread email in un sistema: richieste tipizzate, instradamento per soglia, delega, escalation — e un registro che regge quando l'audit chiede conto.
Ciao è una piattaforma di ingegneria assistita da AI enterprise per costruire workflow di approvazione — applicazioni che accolgono richieste tipizzate, le instradano secondo regole come soglie d'importo e reparto, raccolgono le decisioni e registrano tutto in un log append-only. A differenza delle approvazioni gestite via email, ogni decisione ha un approvatore, un timestamp e la versione esatta revisionata. Le stesse modifiche al workflow passano attraverso revisione Guardrails, QA automatizzato e test di sicurezza prima del merge.
Pubblicato 2026-07-03 · Ultimo aggiornamento 2026-07-03
Le approvazioni sono un sistema, non una risposta
Un workflow di approvazione fa quattro cose: accoglie una richiesta, la instrada alle persone giuste, raccoglie una decisione, e registra tutto. La maggior parte delle aziende gestisce questo via email — dove una risposta "mi sembra a posto" è il controllo. Nessuno può dire in seguito quale versione è stata approvata, se la policy di soglia è stata applicata, o perché una richiesta è rimasta nove giorni nella casella di posta di qualcuno mentre era in ferie.
Il divario diventa costoso al momento dell'audit. I revisori fanno tre domande: chi ha approvato questo, cosa hanno visto esattamente, ed è stata applicata la policy dichiarata? L'email non risponde in modo affidabile a nessuna di esse. Non lo fanno nemmeno i thread di chat, e non lo fa nemmeno un foglio di calcolo con una colonna "approvato?".
Ciao costruisce i workflow di approvazione come vere applicazioni: moduli di richiesta tipizzati, regole di instradamento scritte nel codice, delega ed escalation che gestiscono calendari reali, e un registro append-only di ogni decisione. La stessa disciplina si applica al workflow stesso — cambiare una regola di instradamento o una soglia è una modifica di codice governata con revisione registrata, non una modifica silenziosa.
Cosa richiede davvero un workflow di approvazione
- Moduli di richiesta tipizzati — Le richieste di spesa, accesso, contratto ed eccezione catturano ciascuna i campi di cui la decisione ha davvero bisogno — validati all'inserimento.
- Regole di instradamento — Per soglia d'importo, reparto, centro di costo, regione o ruolo — deterministiche, versionate e leggibili in caso di contestazione.
- Catene multi-passaggio — Approvatori sequenziali, approvatori paralleli, e regole di quorum per le decisioni che richiedono più di una firma.
- Delega e assenza dall'ufficio — Le approvazioni si re-instradano quando qualcuno è assente — con la delega stessa a registro.
- Timer SLA ed escalation — Le richieste che restano ferme troppo a lungo fanno escalation automaticamente; la reportistica sui tempi di ciclo mostra dove le cose si bloccano.
- Contesto sulla richiesta — Commenti, allegati e record collegati vivono sulla richiesta, così l'approvatore decide sulla base di prove, non della memoria.
- Un log di decisioni append-only — Chi ha approvato cosa, quando, e la versione esatta che ha visto — immutabile, esportabile, verificabile.
- Azioni all'approvazione — Integrazioni che creano l'ordine d'acquisto, provisionano l'accesso o aggiornano l'ERP una volta presa la decisione — chiudendo il ciclo.
Come funziona una build di workflow di approvazione su Ciao
1. Metti la policy per iscritto
"Le spese sotto 1.000 hanno bisogno di un manager; sopra 10.000 si aggiunge la finanza; i nuovi fornitori aggiungono sempre il procurement." Le regole, enunciate chiaramente, diventano la specifica.
2. Genera moduli e instradamento
Tipi di richiesta, campi, ruoli e instradamento atterrano come schema Supabase e codice di instradamento leggibile.
3. Gestisci il calendario umano
Delega, regole di assenza, timer di escalation e cadenza dei promemoria — le parti che l'email non ha mai gestito.
4. Collega le conseguenze
Le richieste approvate agiscono: un ordine d'acquisto nell'ERP, accesso provisionato nei sistemi IT, un contratto spostato alla firma — tramite integrazioni controllate.
5. Testa decisioni e confini
QA riproduce catene di approvazione, casi limite di soglia e confini di permesso — inclusi i percorsi in cui qualcuno tenta di approvare la propria richiesta.
6. Governa le regole stesse
Il codice di instradamento e soglia è un'area protetta di Guardrails: policy in linguaggio semplice, rilevamento del rischio, revisione umana registrata su ogni modifica.
7. Distribuisci e riporta
Rilascia sul tuo cloud, in VPC privata o on-prem. La reportistica su tempi di ciclo e colli di bottiglia arriva dagli stessi dati.
Checklist di sicurezza e governance
- ✓ I richiedenti non possono approvare le proprie richieste — applicato e testato
- ✓ Separazione dei compiti mappata in livelli di ruolo nel backend
- ✓ Log di decisioni append-only con approvatore, timestamp e versione revisionata
- ✓ Le modifiche alle regole di instradamento e alle soglie richiedono revisione Guardrails registrata
- ✓ SSO tramite SAML o OIDC; i link di approvazione autenticano, non aggirano mai
- ✓ Le sonde di controllo degli accessi girano sull'app live prima che una segnalazione sia considerata attendibile
- ✓ Deleghe ed escalation registrate insieme alle decisioni
- ✓ Deploy in VPC privata o on-prem dove la policy lo richiede
Varianti di workflow di approvazione
Approvazioni di spesa
Richieste instradate per importo e centro di costo, con il contesto di budget sulla richiesta e un ordine d'acquisto creato all'approvazione.
Approvazioni di contratto
Firma legale, finanziaria e di business in sequenza, con la versione esatta del documento bloccata a ogni decisione.
Richieste di accesso IT
Richieste di accesso basate sui ruoli con approvazione del proprietario, concessioni a tempo determinato e una traccia di revisione per la ricertificazione.
Approvazioni di marchio e campagna
Revisione creativa con asset versionati, commenti di markup e un registro di chi ha dato il via libera a cosa per il lancio.
Richieste di assunzione
Richieste di organico instradate attraverso manager, finanza e HR, legate a regole di budget e livello.
Registro delle eccezioni di policy
Eccezioni richieste, giustificate, limitate nel tempo e approvate — con promemoria di scadenza invece di eccezioni permanenti e silenziose.
Requisiti di approvazione, coperti
| Requisito | Come lo copre Ciao |
|---|---|
| L'approvatore giusto ogni volta | Regole di instradamento deterministiche versionate in codice leggibile |
| Le assenze non bloccano le richieste | Delega, re-instradamento per assenza ed escalation SLA |
| Prove di audit | Log append-only: approvatore, timestamp, versione esatta revisionata |
| Nessuna auto-approvazione | Separazione dei ruoli applicata nel backend e testata nei replay QA |
| Le decisioni causano azioni | Le integrazioni creano ordini d'acquisto, provisionano accesso, aggiornano i sistemi di record |
| Le modifiche alle regole sono controllate | Revisione Guardrails registrata prima che le modifiche a instradamento o soglie vengano unite |
| Ambienti ristretti | Opzioni di deploy sul proprio cloud, VPC privata o on-prem |
Domande frequenti
Come impediamo a qualcuno di approvare la propria richiesta?
La separazione dei ruoli è applicata nel backend — il motore di instradamento esclude il richiedente dalla propria catena — e i replay QA includono il tentativo di auto-approvazione come caso di fallimento testato. Le sonde di controllo degli accessi confermano il confine sull'app live.
Cosa ottengono davvero i revisori?
Un log append-only per richiesta: richiedente, approvatori, timestamp, la versione esatta che ogni approvatore ha visto, commenti e allegati. Sul lato ingegneria, il registro di controllo copre anche chi ha cambiato le regole del workflow stesso e chi ha revisionato quella modifica.
Gli utenti di business possono cambiare le regole di instradamento in sicurezza?
Le modifiche alle regole vengono descritte in linguaggio semplice ma vengono rilasciate come modifiche di codice governate: Guardrails rileva che una soglia o una regola di instradamento è cambiata, applica le tue policy in linguaggio semplice e registra la revisione umana prima del merge. La modifica è veloce — e a registro.
Le approvazioni possono innescare azioni nei nostri sistemi ERP o IT?
Sì. Le richieste approvate possono creare ordini d'acquisto, provisionare accesso o aggiornare record tramite integrazioni controllate, e le sandbox personalizzate permettono a quel lavoro di integrazione di avvenire contro backend Rails, Java, Go, Python e Node.
Questo può girare dentro il nostro perimetro di rete?
Sì — il tuo account AWS, Azure o GCP, una VPC privata, o on-prem con termini separati, con SSO tramite SAML o OIDC e MFA opzionale.
Quanto costa?
I workflow di approvazione sono di solito parte di un programma di governance più ampio piuttosto che un'unica app. I programmi di sviluppo seri partono da 10.000 USD all'anno; le vendite possono dimensionare il tuo panorama di approvazioni — spese, accessi, contratti — in un'unica conversazione.