Analisi settimanale 18-24 maggio. Zona Nord-Milano: ritardi +41% vs media 12 settimane, Vettore C, pattern da 3 settimane. Fragili: danni 3,2% vs baseline 0,8% su 2 hub. Reclami: +28 vs settimana precedente sui CAP cintura Torino.
AGENTE · DELIVERY ANOMALY WATCH
Le anomalie sulle consegne emergono prima del picco di reclami.
Delivery Anomaly Watch monitora settimanalmente le consegne dell'operatore logistico e identifica pattern di anomalia: ritardi sistematici su zone specifiche, cluster di reclamo cliente, anomalie su specifici corrieri o articoli. Alert strutturato al responsabile operations per intervento proattivo, prima che i reclami si accumulino.
Delivery Anomaly Watch al lavoro.
Su Vettore C apro revisione contrattuale questa settimana. Su Firenze coinvolgo il responsabile hub per l'imballaggio. Confermato.
Decisioni registrate. Prossima analisi domenica 31 maggio.
Perché esiste.
Gli operatori logistici mid-large gestiscono migliaia di consegne al giorno. I pattern di anomalia — zone con ritardi sistematici, corrieri con tasso di reclamo elevato, articoli con incidenza di danneggiamento — sono spesso identificati solo dopo l'accumulo di reclami cliente, quando il problema è già strutturale.
Come lavora ogni settimana.
Delivery Anomaly Watch legge settimanalmente i dati di consegna: orari effettivi rispetto agli orari pianificati, esiti (consegnato, mancata consegna, danno), reclami cliente, segnalazioni di danneggiamento. Confronta con la baseline aggregata e per cluster — zona geografica, corriere, tipo di articolo — e identifica le deviazioni statisticamente significative. Per ciascuna anomalia, propone un'azione concreta.
La decisione resta al responsabile.
Il responsabile operations decide gli interventi. L'agente non modifica contratti, non riassegna spedizioni in autonomia, non apre reclami senza approvazione.
Le figure operations che passano dalla reazione alla prevenzione.
Responsabile operations logistics
Ha una visione strutturata delle anomalie di consegna ogni settimana, non solo quando i reclami superano la soglia critica. Le decisioni di intervento — revisione del corriere, cambio di processo di imballaggio, analisi di una zona problematica — arrivano basate su pattern misurati, non su segnalazioni aneddotiche.
Settimana 23 312 spedizioni
Zona Roma-Sud ritardo medio 28'
Cluster reclamo 8 ticket simili
Carrier · Y performance ok
Brief al responsabile delivery
Customer service manager
Vede la correlazione tra zone di ritardo sistematico e picchi di reclamo cliente. La comprensione dei cluster di anomalia permette di anticipare le comunicazioni proattive ai clienti prima che arrivino a reclamare.
Rotte · 06:00 42 mezzi
Tempi di guida Reg. CE 561
ZTL · centro 2 deviazioni
ADR · classe 3 route dedicata
12 minuti risparmiati per mezzo
Responsabile contratti corrieri
Dispone di dati strutturati per le revisioni contrattuali: tasso di ritardo per corriere, andamento nel tempo, confronto con la baseline. La negoziazione smette di basarsi su impressioni.
Banchina BK-4 12 slot oggi
09:30 · vettore A priorità alta
10:15 · vettore B standard
11:00 · vettore C ritardo · slittato
Tempi di attesa medi: 18'
Un'anomalia di consegna rilevata in anticipo, prima che diventi reclamo.
Il lunedì mattina, tre anomalie segnalate.
Per un operatore logistico con quattrocento consegne giornaliere su area regionale, il lunedì mattina è il momento del brief settimanale. Delivery Anomaly Watch ha processato durante il weekend i dati della settimana precedente: orari effettivi, esiti di consegna, reclami arrivati al customer service, segnalazioni di danno.
Tre cluster con pattern strutturati, non aneddotici.
Il responsabile operations apre il canale Slack e trova tre anomalie segnalate. La prima riguarda una zona periferica dove il tasso di ritardo è salito al quarantuno percento rispetto alla media storica delle ultime dodici settimane, concentrata su un singolo corriere e presente da tre settimane consecutive. La seconda riguarda articoli fragili con incidenza di danneggiamento tre volte superiore alla baseline in due hub specifici. La terza segnala un cluster di reclami su quattro CAP contigui.
Il responsabile decide. L'agente registra.
Il responsabile decide: apre revisione contrattuale con il corriere problematico, convoca il responsabile hub Firenze per analisi del processo di imballaggio, segnala al customer service i quattro CAP per comunicazione proattiva ai clienti. Le decisioni restano nel registro audit del runtime, interrogabili dal management con un client SQL standard.
Regole dichiarative del team operations del cliente.
Le regole di Delivery Anomaly Watch sono dichiarative. Il team operations logistics del cliente definisce in formato leggibile i pattern di anomalia rilevanti (es. tasso di ritardo sopra soglia per N settimane consecutive, incidenza danni oltre la percentuale configurata per categoria di articolo), le segmentazioni di analisi (per zona, per corriere, per tipo di merce), le soglie che attivano l'alert. Le regole vivono nel repository del cliente, versionate, validate all'avvio dell'agente.
- Linguaggio
- TypeScript (Node.js)
- Modello LLM
- a scelta del cliente: Anthropic, OpenAI, Mistral, modelli open source ospitati internamente, AWS Bedrock per modello privato
- Controlli built-in usati
- pii-detector, tool-rate-limit
- Canali nativi di consegna
- Slack, Telegram, WhatsApp, HTTP OpenAI-compatible
- Schedulazione
- configurabile per istanza (tipica settimanale, fine settimana o lunedì mattina)
- Integrazione TMS
- adapter dedicato realizzato in fase di delivery dal team Exelab
- Integrazione sistema reclami cliente
- adapter dedicato realizzato in fase di delivery dal team Exelab
- Memoria
- persistente per istanza, pgvector + PostgreSQL FTS
- Registro
- immutabile, interrogabile con client SQL standard
Come funziona Delivery Anomaly Watch nel dettaglio.
Il dato cardinale è la traccia delle consegne con marca temporale di pianificazione e di esito effettivo. I reclami cliente e le segnalazioni di danno completano il quadro. Il TMS del cliente è la fonte principale. L'integrazione con il TMS si realizza in fase di delivery tramite adapter dedicato; il team Exelab mappa le fonti dati disponibili in fase di discovery.
La frequenza standard è settimanale. Per operatori con volumi elevati (migliaia di consegne al giorno) è possibile configurare analisi più frequenti (bisettimanale o quotidiana per cluster ad alto rischio). La frequenza si definisce in fase di configurazione delle regole dichiarative.
L'agente valuta la persistenza temporale: un'anomalia su una zona in tre settimane consecutive è strutturalmente diversa da un ritardo singolo per un evento meteorologico. Le soglie di persistenza e di significatività statistica sono configurabili dal team operations. Gli eventi eccezionali documentati (sciopero, maltempo certificato) possono essere inseriti come eccezioni nelle regole per evitare falsi positivi.
Il pattern tipico è 10-14 settimane. Discovery e mappatura delle fonti dati due settimane, configurazione delle regole di anomalia e segmentazioni tre settimane, integrazione TMS e sistema reclami tre settimane, test su dati reali e hand-off al team operations due settimane. La durata effettiva dipende dalla disponibilità e qualità dei dati storici nel TMS del cliente.
Da una conversazione di 30 minuti alla squadra in produzione.
Una conversazione di 30-45 minuti per capire come Delivery Anomaly Watch si configurerebbe sul caso del cliente. Quale TMS, quali pattern di anomalia prioritari, quali segmentazioni.