TyreFlow — Dall'ispezione all'offerta approvata

In breve

TyreFlow è stato costruito per il Casablanca AI Lab di DaiL durante l'Octopus day, con un vincolo di sei ore e partendo da una sessione di discovery con il cliente anziché da una specifica. Un'officina ispeziona ruote che ha già in deposito; l'osservazione utile — questi pneumatici sono consumati — deve diventare una conversazione con il cliente prima del suo prossimo appuntamento, e spesso non lo diventa.

Il progetto è arrivato 2º. La parte che difenderei con più convinzione non è una funzionalità che il software aggiunge: è una cosa che si rifiuta di fare.

Il problema

Il brief partiva dal fatto che i tecnici ispezionano ruote in deposito e che l'informazione non arriva al coordinatore in tempo. La discovery ha corretto due cose.

Primo: il problema non era né l'ispezione né l'offerta, era il passaggio di consegne. La nota resta da qualche parte dove il coordinatore non la vede finché non è troppo tardi.

Secondo, e più utile: il caso principale è asincrono. Io avevo dato per scontato un cliente in piedi in officina; la risposta del cliente è stata che le ruote sono in deposito e il cliente non c'è. Non esiste un momento di ritiro in cui intercettarlo — l'unica vera scadenza è il suo prossimo appuntamento. Quella sola correzione ha cambiato la forma del prodotto, ed è emersa solo perché la sessione era una conversazione e non un elenco di requisiti.

Il terzo punto, senza ambiguità: una persona con nome e cognome approva ogni singola offerta, compresi i casi puliti. Niente «abbastanza affidabile da inviare da solo».

Architettura

Ogni percorso da un'ispezione a un cliente passa dal blocco sulle scorte e da un'approvazione umana. Non esiste una scorciatoia.

Una coda di lavoro per il coordinatore, e sotto una regola: nessuna offerta viene mai inviata per uno pneumatico che l'officina non può fornire.

Classificazione. Ogni treno di ruote diventa esattamente uno fra bozza di offerta, attività da verificare e nessuna azione — mai più di uno — ordinato per urgenza in base ai giorni che mancano all'appuntamento, con un peso maggiore per le schede incomplete e le scorte non confermate. Un'attività da verificare elenca tutti i motivi applicabili in una volta invece di ridurli a una sola etichetta, perché «misura sconosciuta» e «contatto irraggiungibile» sono due lavori diversi.
Le prove prima della proposta. La scheda mostra sempre che cosa il tecnico ha realmente registrato prima di mostrare qualsiasi bozza di offerta. L'approvazione non è mai un'ipotesi.
Il blocco sulle scorte. Finché la disponibilità non è confermata, Approva è disattivato. Il coordinatore segnala invece la misura a una bacheca scorte; confermare quella misura sblocca automaticamente il contatto e riporta a galla ogni scheda rifiutata esattamente per quel motivo.
Approvazione umana, sempre. Approvare, approvare in blocco e recuperare una scheda rifiutata sono tutti click espliciti.
Bozze in 3 lingue × 4 canali — francese, darija e inglese su WhatsApp, SMS, email e chiamata, da modelli modificabili con un prezzo aggiornato.

Tutto gira su dati sintetici, e ogni invio simulato è etichettato «simulato — non inviato» nell'interfaccia stessa, non solo nel README.

Decisioni e compromessi

Il blocco sulle scorte è diventato rigido, non un avviso

Il requisito iniziale permetteva di inviare un'offerta con scorte non confermate usando formule caute. Quando il cliente ha detto «assicuratevi che non possiamo contattare i clienti se le scorte non ci sono», ho rimosso del tutto quel percorso invece di rendere l'avviso più visibile.

È la decisione che difenderei per prima. Un avviso delega la regola a chi è stanco alle cinque del pomeriggio; un pulsante disattivato la applica. Il costo è reale — un coordinatore certo che la merce ci sia comunque non può procedere — ed è il percorso di recupero a renderlo accettabile: segnalare la misura alla bacheca è un click, e confermarla sblocca tutto ciò che era in attesa, comprese le schede già rifiutate per quel motivo. Le formule caute ora coprono solo il caso davvero ambiguo: disponibilità confermata, ma unità insufficienti.

Rifiutare una scheda ha smesso di essere un vicolo cieco

All'inizio il rifiuto faceva sparire il problema dalla vista — il che va benissimo finché il motivo del blocco non decade e nessuno pensa più a ricontrollare. Il cestino dei rifiuti non cancella mai, ed è legato al promemoria che scatta quando viene confermata esattamente la misura che bloccava. Chiude il cerchio che il blocco apre; senza di esso il blocco sarebbe solo un modo per perdere lavoro in silenzio.

Un pulsante demo «inietta un evento» è stato cancellato

Il brief avvertiva che un'animazione scriptata non è la prova che un agente abbia compiuto un'azione, e il mio primo prototipo conteneva esattamente questo: un pulsante che simulava l'arrivo di un'informazione. L'ho sostituito con una riclassificazione innescata da azioni che fanno parte del flusso di lavoro reale — confermare le scorte, registrare un'ispezione. La demo è meno fluida e dimostra molto di più. Ogni cambio di stato nel prototipo è calcolato dallo stato reale dei componenti; le uniche animazioni sono transizioni che seguono un cambio di stato invece di sostituirsi a esso.

Un 80/20 esplicito su cosa costruire in sei ore

In sei ore il numero di funzionalità è la funzione obiettivo sbagliata. Ho stimato che il ritardo nel passaggio di consegne causasse la maggior parte delle occasioni perse: quindi il 20% portante — prove visibili, blocco sulle scorte, un passaggio di approvazione non aggirabile — si è preso il tempo di sviluppo. Il cambio di lingua, i modelli modificabili e il canale telefonico sono arrivati dopo, non prima. È quest'ordine che ha permesso alla demo di reggere le domande invece di sopravvivere solo al percorso ideale.

Cosa è stato difficile

Distinguere, dal vivo e con il cronometro, ciò che il cliente diceva di volere da ciò che la situazione richiedeva davvero. Il caso «il cliente è in officina» sembrava ovvio ed era sbagliato — è il loro caso secondario, e costruirlo per primo avrebbe prodotto uno strumento per un momento che per lo più non si verifica. C'è ancora, con un avviso urgente dal tono distinto, ma come il bonus che è.

Il resto è stato debugging onesto sotto pressione. I test hanno fatto emergere due bug veri negli avvisi: il suono partiva per il tecnico invece che per il coordinatore, e cambiare ruolo distruggeva proprio i dati di cui l'avviso parlava. Entrambi sono corretti a livello di store. Preferisco nominarli piuttosto che presentare sei ore di lavoro come se fossero filate lisce.

Risultato

2º posto, e un prototipo online — non un mazzo di slide — al termine di sei ore. Rilasciato con uno stato di partenza ripetibile (un reset che ripristina esattamente i dati iniziali, senza deriva né casualità), documentazione che separa il reale dal simulato, e un handoff tecnico che copre la prossima integrazione, gli accessi, il responsabile e il rischio irrisolto.

Quello che me ne porto dietro: la discovery è lavoro di ingegneria. La cosa più utile che ho costruito quel giorno è un pulsante disattivato, e dal brief scritto non l'avrei mai dedotto.

I prossimi passi

Il vero passo successivo non è una funzionalità, è un test di validazione: mettere la coda davanti a un coordinatore vero per una settimana e misurare se le ispezioni diventano davvero conversazioni prima dell'appuntamento successivo. Tutto il resto — integrazioni di messaggistica reali, un backend persistente al posto di uno stato precaricato, un'autenticazione degna del nome — è semplice una volta che quel numero esiste e conferma che il meccanismo funziona.