Skill DevOps per l'automazione di processi aziendali

Un cliente ci ha mostrato l'onboarding di un nuovo tenant. Sette passaggi. Tutti a mano.

Qualcuno crea l'ambiente. Qualcun altro punta il DNS. Poi il CRM, il billing, la mail al team, il primo deploy, la welcome email. Ogni passaggio ha un responsabile diverso. Ogni responsabile ha un giorno diverso. Se uno si ferma, la catena aspetta.

Non era un problema di «mancanza di AI». Era un processo che nessuno aveva scritto fino in fondo. Stava in chat, in checklist e nella testa di due persone.

Abbiamo messo quel processo in una skill. Una procedura leggibile da un operatore e eseguibile da un agente. Quattro minuti. Stessa catena. Zero passaggi saltati.

Su ottanta onboarding reali: zero errori, meno 94% di tempo operazionale, traccia completa su git. Non è magia. È un processo che finalmente esiste in un posto solo.

Cosa intendiamo per skill

Una skill non è un prompt lungo salvato in un documento. È un comportamento versionato.

Ha un nome. Ha un input chiaro. Ha dei passi. Ha un esito verificabile. Se cambia, il cambio sta in una diff. Chi l'ha cambiata si vede. Quando si è rotta si torna indietro.

Per un operatore è una procedura. Per un agente è codice. Per l'azienda è la stessa cosa vista da due lati.

Questo è il punto che perdiamo quando parliamo solo di sviluppatori. Il valore non è «l'AI scrive script». Il valore è che la procedura smette di vivere in una persona.

I sette passaggi, senza teatro

Provisioning: ambiente, permessi, nome del tenant. Se manca un campo, la skill si ferma. Non inventa.

DNS: record, attesa, verifica. Se il record non risolve, non si va avanti. L'errore resta nel log.

CRM: anagrafica, owner, stato. Niente duplicati creati «per sicurezza».

Billing: piano, data di avvio, riferimento interno. Se il piano non esiste, stop.

Notifica al team: chi deve sapere, in quale canale, con quale link. Una volta. Non tre messaggi diversi.

Primo deploy: la versione concordata, non «quella che c'era sulla macchina di ieri».

Welcome email: testo versionato, non copiaincolla da un thread di sei mesi fa.

Ognuno di questi passi esisteva già. Il costo stava nel passaggio di mano. L'agente non è più intelligente del team. È più costante.

Perché git e non un foglio

Un foglio si aggiorna. Poi qualcuno lavora sulla copia sbagliata. Poi il foglio e il reale divergono.

Git è noioso e va bene così. Ogni esecuzione lascia una traccia. Ogni modifica alla procedura è una revisione. Se l'onboarding di marzo è diverso da quello di aprile, si vede perché.

Quando un cliente chiede «chi ha creato questo tenant», la risposta non è una riunione. È un commit e un log.

Per un auditor interno è la differenza tra «ci fidiamo delle persone» e «possiamo dimostrarlo».

Dove funziona, dove no

Funziona su processi ripetitivi, con esito sì/no, con sistemi che hanno un'API o almeno un passaggio automatizzabile. Onboarding. Offboarding. Apertura di un punto vendita. Generazione di un ambiente di staging. Invio di un kit di benvenuto. Rinnovo di un certificato.

Non funziona sul lavoro che è giudizio. Una trattativa. Una decisione di credito. Un conflitto tra due team. Lì l'agente può preparare il dossier. Non deve chiudere.

Il test è semplice. Se lo spiegate a un collega nuovo in dieci minuti, e lui può eseguirlo, è una skill. Se ogni volta «dipende», non lo è ancora. Prima va deciso. Poi si automatizza.

Quanto costa ignorarlo

Ottanta onboarding a mano, anche a venti minuti l'uno, sono giornate intere. In realtà erano ore, perché ogni passo aspettava qualcuno. Il tempo reale era nascosto nei ritardi.

Gli errori non erano frequenti. Erano costosi. Un DNS sbagliato. Un tenant nel piano sbagliato. Una welcome email partita verso l'indirizzo interno. Ognuno di questi torna come ticket, non come riga in un report.

Dopo la skill, il tempo è quattro minuti e il ticket di quel tipo è sparito. Il team non è stato sostituito. Ha smesso di fare il lavoro che odiava e in cui sbagliava per noia.

Cosa chiediamo al cliente prima di scrivere la skill

Chi esegue oggi, per nome. Non «il team ops». Una persona. Poi la seconda se la prima è in ferie. Se questa risposta non c'è, il processo non è di nessuno. L'agente non può ereditarlo.

Quale sistema è la fonte di verità per ogni passo. Il CRM, il DNS, il billing. Uno. Se due sistemi dicono due cose diverse sul tenant, la skill si ferma. Non «sincronizza in qualche modo».

Qual è l'esito che un umano può spuntare in dieci secondi. Tenant raggiungibile. Mail partita. Piano corretto. Se l'esito è «il cliente è contento», non è ancora un processo. È un obiettivo. Si spezza.

Quanto può sbagliare prima che costi caro. Un DNS sbagliato per un'ora è un tipo di danno. Un piano di billing sbagliato per un mese è un altro. La skill deve sapere dove fermarsi e chiamare una persona. Non dove «provare comunque».

Queste quattro risposte stanno in una pagina. Se non stanno in una pagina, non stanno in una skill.

Il giorno dopo i quattro minuti

L'onboarding veloce sposta il lavoro. Il team smette di copiare campi. Inizia a gestire le eccezioni: un tenant con un dominio già preso, un piano custom, un legale che chiede una clausola. Va bene. È lavoro umano.

Serve un canale per quelle eccezioni. Non una skill che le ingoia. Un ticket, un owner, un ritorno nella procedura solo quando l'eccezione è diventata regola. Tre volte la stessa eccezione: si scrive il passo. Una volta: si lascia all'umano.

Misuriamo ancora. Tempo, errori, eccezioni per settimana. Se le eccezioni crescono, la skill non è «da migliorare con più AI». Il prodotto o il commerciale sta vendendo troppe varianti. Si torna lì.

Come partire da un solo processo

Non fate la mappa di tutta l'azienda. Prendete il processo che si ripete ogni settimana e che oggi vive in una checklist. Scrivetelo in passi. Togliete le eccezioni finte: o sono regole, o sono rumore.

Eseguite i primi dieci a mano sulla nuova procedura, senza agente. Se i dieci non escono uguali, l'agente non vi salva. Vi moltiplica il disordine.

Quando i dieci sono uguali, l'agente esegue. Voi revisionate. Poi revisionate solo le eccezioni.

Se avete un onboarding, un rilascio o una procedura interna che oggi sta in sette chat, è una skill in attesa. La costruiamo insieme. Il codice della procedura resta vostro.