Software gestione ordini: costo, errori e soglia
Matteo Migliore

Matteo Migliore è un imprenditore e architetto software con oltre 27 anni di esperienza nello sviluppo di soluzioni basate su .NET e nell'evoluzione di architetture applicative per imprese e organizzazioni di alto profilo.

Ha guidato progetti enterprise, formato centinaia di sviluppatori e aiutato aziende di ogni dimensione a semplificare la complessità trasformando il software in guadagni per il business.

Il responsabile dell'ufficio ordini di un distributore di ricambi e componenti per impianti termoidraulici in provincia di Brescia, trenta addetti e nove milioni di fatturato, ha un rito che conoscono tutti: alle otto e dieci del lunedì apre la casella ordini e legge il numero in grassetto accanto a "Posta in arrivo". Sessantatré messaggi. Dentro ci sono ordini veri, ma anche conferme di ordini già dati per telefono, foto di una bolla scritta a penna da un installatore, un file Excel con una colonna di codici che nessuno riconosce e un messaggio dell'agente della zona di Verona che scrive soltanto "come da accordi, stessa roba del mese scorso".

Trovi che cosa significa davvero "software gestione ordini" e che cosa non è, i due numeri che dicono se ne hai bisogno o se ti basta un gestionale tenuto meglio, il conto di quanto costa ogni anno l'ordine ribattuto a mano, tre calcoli in codice che puoi rifare con i tuoi dati, e la soglia oltre cui un pezzo su misura si ripaga. Il caso che segue è un caso tipo, ricostruito da situazioni che ho visto in aziende che vendono ad altre aziende, con i numeri arrotondati.

Che cos'è un software di gestione ordini, e che cosa non è

La ricerca "software gestione ordini" raccoglie strumenti molto diversi, e chi sceglie quello sbagliato se ne accorge quando in ufficio continuano a ribattere gli stessi codici. Conviene separarli subito, perché ciascuno risolve un pezzo e ne lascia scoperti altri.

Il primo è l'ERP o gestionale, il programma che tiene anagrafiche, magazzino, contabilità e fatture. Ha quasi sempre un modulo ordini, e il modulo è fatto bene per una cosa precisa: registrare un ordine che qualcuno ha già deciso di inserire. Non va a prendere l'ordine dove nasce. Parte quando una persona apre la schermata e comincia a scrivere righe.

Il secondo è l'e-commerce, il negozio online. È ottimo quando il cliente sceglie da solo da un catalogo, con prezzi uguali per tutti o quasi. Ma un'azienda che vende a installatori, rivenditori e imprese ha listini per cliente, sconti a scaglioni, condizioni di pagamento diverse e clienti che non vogliono smettere di mandare l'email al loro referente. L'e-commerce intercetta una parte degli ordini e lascia fuori il resto. Di come i due sistemi si parlano ho scritto nell'articolo sull'integrazione fra gestionale ed e-commerce.

Il terzo è il portale B2B, cioè l'area riservata dove il cliente accede con le sue credenziali, vede il suo listino e riordina in pochi clic. È la strada giusta per i clienti che riordinano le stesse cose ogni mese, e ne ho parlato nell'articolo sul portale B2B. Il limite è che funziona con chi lo usa. Se il tuo cliente migliore ha sessant'anni e ordina per telefono dal 1998, il portale resta un bel programma che lui non aprirà mai.

Il quarto è l'EDI, lo scambio di documenti d'ordine fra computer in un formato standard. Lo chiedono la grande distribuzione e alcuni grandi clienti industriali. È rigoroso e costoso da avviare, e riguarda quasi sempre pochi clienti molto grandi, non i mille e quattrocento piccoli che fanno la maggior parte delle righe.

Il quinto, e quello che interessa a chi legge, è l'insieme di regole e di memoria che sta fra il momento in cui l'ordine arriva, in qualunque forma, e quello in cui parte la merce: da dove arriva, chi lo prende in carico, se è uguale a uno già ricevuto, se i codici sono giusti, se la merce c'è davvero, quando può partire, che cosa si promette al cliente e chi gli risponde. Questo non è un modulo. È un processo, e ha un tempo, un costo e un tasso di errore che si possono misurare.

Richiesta, ordine, conferma: tre momenti con regole diverse

Nel parlare comune "ordine" è tutto quello che arriva dal cliente. Nel sistema conviene distinguere. La richiesta d'ordine è quello che il cliente manda, in qualunque forma, vera o sporca. L'ordine è la richiesta dopo che qualcuno, o qualcosa, ha controllato cliente, codici, prezzi e quantità. La conferma è la risposta che dice al cliente che cosa riceverà, quanto pagherà e quando. Fra la prima e la seconda c'è la pulizia dei dati, fra la seconda e la terza la verifica della merce. Quasi tutti i guai nascono quando i tre momenti si confondono in uno solo, fatto da una persona di fretta.

Se prima dell'ordine c'è un preventivo, il discorso cambia e ne ho scritto nell'articolo sul software di gestione dei preventivi. Qui parliamo dell'ordine che arriva da clienti che conoscono già i tuoi prezzi: ricambi, forniture, materiali di consumo, tutto ciò che si vende a catalogo e a listino concordato.

Che cosa deve sapere fare, in una riga per funzione

Un sistema utile tiene insieme sei cose: l'ingresso unico di tutti i canali, la lettura delle righe con il controllo dei codici e dei prezzi del cliente, la ricerca dei doppioni, la verifica della disponibilità vera, la conferma con una data che si può mantenere e il seguito fino alla spedizione. Ogni prodotto del mercato fa bene una o due di queste cose. Quasi nessuno le tiene tutte e sei nello stesso posto, ed è lì che nasce la casella del lunedì mattina.

Perché l'ordine si sporca nei passaggi, senza che nessuno sbagli davvero

Il viaggio di un ordine ribattuto a mano: arriva da email, telefono, agente o portale, l'addetto lo rilegge e lo riscrive nel gestionale, la disponibilità si controlla a occhio, la conferma parte il giorno dopo, il magazzino scopre l'errore alla preparazione e il cliente lo scopre alla consegna

Nell'azienda di Brescia nessuno lavorava male. I quattro addetti dell'ufficio ordini conoscevano i clienti per nome, sapevano a memoria i codici più venduti e rispondevano al telefono alla seconda squillo. Ogni singolo gesto era corretto. Quello che non funzionava era il numero di volte in cui lo stesso ordine veniva letto, interpretato e riscritto da qualcuno.

Lo abbiamo seguito su un anno di dati. Su dodicimila ordini, 5.520 erano arrivati per email, 2.880 per telefono, 2.160 tramite i nove agenti e 1.440 dal portale e dal modulo del sito. Soltanto l'ultimo gruppo, il 12 per cento, entrava nel gestionale senza che nessuno lo ribattesse. Il restante 88 per cento, cioè 10.560 ordini, passava per le mani di una persona che leggeva un messaggio, un appunto o una voce al telefono e riscriveva righe, quantità e riferimenti in una schermata.

Ogni riscrittura è una piccola scommessa. Un codice con due cifre scambiate, una quantità letta dalla riga sbagliata, una confezione da dieci scambiata con una da cento, il cliente che ordina "il solito raccordo" e l'addetto che ricorda quello dell'altro cliente. Nessuno di questi errori è una distrazione grave. Sono errori da ripetizione, e ripetuti dodicimila volte l'anno fanno un numero che si vede.

I tre punti in cui l'ordine si sporca

Il primo è l'ingresso in più canali senza un elenco unico. Gli ordini arrivano da cinque posti: la casella condivisa, le caselle personali degli agenti, il telefono dell'ufficio, i telefoni di quelli che stanno sul banco, il modulo del sito. Nessuno sa quanti ordini siano in attesa, e quando un agente è in ferie i messaggi che gli scrivono i clienti restano dove sono. Il cliente, che ha scritto a "un indirizzo dell'azienda", considera l'ordine dato.

Il secondo è la disponibilità promessa senza guardare davvero il magazzino. Il gestionale dice che a magazzino ci sono 140 pezzi di un raccordo. Quello che non dice, o dice in una schermata a parte che nessuno apre, è che 118 sono già impegnati da altri ordini confermati e che la merce in arrivo sta ancora sul camion. L'addetto promette la consegna per domani perché il numero grande è 140. Il giorno dopo il magazzino spedisce 22 pezzi su 30, e il cliente si ritrova con una consegna a metà e un ordine ancora da chiudere.

Il terzo è la conferma che parte tardi o non parte. Se la conferma dipende da una persona che prima riscrive, poi controlla, poi risponde, il tempo che passa fra l'ordine e la risposta è quello della coda di lavoro dell'ufficio, non quello che il cliente si aspetta. Nel caso di Brescia la conferma arrivava in media dopo 1,9 giorni lavorativi, e per il 28 per cento degli ordini, cioè 3.360, dopo più di due giorni. Un installatore che ha il cantiere fermo aspetta la tua risposta per decidere se ordinare altrove.

Tutti e tre i punti si vedono in un giorno, se i dati stanno in un solo posto, e si vedono in un anno se stanno nella testa di quattro persone. Ed è questa la differenza che un software gestione ordini deve produrre: non far lavorare più in fretta le persone, ma far sì che l'ordine sia scritto una volta sola.

Clienti piccoli, rivenditori e grandi clienti: dove cambia il problema

Con i clienti piccoli, installatori e manutentori, il problema è la forma. Ordinano di fretta, con messaggi di una riga, a volte con una foto del pezzo rotto. Il valore sta nell'interpretare bene e rispondere presto: sono clienti che non hanno tempo di aspettare e un fornitore che risponde in un'ora vale più di uno che costa il due per cento in meno.

Con i rivenditori il problema è il volume e la ripetizione. Mandano ordini lunghi, con trenta o quaranta righe, quasi sempre simili a quelli del mese prima. Un errore su una riga è facile da fare e difficile da trovare. Qui il portale e i modelli d'ordine rendono molto, perché il cliente sceglie da una lista che conosce.

Con i grandi clienti il problema è la regola: orari di consegna, imballi, documenti, a volte un tracciato EDI. Qui l'errore non è un fastidio, è una penale scritta nel contratto, e le regole vanno tenute nel sistema e non nella memoria di chi le ha capite una volta.

Il conto vero: quanto costa ogni anno l'ordine ribattuto a mano

Le cinque voci che costano ogni anno a un distributore con trenta addetti e dodicimila ordini l'anno: ore di ribattitura evitabili, righe sbagliate e resi, ordini evasi in ritardo o a metà, clienti persi per i ritardi e tempo perso a rincorrere lo stato degli ordini, per un totale di circa centonovantaseimila euro

Prima di parlare di software conviene fare il conto della situazione di oggi. Nel caso di Brescia le voci erano cinque. Le riporto con il metodo, perché tu possa rifarlo con i tuoi numeri. Ho lasciato fuori il costo del magazzino e della logistica in sé: sono lavoro vero, e nessun programma di ordini lo fa al tuo posto.

Le premesse sono poche. L'azienda gestiva 12.000 ordini l'anno, circa cinquanta ogni giorno lavorativo, con sette righe di media e un valore medio di 750 euro, cioè nove milioni di fatturato. Il margine lordo era del 24 per cento, quindi circa 180 euro su un ordine medio. I clienti attivi erano 1.400. Un'ora di ufficio costava 34 euro, tutto compreso.

Le ore di ribattitura evitabili. Rileggere un ordine, trovare il cliente, cercare i codici, controllare il prezzo che gli spetta e scrivere le righe prendeva in media 12 minuti. Con un sistema che legge l'ordine e propone le righe, a chi lavora restano quattro minuti di controllo. Sono otto minuti risparmiati su 10.560 ordini ribattuti, cioè 84.480 minuti, 1.408 ore, che a 34 euro fanno circa 48.000 euro l'anno.

Le righe sbagliate e i resi. Il 9 per cento degli ordini, 1.080 l'anno, aveva almeno una riga sbagliata: un codice, una quantità, una confezione. Circa un terzo di questi, 380, arrivava al cliente, che lo rimandava indietro: trasporto di andata e ritorno, rimessa a scaffale, nota di credito e nuova fattura costavano in media 95 euro, in tutto 36.100. Gli altri 700 venivano fermati in magazzino con una telefonata e circa mezz'ora di lavoro fra due persone, 17 euro l'uno, cioè 11.900. Sono circa 48.000 euro l'anno.

Gli ordini evasi in ritardo o a metà. Il 14 per cento degli ordini, 1.680, partiva in ritardo rispetto alla data promessa o con righe mancanti, perché la disponibilità era stata promessa guardando la giacenza e non quello che era già impegnato. Ogni caso comportava una seconda spedizione, 22 euro di trasporto, e circa 14 minuti di solleciti, telefonate e riprogrammazioni, 8 euro. Trenta euro per 1.680 ordini fanno circa 50.000 euro l'anno.

I clienti persi per i ritardi. Ogni anno una quarantina di clienti riducevano molto gli acquisti o smettevano di ordinare. Chiedendo il motivo a chi rispondeva, per metà di loro, una ventina, comparivano consegne a metà, date non mantenute o errori ripetuti. Un cliente medio vale 6.400 euro di fatturato e circa 1.540 di margine l'anno. Venti clienti per 1.540 fanno circa 31.000 euro l'anno, e il numero è prudente, perché ho contato un anno solo di mancato acquisto.

Il tempo perso a rincorrere gli ordini. Sei persone, quattro dell'ufficio e due del banco, perdevano in media due ore a settimana a rispondere alla domanda "dov'è il mio ordine", a cercare una email, a controllare con il magazzino che cosa fosse partito. Due ore per quarantasei settimane per sei persone fanno 552 ore, che a 34 euro sono circa 19.000 euro.

Il totale è di circa 196.000 euro l'anno, il 2,2 per cento del fatturato, in un'azienda con un margine operativo del 5 per cento, cioè 450.000 euro di utile. Detto in un altro modo: più del 40 per cento dell'utile se ne andava nel modo in cui gli ordini entravano e venivano confermati, non nei prezzi, non nei prodotti e non nel magazzino.

Due avvertenze oneste. La prima: le voci sui ritardi e sui clienti persi sono in parte mancati guadagni, non perdite contabili, e si sovrappongono, perché un ordine con la riga sbagliata è spesso anche un ordine evaso in ritardo. La seconda: la voce delle ore è la più solida, perché si misura con un cronometro, e per questo la tratto in modo diverso quando calcolo la soglia più avanti.

Il tuo conto sarà diverso, ma le voci sono quasi sempre queste cinque. Se il totale, rifatto con i tuoi numeri, sta sotto lo 0,8 per cento del fatturato, un software gestione ordini non è la tua priorità. Se supera l'1,5, lo è quasi certamente, anche se in azienda nessuno lo chiama così.

Come si rifà il conto in un pomeriggio

Servono cinque dati, e quasi tutti stanno nel gestionale e nella posta. Il primo è il numero di ordini dell'ultimo anno e il loro valore medio. Il secondo è la quota che arriva da canali che costringono qualcuno a riscrivere: email, telefono, agenti, tutto fuorché un portale o un file letto dal programma. Il terzo è il tempo di inserimento: fate cronometrare a tre persone dieci ordini veri, senza dire che è una prova. Il quarto è quanti ordini hanno avuto una correzione dopo la conferma, un reso o una nota di credito. Il quinto è il margine lordo medio, che sa il commercialista.

Con questi cinque dati le voci si calcolano da sole. Non serve un'analisi, serve onestà sul fatto che il tempo vero è quasi sempre il doppio di quello che si pensa, e che gli errori ricordati sono meno di quelli veri, perché si ricordano soltanto quelli arrivati fino al cliente.

Il numero che decide: quanti ordini si ribattono a mano, e quanti escono giusti al primo colpo

Le quattro soglie della quota di ordini ribattuti a mano, sotto il venticinque per cento basta il gestionale, fra venticinque e cinquanta il problema è di metodo, fra cinquanta e settantacinque un pezzo su misura si ripaga, oltre il settantacinque l'ufficio fa soprattutto il copista, e sotto la scala le soglie della quota di ordini giusti al primo colpo

Il conto delle cinque voci ti dice quanto perdi. Non ti dice se un software ti farà recuperare quei soldi, perché una parte dipende da decisioni commerciali che nessun programma prende. Il numero che lo dice è un altro, e lo chiamo quota di ordini ribattuti a mano: la percentuale di ordini che una persona deve riscrivere nel gestionale perché non nascono già in forma utilizzabile dal programma.

Le soglie che uso sono quattro. Sotto il 25 per cento la situazione è sotto controllo: ti basta il gestionale che hai, tenuto con cura, e forse un portale per i clienti che riordinano sempre le stesse cose. Fra il 25 e il 50 il problema è di metodo: il lavoro arriva in ordine sparso, e prima di scrivere codice serve decidere quali canali tenere e chi li presidia. Fra il 50 e il 75 un sistema che legge e propone le righe si ripaga, perché il ritardo è strutturale e nessuna disciplina lo elimina. Oltre il 75 l'ufficio ordini sta facendo soprattutto il copista: il lavoro più costoso dell'azienda, quello di persone che conoscono i clienti, è copiare da un posto a un altro.

Nell'azienda di Brescia la quota era dell'88 per cento, nella fascia più alta. E la distribuzione diceva più della media: i rivenditori con ordini da trenta righe erano i più esposti, perché ogni riga in più è una possibilità in più di sbagliare, e la loro quota di righe corrette al primo colpo era la più bassa.

Il secondo numero: quanti ordini escono giusti al primo colpo

Accanto alla quota ne misuro un secondo: la percentuale di ordini giusti al primo colpo, cioè senza una correzione dopo la conferma, senza un reso e senza una nota di credito per errore d'ordine. Sopra il 98 per cento stai lavorando bene. Fra il 95 e il 98 c'è un problema di metodo. Fra il 90 e il 95 un controllo automatico dei codici e delle quantità si ripaga. Sotto il 90 un ordine su dieci torna indietro, e la fiducia dei clienti si consuma più in fretta di quanto il conto contabile faccia pensare. A Brescia era il 91.

I due numeri raccontano due punti diversi dello stesso flusso. Il primo dice quanto lavoro di copia stai pagando, il secondo quanto costa quel lavoro quando è fatto male. Si può avere uno bene e l'altro male, e i rimedi sono diversi: nel primo caso si lavora sull'ingresso, nel secondo sui controlli.

Un terzo numero, che il cliente vede prima degli altri: il tempo di conferma

Il cliente non vede le tue schermate. Vede soltanto quanto passa fra il momento in cui manda l'ordine e quello in cui riceve una conferma con una data. Lo misuro in giorni lavorativi, ed è la prima cosa che cambia quando il sistema funziona: dai quasi due giorni di Brescia si può scendere a poche ore per la grande maggioranza degli ordini, perché la conferma non aspetta più che qualcuno riscriva.

Come si calcolano, con i dati che hai

Non serve un sistema nuovo per la prima misura. Servono la data e il canale di arrivo di ogni ordine, la data della conferma, e un elenco delle correzioni successive. Se il canale non è scritto da nessuna parte, si ricostruisce dalla posta e dai registri del centralino. Per i giorni lavorativi serve un calendario con i festivi a zero. Con questi dati la misura è una query.

-- Ordini ribattuti a mano, ordini giusti al primo colpo e tempo di conferma, ultimi dodici mesi.
-- Calendario(Giorno date, Lavorativo bit): una riga per ogni giorno, festivi e ponti a zero.
-- Correzioni(IdOrdine, DataCorrezione): righe modificate dopo la conferma, resi, note di credito per errore d'ordine.
WITH Base AS (
    SELECT o.IdOrdine,
           CASE WHEN o.Canale = 'Portale' THEN 0 ELSE 1 END AS Ribattuto,
           CASE WHEN EXISTS (SELECT 1
                             FROM Correzioni AS c
                             WHERE c.IdOrdine = o.IdOrdine)
                THEN 0 ELSE 1 END AS GiustoAlPrimoColpo,
           conf.GiorniLavorativi
    FROM Ordini AS o
    CROSS APPLY (SELECT COUNT(*) AS GiorniLavorativi
                 FROM Calendario AS g
                 WHERE g.Lavorativo = 1
                   AND g.Giorno >  CAST(o.DataRicezione AS date)
                   AND g.Giorno <= CAST(o.DataConferma AS date)) AS conf
    WHERE o.DataRicezione >= DATEADD(month, -12, CAST(GETDATE() AS date))
      AND o.DataRicezione <  DATEADD(day, -30, CAST(GETDATE() AS date))  -- ordini con almeno trenta giorni di storia
      AND o.DataConferma IS NOT NULL
)
SELECT COUNT(*) AS Ordini,
       CAST(100.0 * SUM(Ribattuto) / COUNT(*) AS decimal(5, 1)) AS PercentualeRibattuti,
       CAST(100.0 * SUM(GiustoAlPrimoColpo) / COUNT(*) AS decimal(5, 1)) AS PercentualeGiustiAlPrimoColpo,
       CAST(AVG(1.0 * GiorniLavorativi) AS decimal(5, 1)) AS ConfermaMediaGiorniLavorativi,
       CAST(100.0 * SUM(CASE WHEN GiorniLavorativi > 2 THEN 1 ELSE 0 END) / COUNT(*) AS decimal(5, 1)) AS PercentualeConfermatiOltreDueGiorni
FROM Base;

La query restituisce cinque valori: quanti ordini, la quota di ribattuti, la quota di giusti al primo colpo, la conferma media in giorni lavorativi e la percentuale di ordini confermati dopo più di due giorni. Due avvertenze. La prima: se il canale di arrivo non è mai stato scritto, il dato mancante è già un risultato, e brutto, perché vuol dire che nessuno sa da dove arrivano gli ordini. La seconda: conta la data in cui l'ordine è arrivato, non quella in cui qualcuno l'ha aperto. Sono giorni diversi, e il primo è quello che vede il cliente.

La disponibilità vera: il prezzo e la data che puoi promettere

Quasi tutto il valore di un software gestione ordini, dopo l'ingresso unico, sta in una funzione sola: dire al cliente soltanto quello che si può mantenere. Tre numeri che oggi stanno in tre posti vanno messi accanto, per ogni riga: la giacenza fisica, la quantità già impegnata da altri ordini confermati e la merce in arrivo con la sua data. La differenza fra giacenza e impegnato è la quantità libera, e solo quella si può promettere subito.

La parte che sembra banale, e che non lo è, è il calendario. Una consegna promessa per sabato in un'azienda che non spedisce di sabato è una promessa sbagliata, come lo è una merce che arriva il venerdì pomeriggio e che si dichiara spedibile lo stesso giorno. Il sistema deve contare i giorni lavorativi, e deve sapere a che ora l'azienda chiude le spedizioni.

Un calcolo che si scrive in un'ora

Ecco il nucleo in C#, con i tipi minimi. Per ogni riga dice quanti pezzi si possono spedire subito, quanti dopo e con quale data, oppure che la riga non si può promettere. Non decide al posto della persona: scrive nella conferma quello che è vero e segnala quello che manca.

// Promessa di consegna di una riga d'ordine: giacenza libera, merce in arrivo, orario di chiusura spedizioni.
public sealed record Disponibilita(string Codice, int Giacenza, int Impegnato, int InArrivo, DateOnly? DataArrivo);

public enum EsitoPromessa { Pronto, Parziale, Differito, NonPromettibile }

public sealed record Promessa(
    string Codice, int Richiesta, int Subito, EsitoPromessa Esito, DateOnly? ConsegnaCompleta, string Nota);

public static class PromessaDiConsegna
{
    private static readonly TimeOnly ChiusuraSpedizioni = new TimeOnly(15, 0);

    private static bool Lavorativo(DateOnly giorno) =>
        giorno.DayOfWeek != DayOfWeek.Saturday && giorno.DayOfWeek != DayOfWeek.Sunday; // i festivi vengono dal calendario aziendale

    private static DateOnly ProssimoLavorativo(DateOnly giorno)
    {
        do { giorno = giorno.AddDays(1); } while (!Lavorativo(giorno));
        return giorno;
    }

    public static Promessa Calcola(string codice, int richiesta, Disponibilita? d, DateTime adesso)
    {
        if (d is null)
        {
            return new Promessa(codice, richiesta, 0, EsitoPromessa.NonPromettibile, null,
                "Articolo non in anagrafica: verificare a mano.");
        }

        var oggi = DateOnly.FromDateTime(adesso);
        var spedizione = Lavorativo(oggi) && TimeOnly.FromDateTime(adesso) < ChiusuraSpedizioni
            ? oggi
            : ProssimoLavorativo(oggi);

        var libero = Math.Max(0, d.Giacenza - d.Impegnato);
        if (libero >= richiesta)
        {
            return new Promessa(codice, richiesta, richiesta, EsitoPromessa.Pronto,
                ProssimoLavorativo(spedizione), "Disponibile: spedizione completa.");
        }

        var mancano = richiesta - libero;
        DateOnly? completa = null;
        if (d.DataArrivo is DateOnly arrivo && d.InArrivo >= mancano)
        {
            var spedibile = ProssimoLavorativo(arrivo) > spedizione ? ProssimoLavorativo(arrivo) : spedizione;
            completa = ProssimoLavorativo(spedibile);
        }

        if (libero == 0)
        {
            return completa is null
                ? new Promessa(codice, richiesta, 0, EsitoPromessa.NonPromettibile, null,
                    "Nulla di libero e nessun arrivo che copra la richiesta: serve una decisione.")
                : new Promessa(codice, richiesta, 0, EsitoPromessa.Differito, completa,
                    $"Niente subito: tutto dal {completa:dd/MM/yyyy}.");
        }

        var nota = completa is null
            ? $"{libero} subito, per i restanti {mancano} non c'è una data: chiedere al cliente."
            : $"{libero} subito il {ProssimoLavorativo(spedizione):dd/MM/yyyy}, i restanti {mancano} il {completa:dd/MM/yyyy}.";
        return new Promessa(codice, richiesta, libero, EsitoPromessa.Parziale, completa, nota);
    }
}

Prendi il raccordo di cui parlavo prima: 140 pezzi in giacenza, 118 già impegnati, 200 in arrivo venerdì 9 ottobre 2026. Il cliente ne chiede 30 lunedì 5 ottobre alle dieci e venti. La quantità libera è 22, ne mancano 8. Il sistema promette 22 pezzi con consegna martedì 6 e il resto, dalla merce in arrivo, spedibile lunedì 12 e consegnato martedì 13. Il vecchio modo avrebbe guardato 140 e promesso trenta pezzi per domani. Il cliente avrebbe saputo la verità due giorni dopo, a cantiere aperto.

Non c'è niente di sofisticato, ed è proprio questo il punto. Il valore non sta nella formula: sta nel fatto che i tre numeri siano nello stesso posto, che le date siano date lavorative e che la promessa la scriva una macchina ogni volta, non la memoria di chi è stanco il venerdì pomeriggio. L'altra metà del lavoro, cioè tenere vere giacenze e merce in arrivo, è quella di cui ho scritto nell'articolo sul software di gestione del magazzino: se il magazzino mente, la promessa mente con lui.

Che cosa fare quando la merce non basta

La funzione non decide che cosa fare con una consegna parziale: lo decide una regola del cliente. Per alcuni è meglio ricevere subito i pezzi disponibili, per altri è meglio aspettare tutto e fare una sola consegna, perché il trasporto di due viaggi costa più della merce. Questa preferenza va scritta una volta nell'anagrafica del cliente e applicata ogni volta. Così la conferma non sorprende nessuno, e l'addetto non deve ricordarsi di chi sia il cliente "che vuole tutto insieme".

Ordini doppi, righe sbagliate: i controlli che non costano nulla

Una voce dimenticata del conto è il doppione: lo stesso ordine che entra due volte. Succede più spesso di quanto si pensi, e per ragioni innocenti. Il cliente manda l'email, poi richiama per essere sicuro, e l'addetto che risponde lo riscrive. L'agente inserisce l'ordine che il cliente gli aveva già mandato in copia all'ufficio. Un ordine con un difetto viene rimandato "corretto" senza dire che sostituisce il precedente. Nell'azienda di Brescia i doppioni erano circa l'1,5 per cento degli ordini, 180 l'anno: la maggior parte intercettati in tempo, alcuni no, e quelli non intercettati diventavano una consegna doppia e un reso.

Il controllo è semplice e si scrive in mezz'ora. Due ordini dello stesso cliente, arrivati a poche ore di distanza, sono sospetti in due casi: hanno lo stesso riferimento d'ordine del cliente, scritto magari in modo diverso, oppure hanno le stesse righe con le stesse quantità. In nessuno dei due casi il sistema scarta l'ordine. Lo segnala a chi lo sta inserendo, con il motivo, e decide la persona.

// Segnalazione dei doppioni: stesso riferimento del cliente, oppure stesse righe e quantità, entro 72 ore.
public sealed record RigaOrdine(string Codice, int Quantita);

public sealed record OrdineRicevuto(
    string Id, string IdCliente, string? RiferimentoCliente, DateTime Ricevuto, IReadOnlyList<RigaOrdine> Righe);

public sealed record SospettoDoppione(string IdEsistente, string Motivo);

public static class ControlloDoppioni
{
    private static string Normalizza(string? testo) =>
        new string((testo ?? "").Where(char.IsLetterOrDigit).ToArray()).ToUpperInvariant();

    private static string Firma(OrdineRicevuto o) =>
        string.Join("|", o.Righe.OrderBy(r => r.Codice).Select(r => $"{r.Codice}x{r.Quantita}"));

    public static IReadOnlyList<SospettoDoppione> Cerca(
        OrdineRicevuto nuovo, IEnumerable<OrdineRicevuto> esistenti, int finestraOre = 72)
    {
        var riferimentoNuovo = Normalizza(nuovo.RiferimentoCliente);
        var firmaNuovo = Firma(nuovo);
        var sospetti = new List<SospettoDoppione>();

        foreach (var e in esistenti)
        {
            if (e.Id == nuovo.Id || e.IdCliente != nuovo.IdCliente) continue;
            if (Math.Abs((e.Ricevuto - nuovo.Ricevuto).TotalHours) > finestraOre) continue;

            if (riferimentoNuovo.Length > 0 && riferimentoNuovo == Normalizza(e.RiferimentoCliente))
            {
                sospetti.Add(new SospettoDoppione(e.Id, "Stesso riferimento d'ordine del cliente."));
            }
            else if (firmaNuovo == Firma(e))
            {
                sospetti.Add(new SospettoDoppione(e.Id, $"Stesse righe e quantità, ricevuto {e.Ricevuto:dd/MM HH:mm}."));
            }
        }

        return sospetti;
    }
}

Un caso. Un installatore manda alle otto e cinque del mattino l'ordine con riferimento "PO 2291/B". Alle quattro e mezza del pomeriggio l'agente della sua zona inserisce lo stesso ordine con il riferimento scritto "po2291b". Tolti spazi, barre e maiuscole, i due riferimenti coincidono, e il sistema avvisa l'addetto prima che il secondo ordine diventi una seconda consegna. Se invece il riferimento manca, vale l'altra regola: stesse sette righe con le stesse quantità, nello stesso cliente, nello stesso giorno, è quasi certamente lo stesso ordine.

Controllare i codici prima che sbaglino

Lo stesso spirito vale per le righe. Prima ancora della disponibilità, ogni riga dovrebbe passare tre verifiche banali, che nessuno fa a mano perché sono noiose: il codice esiste e non è fuori catalogo, la quantità è un multiplo della confezione, il prezzo applicato è quello che spetta a quel cliente alla data di oggi. Una riga che non le passa non viene scartata: viene evidenziata, e l'addetto la guarda per prima. È la differenza fra un ufficio che rilegge tutto, e per questo non rilegge niente con attenzione, e un ufficio che guarda soltanto quello che il sistema non sa verificare.

Come deve girare un software gestione ordini: dall'ordine alla spedizione

Il flusso di un software di gestione ordini collegato al gestionale: ogni ordine entra in un elenco unico qualunque sia il canale, le righe vengono lette e controllate, i doppioni si segnalano, la disponibilità vera calcola la data promessa, la conferma parte con la data, il gestionale riceve l'ordine pulito e il magazzino prepara la spedizione

La domanda che mi fanno più spesso è se debba essere un prodotto o un sistema nuovo. Prima conviene capire che cosa deve succedere, perché il flusso è lo stesso qualunque strada si scelga.

Ogni ordine entra in un elenco unico. Email, telefono, agenti, portale, foto di una bolla: qualunque sia il canale, l'ordine finisce in un posto con una data di arrivo, un canale e un responsabile. Non serve eliminare i canali, serve che tutti scrivano nello stesso elenco. Nell'azienda di Brescia bastò una casella condivisa con regole, un modulo di tre campi per i telefoni e un indirizzo da dare agli agenti.

Le righe vengono lette e controllate. Dall'email o dal file si ricava una bozza di righe, e ogni riga passa dai controlli: codice esistente, confezione, prezzo del cliente. Quello che non quadra si segnala. A chi lavora resta il controllo di quello che è dubbio, non la copiatura di quello che è chiaro.

I doppioni si segnalano. Prima di accettare l'ordine il sistema controlla se ne esiste uno uguale, e se sì lo dice.

La disponibilità vera decide la data. Per ogni riga si calcolano quantità libera, merce in arrivo e giorno lavorativo di spedizione. La conferma contiene soltanto promesse che si possono mantenere.

La conferma parte con la data. Un messaggio al cliente con righe, prezzi, disponibilità e consegna, nello stesso canale da cui è arrivato l'ordine. Se tutto è chiaro, parte da solo dopo il controllo di una persona, in poche ore. Se qualcosa non quadra, resta nella coda con il motivo scritto.

Il gestionale riceve l'ordine pulito. L'ordine entra nel gestionale con una sola scrittura, senza che nessuno riscriva righe, quantità e riferimenti. La contabilità, le fatture e le anagrafiche non cambiano: è questo il pezzo che si tiene.

Il magazzino prepara la spedizione. Il magazzino vede un ordine in cui le quantità e le date sono quelle promesse, e le variazioni dell'ultimo momento tornano al cliente nello stesso modo.

Il cliente può sapere dov'è il suo ordine. Un indirizzo o una pagina con lo stato, senza telefonare. Chi risponde a "dov'è il mio ordine" non è più un addetto che cerca una email, è una schermata. Un cliente che ha uno stato visibile smette di chiamare, ed è la voce da 19.000 euro che scende.

Nessuno di questi passaggi richiede di cambiare la contabilità o la fatturazione. Nell'azienda di Brescia il gestionale è rimasto lo stesso. È cambiato quello che stava prima: le caselle, i foglietti e la rilettura.

Il legame con il resto dell'azienda

Un sistema di ordini non vive da solo. Dal lato commerciale riceve prezzi e condizioni dal CRM, e rimanda l'esito e la storia degli acquisti: l'articolo sul gestionale CRM descrive il punto di vista di chi vende. Se per alcune commesse l'ordine nasce da un preventivo, i dati passano dal sistema dei preventivi senza essere riscritti, e per le aziende che producono su ordine il passo successivo è la commessa, di cui ho scritto nell'articolo sul software di gestione delle commesse. Il confine fra un sistema e l'altro è sempre lo stesso: ognuno passa all'altro l'esito, nessuno dei due diventa l'altro.

Che cosa non deve fare

Un sistema di questo tipo non deve rendere l'ordine più rigido di quello che è. Una parte del mestiere sta nell'eccezione: il cliente storico a cui si spedisce prima del pagamento, l'urgenza di un installatore con l'impianto fermo, la sostituzione di un articolo esaurito con un equivalente concordato per telefono. Il sistema deve permettere tutto questo, chiedendo solo che l'eccezione sia scritta e abbia un nome accanto. Un programma che impedisce di fare l'eccezione verrà aggirato in una settimana, e le caselle personali torneranno.

Quanto costa un software gestione ordini: prodotto, modulo del gestionale o su misura

Costo cumulato su cinque anni di restare con la ribattitura a mano e di costruire un pezzo su misura da 38.000 euro, al crescere degli ordini l'anno: contando solo il tempo le linee si incrociano intorno ai 3.350 ordini, contando anche errori e ritardi recuperati intorno ai 1.240

Le strade sono tre, e i prezzi che seguono sono quelli che vedo nel 2026 per aziende italiane che vendono ad altre aziende, fra i tre e i trenta milioni di fatturato.

Il prodotto. Esistono portali B2B e programmi di gestione ordini pronti, con catalogo, listini per cliente, carrello e un minimo di lettura dei file. Costano di solito fra i tremila e i ventimila euro l'anno, a seconda di utenti, clienti collegati e funzioni, con un avviamento fra duemila e quindicimila euro. Fanno bene le cose generiche: il cliente che accede e riordina. Fanno meno bene quelle particolari della tua azienda: la lettura dell'email sporca, il calcolo della disponibilità con l'impegnato e la merce in arrivo, i controlli sui doppioni, il collegamento con il tuo gestionale.

Il modulo del gestionale. Il modulo ordini del gestionale amministrativo costa fra seimila e trentamila euro fra licenza e configurazione, se non lo hai già. Ha il vantaggio di conoscere anagrafiche, articoli e giacenze. È pensato per ordini inseriti da un operatore, e questo si sente quando metà degli ordini arriva da email e telefonate e la schermata di inserimento resta uguale.

Il sistema su misura. Anche qui due cifre. Un pezzo su misura che si affianca a quello che c'è, cioè ingresso unico, lettura delle righe con proposta, controlli di codici, doppioni e prezzi, verifica della disponibilità con impegnato e arrivi, conferma con data, stato dell'ordine e collegamento con il gestionale, costa fra i ventottomila e i sessantamila euro, più il quindici o venti per cento l'anno di manutenzione. Un sistema completo, con regole di assegnazione fra più magazzini, scambio EDI con i grandi clienti e gestione dei resi, costa fra i novanta e i centottantamila euro e serve raramente sotto i venticinquemila ordini l'anno o se il magazzino è uno solo.

La soglia, con i numeri

Il confronto più utile è fra restare con la ribattitura a mano e costruire un pezzo su misura. Il costo del pezzo è quasi fisso, mentre il costo del lavoro che si risparmia cresce con il numero degli ordini.

Con i numeri di Brescia, il pezzo è costato 38.000 euro, con una manutenzione del quindici per cento, cioè 5.700 euro l'anno. In cinque anni fanno 66.500 euro. Contando soltanto il tempo di ribattitura, che a conti fatti sono circa sette minuti risparmiati per ogni ordine, a 34 euro l'ora ogni ordine l'anno di volume vale circa 4 euro l'anno, quasi 20 in cinque anni. Le due strade si incrociano intorno a 3.350 ordini l'anno, circa quattordici ogni giorno lavorativo. Sotto quella soglia, contando soltanto il tempo, ti conviene restare come sei.

// Quanti ordini l'anno servono perché un pezzo su misura si ripaghi in N anni.
public static class Pareggio
{
    public static (int SoloTempo, int ConErroriRecuperati) Ordini(
        decimal costoRealizzazione, decimal manutenzioneAnnuaPercentuale, int anni,
        decimal minutiRisparmiatiPerOrdine, decimal costoOra, decimal erroriRecuperatiPerOrdineAnno)
    {
        var costoTotale = costoRealizzazione * (1 + manutenzioneAnnuaPercentuale * anni);
        var risparmioTempo = minutiRisparmiatiPerOrdine / 60m * costoOra * anni;  // per ogni ordine l'anno
        var risparmioErrori = erroriRecuperatiPerOrdineAnno * anni;               // idem, errori e ritardi evitati

        return (
            (int)Math.Ceiling(costoTotale / risparmioTempo),
            (int)Math.Ceiling(costoTotale / (risparmioTempo + risparmioErrori)));
    }
}

// Pareggio.Ordini(38000m, 0.15m, 5, 7m, 34m, 6.78m)  =>  (3353, 1238)

E il solo tempo è la parte più piccola del conto. A Brescia il sistema recuperava prudentemente il 55 per cento delle quattro voci che non sono ore, cioè delle righe sbagliate e dei resi, degli ordini a metà, dei clienti persi e dei solleciti: 148.000 euro l'anno per il 55 per cento fa circa 81.400 euro, cioè 6,78 euro per ogni ordine dell'anno. Aggiungendoli, la soglia scende a circa 1.240 ordini l'anno, meno di cinque ogni giorno lavorativo. Con dodicimila ordini, nel caso di Brescia, il risparmio annuo complessivo valeva circa 129.000 euro, 5.700 dei quali se ne andavano in manutenzione. Il pezzo su misura, costato 38.000 euro, si è ripagato in circa quattro mesi dall'avvio in produzione, otto contando i quattro del progetto.

La strada che consiglio nella maggior parte dei casi è mista: il gestionale che già hai per anagrafiche, articoli, magazzino e fatture, un portale per i clienti che riordinano le stesse cose, e un pezzo su misura per quello che nessun prodotto sa fare bene, cioè leggere gli ordini sporchi, calcolare la promessa vera e controllare i doppioni. Se in tutta l'azienda gli ordini sono meno di mille all'anno, non serve né l'una né l'altra: bastano una casella condivisa con regole, un modello d'ordine per i clienti ricorrenti e un controllo settimanale delle righe sbagliate.

Chi sta valutando se prendere un pacchetto o far costruire qualcosa su misura trova il ragionamento più ampio nell'articolo sul gestionale aziendale, pacchetto o su misura, e le voci che un contratto serio deve contenere in quello sullo sviluppo di software su misura.

Le domande da fare a chi ti propone un prodotto

Cinque domande separano i prodotti che risolvono il problema da quelli che lo spostano.

Che cosa fa con l'email che non è un modulo? Se il programma sa ricevere soltanto ordini già strutturati, risolve il 12 per cento di Brescia, non l'88. Chiedi di fargli leggere tre ordini veri, anche brutti.

La disponibilità tiene conto dell'impegnato? Se la schermata mostra la giacenza e basta, ti promette quello che non hai. Chiedi di fare la prova con un articolo già venduto per intero ad altri ordini.

Che cosa succede quando lo stesso ordine arriva due volte? Se la risposta è "l'operatore se ne accorge", non c'è nessun controllo. Chiedi di inserire due volte lo stesso ordine e di guardare che cosa dice.

Come entra l'ordine nel mio gestionale? Se ogni passaggio è un'esportazione da fare a mano, i dati torneranno in ordine sparso entro un mese.

Come escono i miei dati? Un prodotto che non espone lo storico degli ordini con un'interfaccia documentata è un'altra isola, e le tue date di conferma, i tuoi errori e i tuoi tempi sono l'ultima cosa che un'azienda può permettersi di lasciare chiusa nel programma di un fornitore.

L'intelligenza artificiale in un software di gestione ordini: dove aiuta e dove no

Molti prodotti del 2026 promettono un assistente basato sull'intelligenza artificiale. Uso modelli linguistici ogni giorno nel mio lavoro dal 2023, e per chi riceve ordini ho visto tre usi che rendono e uno che no.

La bozza delle righe dall'email. Un modello legge il messaggio del cliente, il file o la foto della bolla e prepara le righe: codice probabile, quantità, riferimento d'ordine, indirizzo di consegna se diverso. Una persona controlla e completa. Il lavoro di leggere e riscrivere, che occupava dodici minuti, diventa un controllo di quattro, e soprattutto l'ordine entra nell'elenco con i campi giusti invece che in una casella. Dove il modello non è sicuro di un codice, deve dirlo, non scegliere.

L'abbinamento di un codice ambiguo. "Il solito raccordo da tre quarti" può corrispondere a quattro articoli. Il modello propone i due più probabili guardando lo storico di quel cliente, e la persona sceglie. Il costo è un clic, e il vantaggio è che la scelta si impara: la volta dopo il sistema sa che quel cliente intende quello.

Il testo della conferma e dei solleciti. Il modello scrive il messaggio che accompagna la conferma, nel tono e nella lingua del cliente, con i riferimenti all'ordine. Le quantità, i prezzi e le date sono quelle calcolate dal sistema, non scritte dal modello. La persona legge e manda.

Non rende, invece, e qui sono netto, la conferma della disponibilità e del prezzo. Un modello linguistico non sa quanti pezzi sono davvero liberi, quanti sono impegnati e quando arriverà il camion. Non sa che sconto spetta a quel cliente quest'anno. Può produrre una data verosimile, e una data verosimile sbagliata è peggio di nessuna data, perché il cliente organizza il cantiere su quella. Disponibilità e prezzo li calcolano i dati con le loro regole, e se i dati non bastano decide una persona. Il modello prepara, il sistema calcola, la persona decide.

C'è un secondo limite, meno visibile. Un modello che lavora su dati sporchi, cioè con anagrafiche doppie, giacenze sbagliate e listini scaduti, produce proposte sbagliate con grande sicurezza, e le persone smettono di fidarsi in un giorno. Per questo l'intelligenza artificiale va aggiunta dopo i dati, non prima.

Gli errori da evitare quando si cambia il modo in cui entrano gli ordini

Ho visto lo stesso copione ripetersi in aziende diverse, e conviene conoscerlo prima.

Togliere i canali ai clienti. Il primo impulso è dire ai clienti: da domani ordinate soltanto dal portale. Funziona con il dieci per cento e fa arrabbiare gli altri novanta. Il sistema deve prendere l'ordine come arriva, non chiedere al cliente di cambiare abitudini. Il portale si propone a chi riordina sempre le stesse cose, e si lascia che il resto continui a scrivere come ha sempre fatto.

Automatizzare prima di pulire. Un sistema che legge e inserisce ordini da solo, con anagrafiche sporche, produce errori più in fretta di quanto li producesse l'ufficio. Prima si sistemano codici doppi, confezioni e listini dei clienti principali, poi si accende la lettura.

Promettere una data che non si controlla. Se la conferma automatica contiene una data che il magazzino non rispetta, l'azienda ha costruito un modo veloce di deludere il cliente. Prima si misura quanto sono veri giacenza e impegnato, poi si pubblica la data.

Lasciare l'ufficio fuori dal progetto. Chi conosce i clienti e i loro modi di scrivere è l'ufficio ordini, non chi sviluppa. Se non è coinvolto fin dalle prime due settimane, il sistema impara le regole sbagliate e le persone lo aggirano.

Misurare soltanto la velocità. Se la sola cosa che si guarda è quanti ordini si inseriscono per ora, gli errori salgono. Si misurano insieme tre cose: la quota di ribattuti, la quota di giusti al primo colpo e il tempo di conferma. Se una migliora e le altre peggiorano, il sistema ha spostato il problema.

Dimenticare le eccezioni. Il cliente che ordina a voce da vent'anni, l'urgenza, la sostituzione concordata: sono la parte del mestiere che il sistema deve lasciare fare. Se non c'è una strada per l'eccezione, la troveranno le persone, fuori dal sistema.

Da dove si comincia: il primo rilascio in trenta giorni

Che tu scelga un prodotto, il modulo del gestionale o un pezzo su misura, l'ordine in cui si fanno le cose conta più della scelta. Il piano che uso per un'azienda che riceve ordini da più canali comincia con un primo rilascio utile in trenta giorni. Non è il sistema completo, ci vorranno altri tre o quattro mesi: è la parte che comincia a togliere lavoro a chi lo fa oggi.

Prima settimana: la misura. Si calcolano la quota di ordini ribattuti, la quota di giusti al primo colpo e il tempo di conferma, ricostruendo canale e date da posta e centralino. Si cronometrano dieci ordini veri. Si rifà il conto delle cinque voci. Alla fine c'è un numero, e un elenco degli ordini con errore degli ultimi tre mesi, che di solito mostra subito i dieci codici e i tre clienti dove si sbaglia di più.

Seconda settimana: l'elenco unico. Si apre una casella condivisa con regole e un modulo di tre campi per il telefono, e si dà agli agenti un indirizzo unico a cui inoltrare. Da quel giorno ogni ordine ha una data di arrivo, un canale e un responsabile. È già un miglioramento, anche senza nessun programma nuovo, e rimisurando a fine settimana si vede quanti ordini erano fuori dall'elenco.

Terza settimana: i controlli. Si accendono i tre controlli sulle righe, cioè codice, confezione e prezzo del cliente, e la segnalazione dei doppioni. Si parte dai venti clienti che pesano di più. Chi lavora li usa in parallelo al metodo di oggi, e si confrontano i risultati ordine per ordine. È la fase in cui si perdono le illusioni e si guadagna la fiducia.

Quarta settimana: disponibilità e conferma. Si calcola la promessa con giacenza libera, merce in arrivo e calendario, e la conferma parte con la data per gli ordini che passano tutti i controlli. Gli altri restano in coda con il motivo scritto. Alla fine del mese si rimisurano i tre numeri: è l'unico modo di sapere se il progetto ha funzionato, e se non è così, di capire dove guardare.

Il resto, dalla lettura delle email alla bozza delle righe, dal portale per i clienti ricorrenti allo stato dell'ordine visibile al cliente, arriva dopo, quando i dati sono affidabili e l'ufficio si fida del sistema.

Che cosa chiedere alla persona che lo costruisce

Se scegli il pezzo su misura, tre richieste prima di cominciare. Chiedi che i tre numeri, quota di ribattuti, giusti al primo colpo e tempo di conferma, siano calcolati dal sistema fin dal primo giorno, in modo che il risultato si veda senza una riunione. Chiedi che le regole, cioè confezioni, prezzi del cliente, preferenze di consegna e orario di chiusura delle spedizioni, siano modificabili da chi lavora in azienda, senza passare da chi ha scritto il programma. Chiedi che i dati escano in un formato aperto, così non resti in ostaggio nemmeno di chi lo ha fatto bene.

Se il numero dice che non è il tuo problema

Può darsi che, fatta la misura, la quota di ordini ribattuti sia sotto il 25 per cento, che i tuoi ordini escano giusti al primo colpo il 98 per cento delle volte e che la conferma parta in giornata. È una buona notizia, e vale la pena dirlo chiaramente: in quel caso un software gestione ordini su misura non ti serve, e chi ti dice il contrario ti sta vendendo qualcosa.

In quel caso il collo di bottiglia, se c'è, è quasi sempre altrove. Se ricevi bene ma spedisci male, il problema è nel magazzino e nella logistica, e un sistema di ordini non lo risolve. Se gli ordini escono giusti ma i clienti comprano poco, il problema è nell'offerta, nel prezzo o nella relazione. Se gli ordini sono pochi e grandi, trenta o quaranta l'anno che valgono centinaia di migliaia di euro l'uno, non serve un sistema: serve una persona che li segua uno per uno, come un progetto.

E c'è un caso in cui il software non è la risposta nemmeno con numeri brutti: quando gli errori non dipendono dagli strumenti ma da un anagrafico mai sistemato, con tre codici per lo stesso articolo e due schede per lo stesso cliente. Lì il problema è il dato, e un programma aiuta soltanto se prima lo hai ripulito.

Se sei arrivato fin qui, probabilmente hai in mente la casella del lunedì mattina. Prima di guardare qualunque dimostrazione, prendi gli ultimi cinquanta ordini che hai ricevuto e scrivi, per ciascuno, da che canale è arrivato, se qualcuno l'ha riscritto e quanto ci è voluto per confermarlo. Poi guarda quanti hanno avuto una correzione dopo la conferma. Se più di metà li ha riscritti qualcuno, o più di uno su dieci ha avuto una correzione, hai già la risposta. Il resto è un progetto, non una scelta di prodotto.

Se vuoi un secondo sguardo sul tuo caso, la strada è la consulenza software, e quando la soluzione giusta è un pezzo costruito attorno al tuo modo di lavorare lo trovi spiegato nella pagina sul software su misura. Per il metodo con cui si legge il margine di un'azienda intera, dall'alto, c'è l'articolo sul software per il controllo di gestione.

Domande frequenti

Dipende dalla strada. Un prodotto, cioè un portale B2B o un programma di gestione ordini pronto, costa di solito fra i tremila e i ventimila euro l'anno, con un avviamento fra duemila e quindicimila euro. Il modulo ordini del gestionale costa fra seimila e trentamila euro fra licenza e configurazione, se non lo hai già. Un pezzo su misura che si affianca a quello che c'è, con ingresso unico, lettura delle righe, controlli, disponibilità vera e conferma con data, costa fra ventottomila e sessantamila euro, più il quindici o venti per cento l'anno di manutenzione. Un sistema completo con più magazzini ed EDI sta fra novanta e centottantamila euro e serve raramente sotto i venticinquemila ordini l'anno.

Si calcolano due numeri. La quota di ordini ribattuti a mano: la percentuale di ordini che una persona deve riscrivere nel gestionale. E la percentuale di ordini giusti al primo colpo, cioè senza correzioni dopo la conferma, senza resi e senza note di credito per errore d'ordine. Sotto il 25 per cento di ribattuti basta il gestionale, fra 25 e 50 il problema è di metodo, fra 50 e 75 un sistema si ripaga, oltre 75 l'ufficio fa soprattutto il copista. Per gli ordini giusti, sopra il 98 per cento si lavora bene, sotto il 90 un ordine su dieci torna indietro.

Cinque voci: le ore di ribattitura evitabili, le righe sbagliate e i resi, gli ordini evasi in ritardo o a metà, i clienti persi per i ritardi e il tempo perso a rincorrere lo stato degli ordini. In un distributore con 30 addetti, 12.000 ordini l'anno e 9 milioni di fatturato valevano circa 48.000, 48.000, 50.000, 31.000 e 19.000 euro, in tutto circa 196.000 euro l'anno, il 2,2 per cento del fatturato. Le voci su ritardi e clienti persi sono in parte mancati guadagni. Sotto lo 0,8 per cento del fatturato il problema non è una priorità, sopra l'1,5 quasi certamente lo è.

No. Il portale B2B e l'e-commerce sono canali: il cliente accede, sceglie e ordina da solo, e funzionano con chi li usa. Un software gestione ordini copre tutto il percorso, compresi gli ordini che arrivano da email, telefono e agenti: li raccoglie in un elenco unico, controlla righe e doppioni, calcola la disponibilità vera e manda la conferma con una data. Il portale è una delle porte d'ingresso, di solito per i clienti che riordinano sempre le stesse cose.

Può preparare, non confermare. Aiuta a leggere l'email o la foto della bolla e a proporre le righe, ad abbinare un codice ambiguo guardando lo storico del cliente e a scrivere il testo della conferma, sempre con una persona che controlla. Non deve decidere disponibilità e prezzo: un modello non sa quanti pezzi sono davvero liberi né che sconto spetta a quel cliente, e una data verosimile ma sbagliata è peggio di nessuna data. Disponibilità e prezzo li calcolano i dati con le loro regole.

Nella maggior parte dei casi una strada mista: il gestionale che già hai per anagrafiche, magazzino e fatture, un portale per i clienti che riordinano le stesse cose e un pezzo su misura per leggere gli ordini sporchi, calcolare la promessa vera e controllare i doppioni. Contando solo il tempo il pezzo su misura si ripaga oltre i 3.350 ordini l'anno; con errori e ritardi recuperati la soglia scende a circa 1.240. Sotto i mille ordini bastano una casella condivisa con regole e un modello d'ordine per i clienti ricorrenti.

Lascia i tuoi dati nel form qui sotto

Matteo Migliore

Matteo Migliore è un imprenditore e architetto software con oltre 27 anni di esperienza nello sviluppo di soluzioni basate su .NET e nell'evoluzione di architetture applicative per imprese e organizzazioni di alto profilo.

Nel corso della sua carriera ha collaborato con realtà come Cotonella, Il Sole 24 Ore, FIAT e NATO, guidando team nello sviluppo di piattaforme scalabili e modernizzando ecosistemi legacy complessi.

Ha formato centinaia di sviluppatori e affiancato aziende di ogni dimensione nel trasformare il software in un vantaggio competitivo, riducendo il debito tecnico e portando risultati concreti in tempi misurabili.

Stai leggendo perché vuoi smettere di rattoppare software fragile.Scopri il metodo per progettare sistemi che reggono nel tempo.