RouteLogic
Centro di Comando RouteLogic
RouteLogic confronta il giro attuale con uno scenario ottimizzato e trasforma lo spreco operativo in evidenza misurabile.
Ottieni baseline esplicita, route solver, delta tecnico, provenienza e report verificabile. Nessuna promessa economica: solo evidenza classificata sul file caricato.
Per distributori locali, consegne food & beverage, grossisti beverage, logistica regionale e PMI con giri ricorrenti.
Console RouteLogic
La Console operativa analizza i giri caricati. Il modulo Intelligence resta futuro e non attivo in questa build.
Build locale attiva
Analisi operativa dei giri: carica CSV, misura km, verifica qualità e scarica report.
I vincoli avanzati vengono rilevati e auditati quando presenti; non tutti vengono ottimizzati globalmente in questa build.
Usa Console OperativaModulo riservato
Modulo futuro per margini, tender, brokerage e decisioni commerciali. Non attivo in questa build.
Nessuna AI commerciale, marketplace o decisione automatica viene dichiarata ora.
Vedi modulo riservato01 Sistema
Un motore locale di route analysis che confronta il giro attuale con una sequenza ottimizzata sugli stessi stop.
Lavora su file operativi reali, non su descrizioni astratte: coordinate se presenti, geocoding indirizzi dove i dati lo permettono.
Restituisce un prima/dopo misurabile, con fornitore routing dichiarato, fallback esplicito e limiti di qualità input non nascosti.
Non è consulenza generica: è un sistema che misura differenze operative su dati caricati dal potenziale cliente.
02 Problema
Molti distributori e molte PMI lavorano su giri storici costruiti per abitudine, esperienza del autista o ordinamento manuale in Excel.
Piccole inefficienze ripetute ogni giorno o ogni settimana diventano costo reale su km, tempo, carburante e margine.
Il problema spesso resta invisibile perché nessuno misura davvero la sequenza alternativa sugli stessi clienti.
Il sistema rende visibile questo margine nascosto con un confronto numerico prima/dopo, senza promettere risparmi finti o precisione che il file non consente.
Il costo operativo non sta solo nella domanda o nel numero di stop: spesso sta nell'ordine con cui vengono serviti.
Evidenza operativa: il margine perso è nella sequenza, non nel racconto del giro.
03 Workflow
Workflow concreto: carica un CSV, il sistema valida la struttura, riconosce coordinate o prova geocoding locale sugli indirizzi, calcola la distanza attuale, produce una sequenza alternativa ottimizzata e misura il delta km in modo tracciabile.
Input
CSV con coordinate o indirizzi completi abbastanza chiari da essere normalizzati.
Calcolo
Routing su rete stradale via HERE se configurato, fallback OSRM locale se disponibile e fallback geometrico solo quando necessario e dichiarato.
Output
Preview con km attuali, km ottimizzati, riduzione, qualità input e stato esecutivo del record.
04 Azione
Il file deve essere un CSV tabellare chiaro. Le coordinate reali restano la qualità migliore; gli indirizzi completi sono processabili via geocoding locale solo quando il dato è sufficientemente completo.
Apri ultima analisiRequisiti del file
Formati supportati ora: Solo CSV. Questa build locale non espone XLSX, XLS o PDF come formati supportati. Le coordinate reali restano la forma più affidabile; il geocoding degli indirizzi dipende dalla qualità e completezza del dato sorgente.
Preparazione assistita
Il caricamento automatico funziona quando il CSV è già strutturato e interpretabile. Se il file è grezzo, sporco, incompleto o non immediatamente computabile, può essere inviato per preparazione assistita. La preparazione assistita può includere controllo, pulizia e normalizzazione del file. Normalmente viene gestita entro 24–48 ore lavorative, in base alla qualità del materiale ricevuto. La preparazione assistita non garantisce sempre il recupero o la computabilità del file: l’esito dipende dalla qualità dei dati forniti.
1. Formato migliore: coordinate
CSV tabellare con nome stop, latitudine e longitudine. E' il formato piu' affidabile per calcolare subito il giro.
name,lat,lon
Deposito,42.5636,12.6427
Cliente 1,42.5700,12.6500
Cliente 2,42.5600,12.6300
Deposito Ritorno,42.5636,12.6427
name,lat,lon,stop_type
Deposito,42.5636,12.6427,depot_start
Cliente 1,42.5700,12.6500,customer
Cliente 2,42.5600,12.6300,customer
Deposito Ritorno,42.5636,12.6427,depot_end
2. Formato accettabile: indirizzi
Indirizzi completi possono essere preparati/geocodificati quando le colonne sono chiare. Il risultato dipende dalla qualita' del dato.
cliente,indirizzo,civico,comune,cap,provincia
Cliente Roma,Via Roma,12,Roma,00100,RM
Il cliente non deve controllare ogni riga: il sistema evidenzia le righe dubbie, incompleti o non risolte.
3. Formato non adatto
CSV e' l'unico formato automatico supportato ora. Excel/PDF richiedono preparazione assistita o conversione preventiva.
Regola deposito
Se il file contiene depot_start e depot_end, RouteLogic mantiene il deposito iniziale al primo posto e il rientro deposito all'ultimo posto. Vengono ricalcolati solo gli stop cliente intermedi.
Il fallback geometrico produce una stima quando il fornitore stradale non e' disponibile; non e' routing stradale.
Strumento separato
Hai un file con indirizzi ma senza latitudine e longitudine? Caricalo qui: il sistema tenterà di normalizzare gli indirizzi e convertirli in un CSV utilizzabile per una prima analisi del giro.
Il sistema tenta la conversione tramite cache locale e fornitore geocoding configurato, se disponibile. Il file generato può includere nome stop, indirizzo originale, latitudine, longitudine, stato di geocoding, livello di affidabilità e motivo di eventuale verifica.
Il sistema non ti chiede di controllare ogni singola riga: evidenzia solo gli stop dubbi, incompleti, ambigui o non risolti, così la revisione resta mirata.
Le righe risolte con buona affidabilità possono essere usate per una prima analisi operativa. Le righe dubbie, incompleti o a bassa affidabilità restano marcate per revisione mirata prima di considerarle definitive.
La qualità delle coordinate dipende dalla qualità del file sorgente. Il sistema non garantisce precisione assoluta, precisione al numero civico o risoluzione completa di ogni indirizzo.
Per file sporchi, incompleti, ambigui o critici, resta disponibile la preparazione assistita con controllo, pulizia e normalizzazione del file, normalmente entro 24–48 ore lavorative in base alla qualità del materiale ricevuto.
Formato accettato: solo CSV tabellare con header chiari. File Excel, PDF, screenshot, testo copiato o file non strutturati non vengono elaborati direttamente da questa funzione automatica.
Struttura consigliata
customer_name,street,street_number,city,postal_code,province
Equivalente italiano
cliente,indirizzo,civico,comune,cap,provincia
Città/comune, via/indirizzo e numero civico migliorano nettamente la qualità del geocoding. Più il dato è completo e coerente, più l'output è utilizzabile.
Cosa produce: il sistema tenta di leggere e normalizzare le colonne indirizzo, comporre un indirizzo strutturato, eseguire il geocoding ed esportare un CSV preparato con coordinate dove disponibili.
Il file preparato include i campi tecnici previsti dal sistema, tra cui name, original_address, normalized_address, lat, lon, geocoding_status, confidence, review_required, review_reason, resolver_mode e provider.
Revisione richiesta: il cliente non deve controllare manualmente ogni riga una per una. La revisione mirata riguarda soprattutto righe dubbie, incomplete, non risolte o marcate come da verificare. Le righe risolte con alta confidenza possono essere usate come base tecnica preparata, con normale giudizio operativo.
Limite dichiarato: il sistema non garantisce precisione assoluta delle coordinate, precisione esatta al numero civico, geocoding completo di ogni riga o computabilità automatica del file. Indirizzi ambigui, incompleti o formattati male possono richiedere preparazione assistita.
Preparazione assistita: La preparazione assistita può includere controllo, pulizia e normalizzazione del file. Normalmente viene gestita entro 24–48 ore lavorative, in base alla qualità del materiale ricevuto.
Ambito computazione corrente
RouteLogic confronta il giro attuale con una sequenza migliore sugli stessi stop e, quando il CSV contiene dati sufficienti, costruisce anche un piano VRP vincolato bounded con deposito, veicolo, capacità e finestre temporali nel perimetro supportato.
Il primo livello è l'ottimizzazione base della sequenza: confronto tra giro caricato e giro ricalcolato, km attuali, km ricalcolati e delta tecnico.
Il secondo livello è il piano vincolato bounded: quando sono presenti vehicle_id, domanda, capacità, deposito e finestre temporali, il sistema verifica o applica quei vincoli nel perimetro deterministico disponibile.
I moduli non supportati in esecuzione autonoma restano audit diagnostico: vengono rilevati e riportati, ma non diventano claim di ottimizzazione completa.
RouteLogic costruisce un piano VRP vincolato bounded quando i dati lo consentono, verifica capacità, deposito, sequenza e finestre temporali nel perimetro deterministico disponibile, segnala violazioni e dati mancanti, e non dichiara ottimo globale matematico salvo futura certificazione exact separata.
Supporto vincoli
Ottimizzazione base sequenza: supportata nella computazione corrente.
Finestre orarie: audit/enforcement sulla sequenza caricata quando tw_start/tw_end sono presenti; ottimizzazione VRPTW globale non dichiarata.
Multi-depot: validazione/reporting attivi su depot, assegnazioni, coordinate e capacità quando i dati sono presenti; ottimizzazione globale completa di assegnazione multi-deposito non dichiarata.
Capacita / carico: enforced quando domanda e capacità utilizzabile sono presenti; violazioni e dati insufficienti vengono riportati senza inventare assegnazioni.
Flotta eterogenea: profiling flotta, vehicle_id grouping, capacità differenziate e assegnazione bounded dove i dati sono sufficienti; fleet optimization globale non dichiarata.
Ritiro-consegna: relazioni rilevate e controllate dove possibile; precedenza ritiro-prima-della-consegna non dichiarata come vincolo motore pienamente applicato.
I campi avanzati non vengono scartati: vengono rilevati, controllati dove possibile, salvati nel record, mostrati nel report ed esportati per auditabilità e futura enforcement del solver.
05 Motore VRP
Il giro caricato viene trattato come baseline operativa reale. Il motore confronta quell'ordine con sequenze alternative sugli stessi stop, dentro un ciclo di calcolo controllato.
Il motore non si limita a una singola stima. Entro un limite di tempo controllato esplora più configurazioni del giro, confronta sequenze alternative e conserva il miglior risultato trovato nel ciclo di calcolo.
La logica include esplorazione multi-start, ricerca entro un limite di tempo e operatori di miglioramento locale. Il risultato mostrato è il miglior risultato trovato in quella sessione, non una promessa di ottimo matematico globale.
Questo consente un confronto numerico verificabile tra baseline esplicita e route solver: stessa domanda, stessi stop, stessa matrice validata, sequenza diversa.
06 Routing
Quando HERE è configurato, il sistema lo usa come fornitore primario tramite bridge; se non disponibile passa a OSRM locale e poi al fallback geometrico dichiarato.
OSRM utilizza il grafo stradale disponibile e un profilo di routing configurato: quando i dati cartografici sono presenti e corretti, il calcolo può tenere conto di vincoli codificati come sensi unici, accessi stradali, svolte consentite o vietate, geometria della rete e percorribilità secondo il profilo impostato.
La qualità del routing stradale dipende dalla qualità del dataset cartografico, dal profilo usato e dalle restrizioni effettivamente presenti nei dati.
Se il provider OSRM non è disponibile, il sistema può degradare in modalità geometrica controllata. Questa modalità viene dichiarata nel record e non viene presentata come equivalente al routing stradale.
Fornitore usato, modalità di routing, fallback applicato e motivo del fallback restano tracciati in anteprima, dettaglio, centro di comando ed esportazioni.
07 Upgrade
La anteprima locale base usa HERE quando configurato, OSRM locale come fallback quando disponibile e fallback geometrico dichiarato quando necessario.
OSRM lavora sul routing stradale locale disponibile nel dataset; HERE, come modulo premium futuro, può aggiungere un livello dinamico legato a traffico, eventi stradali e condizioni operative aggiornate, dove disponibili dal fornitore.
Un eventuale modulo premium/futuro può integrare servizi HERE Technologies per aumentare l'aderenza operativa con segnali su traffico, chiusure, incidenti, lavori stradali, congestione, limitazioni di accesso e altri eventi stradali dove disponibili.
Questo livello può modificare priorità e sequenze, evidenziare criticità non visibili nella sola distanza statica e rendere più realistica la valutazione quotidiana del giro. Dipende dalla disponibilità del fornitore, dal piano API, dalla qualità delle sorgenti evento e dal volume di utilizzo.
L’eventuale attivazione HERE non è inclusa nella anteprima locale base e resta un modulo premium attivabile separatamente.
08 Revisione
L'anteprima serve a mostrare evidenza operativa iniziale. I casi seri richiedono revisione del file, verifica qualità input, lettura del fornitore usato e discussione della reale azionabilità del risultato.
Per questo il contatto diretto con l’operatore resta il CTA principale: dati sporchi, indirizzi incompleti, ripiego del fornitore o necessità di attivare moduli avanzati vanno gestiti in modo esplicito.
Stripe resta opzionale e secondario. La revisione umana resta il percorso corretto quando il dataset o il contesto operativo richiedono decisione, non solo accesso al report.
05 Target
Distributori locali e grossisti con giri ricorrenti.
Distribuzione alimentare e bevande, grossisti beverage, micro-logistica regionale.
PMI che pianificano ancora su Excel, ERP o sequenze storiche.
Aziende che vogliono misurare margine operativo prima di discutere rollout o software più complessi.
06 Differenza
07 Metodo
L'operatore lavora come architetto di protocolli operativi: sistemi decisionali, automazioni, analisi assistita da AI e strumenti orientati al margine.
Dal 2022 lavoro in modo continuativo su sistemi di intelligenza artificiale applicata, protocolli operativi, automazioni e strumenti decisionali orientati al margine.
Questo motore VRP è parte di un metodo più ampio: trasformare dati operativi reali in decisioni misurabili, senza nascondere limiti del dato, del routing o del geocoding.
Il risultato non è una promessa generica di risparmio: è una diagnosi tecnica su file caricati, con revisione umana quando il dato non è ancora affidabile.
08 Limiti
09 Operatività
Questa fase è local-first: il sistema gira su Mac locale con Node.js / Express, senza VPS, dominio o cloud database obbligatori.
Può essere usato in demo dal vivo sul laptop dell'operatore oppure esposto temporaneamente via ngrok per revisione remota con potenziali clienti reali.
La stessa superficie commerciale resta coerente: anteprima pubblica, preparazione assistita, contatto diretto, spazio operativo autenticato e sblocco interno per l'operatore.
Prontezza locale pre-produzione
Questa build resta local-first e demo-ready: controllo salute disponibile su /health, archiviazione JSON locale, esportazioni preservate e configurazione VPS documentata. La produzione reale richiede un segreto di sessione di produzione, HTTPS, backup del directory dati e supervisione processo.
10 Call To Action
Il percorso corretto è semplice: caricamento se il CSV è davvero pronto; preparazione assistita se il dato è tecnico, incompleto o sporco; contatto diretto per revisione completa del caso operativo.