Manutenzione tecnica, sicurezza, magazzino, catalogo, marketing e intelligenza artificiale dopo il go-live: scelte, quanto costa e cosa succede se non lo si fa
Il giorno del lancio un eCommerce smette di essere un progetto e diventa un servizio. Cambia tutto: il rischio non è più consegnare in ritardo, è restare fermi mentre i clienti stanno comprando. Cambiano le competenze richieste, cambia il tipo di contratto, e cambia soprattutto il modo di ragionare sui soldi — dalla domanda "quanto costa farlo" a "quanto costa tenerlo in piedi e quanto costa non tenerlo".
Questa guida è la seconda di due parti. La prima — come sviluppare un nuovo eCommerce — copre la progettazione fino al go-live. Questa riguarda tutto ciò che viene dopo: il contratto di manutenzione, gli aggiornamenti tecnologici che hanno date certe, la sicurezza dei pagamenti, la riconciliazione con il magazzino, il catalogo che invecchia, il marketing in esercizio, l'intelligenza artificiale e la conformità che non si esaurisce con il lancio. Per ogni ambito trovi come si sceglie e cosa comporta la scelta in termini di tempi, costi, efficacia e organizzazione, i driver per scegliere i freelance a cui affidarlo e gli strumenti, con i prezzi pubblicati, per la manutenzione e per le statistiche post-vendita.
Anche qui vale la regola sulle fonti. Dove esistono dati verificabili sono citati con il link originale: le date di fine supporto del software, i requisiti PCI, le soglie dei circuiti di pagamento, le regole di Google e Yahoo sulle email, i numeri di Netcomm sui picchi stagionali. Dove non esistono, è detto: non esiste alcuna fonte primaria sul "costo medio di manutenzione di un eCommerce", né sul tasso medio di reso in Italia, né una pagina pubblica di Mastercard con le soglie dei chargeback. Sono tre numeri che troverai citati ovunque e che nessuno può verificare.
INDICE DEI CONTENUTI
- Il giorno dopo: da progetto a servizio
- Il contratto di manutenzione: cosa deve contenere
- Manutenzione tecnologica: il software invecchia a data certa
- Sicurezza in esercizio: cosa cambia dopo il lancio
- Magazzino, ordini e resi: dove il negozio tocca l'azienda
- Il catalogo vivo: prezzi, promozioni e feed
- Marketing in esercizio: cosa cambia dopo il lancio
- L'intelligenza artificiale in esercizio: dove rende e cosa va sorvegliato
- La conformità non finisce con il lancio
-
Gli strumenti della manutenzione e della misurazione
- Monitoraggio ed errori: accorgersene prima dei clienti
- Dipendenze e vulnerabilità: il lavoro noioso si automatizza
- Test automatici e rilasci: cinque prove che valgono un contratto
- Misurare le vendite: gli strumenti di statistica post-vendita
- Le prestazioni in esercizio: dati di laboratorio e dati di campo
- Perché i benchmark di settore non sostituiscono i tuoi numeri
-
I driver per scegliere chi fa la manutenzione
- Sviluppo e integrazione: il driver è la reperibilità dimostrabile
- Sicurezza: il driver è l'inventario, non l'audit una tantum
- Progettazione: il driver è lavorare su dati, non su opinioni
- Marketing: il driver è la continuità e la trasparenza sui dati
- Intelligenza artificiale: il driver è chi sorveglia il risultato
- Quanto costa mantenere: come si costruisce il budget annuale
- Quando smettere di manutenere e rifare
- Conclusioni
-
Domande frequenti
- Quanto costa mantenere un eCommerce all'anno?
- Cosa deve contenere un contratto di manutenzione?
- Ogni quanto vanno fatti gli aggiornamenti?
- Di chi è la responsabilità della sicurezza dei pagamenti?
- Come si riducono le contestazioni di pagamento?
- Perché le mie email finiscono nello spam?
- Quando conviene rifare il sito invece di mantenerlo?
Il giorno dopo: da progetto a servizio
Un negozio online fermo non è un disservizio: è fatturato che non entra, e in un'ora di picco può valere più di un mese di manutenzione. Questa asimmetria è l'unica cosa da tenere a mente quando si valuta un preventivo di assistenza: il costo della manutenzione va confrontato con il costo del fermo, non con il costo dello sviluppo. Un'azienda che fattura 30.000 euro al mese online perde circa mille euro al giorno di negozio chiuso, senza contare gli ordini che non torneranno.
Da qui discende la seconda regola: in esercizio conta più la velocità di ripristino della perfezione del codice. Un fornitore che risponde in due ore con una soluzione temporanea vale più di uno che risponde in due giorni con la soluzione elegante. La domanda da fare a chi ti propone manutenzione non è cosa farà, ma in quanto tempo si accorge di un problema e in quanto tempo ti richiama.
Il contratto di manutenzione: cosa deve contenere
È il documento che decide la qualità dei prossimi anni e di solito è mezza pagina. Ne servono tre, con quattro cose scritte per esteso.
Monte ore, tempo di risposta, reperibilità
Il monte ore serve a distinguere ciò che è incluso da ciò che si preventiva a parte, ed è la voce che rende prevedibile il costo. Va definito su base mensile o annuale, con la regola su cosa succede alle ore non usate: si perdono, si accumulano, si compensano. Un monte ore senza questa clausola produce discussioni ogni trimestre.
Il tempo di risposta va distinto per gravità, e la classificazione va scritta con esempi: il negozio non vende (bloccante), il negozio vende ma un pagamento su tre fallisce (grave), un'immagine non si vede (ordinario). A ogni livello corrisponde un tempo di presa in carico — che è una promessa verificabile — e non un tempo di risoluzione, che nessuno può garantire onestamente.
La reperibilità è la voce che quasi nessuno mette e che decide tutto durante i picchi: fuori orario, nei fine settimana e nelle settimane promozionali, chi risponde? Se la risposta è "di solito sono raggiungibile", non è un servizio: è una cortesia, e va prezzata come tale. Se il tuo negozio fa una quota rilevante di fatturato in due settimane di novembre, la reperibilità in quelle due settimane vale più di tutto il resto del contratto.
Cosa non è manutenzione (e va detto prima)
Manutenzione è tenere in funzione ciò che esiste: aggiornamenti, correzioni, ripristini, monitoraggio, piccoli adeguamenti. Non è evoluzione: una nuova funzione, un nuovo canale di vendita, un restyling non stanno nel monte ore e non devono starci, altrimenti finiscono per mangiare le ore che servivano a tenere il negozio sicuro.
La ricaduta organizzativa di confondere le due cose è sempre la stessa: il budget di manutenzione viene consumato da richieste di modifica, gli aggiornamenti slittano, e dopo un anno il sito gira su versioni fuori supporto. Tenere due voci separate — manutenzione ed evoluzione — è il singolo accorgimento contrattuale che protegge di più nel medio periodo.
Il passaggio di consegne che rende sostituibile il fornitore
Nessun rapporto dura per sempre, e la differenza fra cambiare fornitore in due settimane o in sei mesi è scritta nel contratto di manutenzione, non in quello di sviluppo. Servono tre condizioni attive durante il rapporto e non alla fine: il codice su un repository intestato a te, con il fornitore invitato come collaboratore; gli account intestati alla tua azienda — dominio, hosting, servizi di pagamento, strumenti di analisi, Merchant Center — con il fornitore aggiunto come utente; e le istruzioni per ricostruire l'ambiente da zero, provate almeno una volta.
Ricaduta. Queste tre righe non costano quasi nulla se scritte all'inizio e sono quasi impossibili da ottenere quando i rapporti si sono guastati. Sono anche la ragione per cui un freelance singolo può gestire in sicurezza un progetto che deve durare anni: non perché sia insostituibile, ma perché è sostituibile senza perdere il negozio.
Manutenzione tecnologica: il software invecchia a data certa
L'invecchiamento non è un'opinione: le date di fine supporto sono pubblicate anni prima. Ignorarle non produce un guasto immediato, produce un accumulo — e poi un aggiornamento grande, rischioso e costoso, di solito nel momento peggiore.
Le date che decidono per te
PHP pubblica un calendario preciso: la 8.2 ha finito il supporto attivo il 31 dicembre 2024 e riceve solo correzioni di sicurezza fino al 31 dicembre 2026; la 8.3 è in sola sicurezza fino a fine 2027; la 8.4 resta in supporto attivo fino a fine 2026 e in sicurezza fino al 2028. Laravel non ha più versioni LTS e applica una regola uniforme: 18 mesi di correzioni e 2 anni di patch di sicurezza — la 11 ha smesso di riceverle a marzo 2026, la 12 le riceve fino a febbraio 2027 e la 13 è uscita nel marzo 2026. Node.js ha chiuso la v20 il 30 aprile 2026.
Nel mondo WordPress la logica è diversa e va conosciuta: non esiste un calendario di fine vita e la policy dichiarata è che solo l'ultima versione è ufficialmente supportata, con i backport a rami vecchi trattati come cortesia — nel giugno 2025 il Security Team ha annunciato la fine degli aggiornamenti per le versioni 4.1–4.6. WooCommerce supporta l'ultima versione e la precedente, e per estensioni e temi solo l'ultima.
Ricaduta. Queste date vanno messe a calendario e trasformate in una voce di budget annuale, perché determinano quando servirà un intervento non rinviabile. Un negozio che gira su una versione fuori supporto non è "vecchio": è un negozio i cui problemi di sicurezza non verranno più corretti da nessuno, e per cui ogni estensione aggiornata diventa un rischio di incompatibilità.
Le estensioni sono la superficie d'attacco
Il dato più utile su questo punto viene dal report annuale di Patchstack, State of WordPress Security in 2026: 11.334 nuove vulnerabilità nel 2025, +42% sull'anno precedente, di cui il 91% nei plugin e il 9% nei temi, contro sei nel core. Va detto che è un report prodotto da un fornitore di sicurezza WordPress, quindi con un interesse commerciale, ma il perimetro metodologico è dichiarato e il dato è ad accesso libero.
La conclusione operativa non è "WordPress è insicuro": è che il rischio sta quasi tutto in ciò che aggiungi, e vale per qualunque piattaforma estendibile. Da qui due regole di gestione: ogni estensione installata va giustificata da una funzione che serve davvero, e l'inventario di ciò che è installato — con versione, autore e data dell'ultimo aggiornamento — va tenuto e riletto ogni trimestre. Le estensioni abbandonate dall'autore sono il primo problema da rimuovere, non l'ultimo.
Come si aggiorna senza rompere niente
Serve un ambiente di prova. Aggiornare in produzione sperando che vada bene è la causa più comune dei guasti gravi in esercizio: un ambiente di staging che replichi la produzione costa poche decine di euro al mese ed è la differenza fra un aggiornamento e una scommessa.
Servono finestre concordate. Gli aggiornamenti si fanno quando il negozio vende meno, mai il venerdì pomeriggio e mai in campagna promozionale. Il calendario va condiviso con chi fa marketing, perché è l'unico che sa quando parte una spedizione di email a ventimila persone.
Serve una via di ritorno. Prima di ogni aggiornamento: copia ripristinabile, procedura di rollback provata, e una lista di controllo di cinque minuti da eseguire dopo — home, ricerca, scheda prodotto, carrello, pagamento di prova. Il novanta per cento dei problemi post-aggiornamento si vede in quei cinque minuti, il resto lo trovano i clienti.
Sicurezza in esercizio: cosa cambia dopo il lancio
In fase di progetto la sicurezza è una questione di architettura; in esercizio è una questione di abitudini e di tempi di reazione. Quattro capitoli, in ordine di quanto costano quando vanno male.
Pagine di pagamento e script di terze parti: cosa è cambiato con PCI DSS 4
Lo standard di sicurezza dei pagamenti è oggi la versione 4.0.1, e i requisiti che erano "futuri" sono obbligatori dal 31 marzo 2025. Due riguardano direttamente chi gestisce un negozio: il 6.4.3, che impone di sapere quali script girano sulla pagina di pagamento e di autorizzarli uno a uno, e l' 11.6.1, che impone un meccanismo capace di accorgersi se quella pagina viene modificata senza permesso, con verifica almeno settimanale.
Per i negozi più piccoli, che si autocertificano con il questionario semplificato, il Council ha tolto quei requisiti dal SAQ A sostituendoli con un criterio di ammissione: il commerciante deve poter confermare che il sito non è suscettibile ad attacchi tramite script. La FAQ ufficiale chiarisce che la questione riguarda chi usa campi di pagamento incorporati in iframe — non chi reindirizza a una pagina del fornitore — e che si soddisfa in due modi: adottando le tecniche di 6.4.3 e 11.6.1, oppure ottenendo conferma scritta dal fornitore che la sua soluzione le include.
Ricaduta operativa. Ogni tag di marketing, widget di chat, script di raccomandazione o pixel che qualcuno aggiunge al sito è materia di questo requisito. Serve un inventario degli script attivi con chi li ha autorizzati e perché, e una regola aziendale su chi può aggiungerne. La causa più frequente di furto dei dati di carta non è la violazione del server: è uno script di terze parti manomesso, che continua a far funzionare il negozio mentre copia i dati altrove.
Accessi, segreti e backup: le tre cose noiose
Gli accessi vanno rivisti ogni trimestre, con una domanda sola: chi di questi non lavora più al progetto? Le utenze dei fornitori usciti restano attive per anni ed è una delle vie d'ingresso più banali. Autenticazione a due fattori obbligatoria per il pannello di amministrazione, e privilegi minimi: chi carica prodotti non deve poter installare estensioni.
I segreti — chiavi delle API, credenziali dei servizi di pagamento — non stanno nel codice e vanno ruotati quando qualcuno lascia il progetto. I backup vanno provati: l'unica domanda che conta è quando è stato ripristinato l'ultimo backup su un ambiente vuoto, e quanto tempo ci è voluto. Un backup mai ripristinato non è una copia di sicurezza, è un file.
Quando succede: le 72 ore e la procedura
Se una violazione riguarda dati personali, l'articolo 33 del GDPR impone la notifica all'autorità senza ingiustificato ritardo e, quando possibile, entro 72 ore dal momento in cui se ne è avuta conoscenza; se il rischio per le persone è elevato va informato anche l'interessato. In Italia la notifica passa esclusivamente dalla procedura telematica del Garante.
Tradotto in organizzazione: settantadue ore non sono il tempo per capire cosa è successo, sono il tempo per averlo già capito abbastanza da raccontarlo. Serve una procedura scritta di mezza pagina — chi viene avvisato, chi decide, chi parla con i clienti, dove stanno i log e per quanto tempo vengono conservati — e serve prima, perché scriverla mentre il negozio è sotto attacco non funziona.
Frodi e contestazioni: le soglie che ti mettono in un programma di monitoraggio
Le contestazioni non sono solo perdite: superate certe soglie fanno entrare il negozio nei programmi di monitoraggio dei circuiti, con costi aggiuntivi e, nei casi peggiori, la perdita del contratto di incasso. Il programma di monitoraggio Visa (VAMP), in vigore dal 1° giugno 2025, calcola un rapporto fra frodi e contestazioni sul totale delle transazioni: per l'Europa la soglia "eccessiva" era di 220 punti base con almeno 1.500 eventi al mese ed è scesa a 150 punti base dal 1° aprile 2026.
Su Mastercard, attenzione a ciò che leggi: non esiste una pagina pubblica di Mastercard con le soglie del programma sui chargeback. Le cifre più citate (cento contestazioni al mese e l'1,5% di rapporto) sono pubblicate da banche acquirer e fornitori di pagamento, non dal circuito. Se un consulente te le presenta come regole ufficiali, chiedi il link.
Ricaduta pratica. Il presidio antifrode è un lavoro continuo, non un'impostazione: soglie e regole vanno riviste quando cambiano assortimento, ticket medio o mercati serviti. E la prima riduzione delle contestazioni non arriva dagli strumenti, arriva dalle cose noiose — descrizione dell'addebito riconoscibile sull'estratto conto, email di conferma chiara, tracciamento della spedizione, assistenza che risponde. Molte contestazioni sono clienti che non ricordano di aver comprato da te.
Magazzino, ordini e resi: dove il negozio tocca l'azienda
È la parte che non si vede dal sito ed è quella che assorbe più ore di persone. Tre presidi quotidiani valgono più di qualunque funzione aggiuntiva.
La riconciliazione: il controllo che smaschera tutto
Ogni sera, tre numeri devono coincidere: gli ordini ricevuti sul sito, quelli arrivati nel gestionale e gli incassi accreditati dal fornitore di pagamento. Quando divergono, è quasi sempre una di quattro cose: una sincronizzazione ferma, un pagamento autorizzato ma non catturato, un ordine creato due volte, un rimborso non registrato.
La ricaduta di non farlo è subdola, perché non produce un guasto visibile: produce un magazzino che si scosta lentamente dalla realtà, e sei mesi dopo un inventario che non torna. Il controllo va automatizzato con un allarme, non lasciato alla buona volontà di qualcuno: se il numero degli ordini non corrisponde, deve arrivare un messaggio a una persona, la sera stessa.
I resi sono un processo, non una pagina del sito
Il consumatore ha quattordici giorni per recedere e due anni di garanzia legale di conformità: sono diritti che generano lavoro operativo continuo. Le domande da risolvere una volta e scrivere da qualche parte: chi autorizza il reso, in quanti giorni si rimborsa, chi controlla lo stato del prodotto che rientra, come rientra a magazzino, e chi emette la nota di credito.
Un avvertimento sulle cifre: non esiste una fonte primaria italiana o europea sul tasso medio di reso nell'eCommerce. Eurostat non lo rileva, Netcomm e l'Osservatorio non pubblicano un dato con metodologia dichiarata, e le percentuali che circolano — 20%, 30%, 50% nel fashion — provengono da fornitori di logistica inversa. Il solo tasso di reso che conta è il tuo, misurato per categoria: è anche l'unico modo per capire se il problema è il prodotto, la scheda o la taglia.
I picchi: quando il negozio fa in due settimane quello che fa in due mesi
Il dato italiano con metodologia dichiarata sui picchi promozionali è dell' Osservatorio eCommerce B2c Netcomm–Politecnico di Milano: nel periodo del Black Friday 2025 gli italiani hanno speso online 2,2 miliardi di euro (+7%), con 41,5 milioni di colli movimentati (+9%) pari al 4,8% del volume annuo, e uno sconto medio applicato del 25%.
La ricaduta è tutta organizzativa e va preparata almeno un mese prima: blocco degli aggiornamenti nelle settimane calde, verifica preventiva della tenuta dell'infrastruttura, reperibilità concordata per iscritto, magazzino e corriere avvisati, e assistenza clienti dimensionata. Il costo di un'ora di fermo il venerdì nero non è comparabile con quello di un'ora di fermo in un martedì di febbraio, e il contratto di manutenzione dovrebbe dirlo esplicitamente.
Il catalogo vivo: prezzi, promozioni e feed
Un catalogo non è un archivio: cambia ogni giorno, e ogni cambiamento tocca contemporaneamente gestionale, sito, feed pubblicitari e marketplace.
Prezzi e promozioni: l'obbligo che richiede uno storico
Ogni annuncio di riduzione deve indicare il prezzo più basso praticato nei trenta giorni precedenti, salve le eccezioni di legge. In esercizio significa che lo storico dei prezzi per variante va conservato e mostrato correttamente, e che chi carica le promozioni deve sapere come funziona la regola — perché l'errore tipico non è tecnico, è un'offerta lanciata a mano da chi non sapeva che il prezzo era già stato ritoccato la settimana prima.
Stessa logica per le recensioni: se le pubblichi devi dichiarare se e come verifichi che provengano da acquirenti reali. È una frase da scrivere una volta, ma va mantenuta vera quando cambia lo strumento che le raccoglie.
Il feed che si rompe in silenzio
Il feed prodotto è l'unico pezzo dell'infrastruttura che può smettere di funzionare senza che nessuno se ne accorga: il sito continua a vendere, ma le schede spariscono dagli annunci. Google sospende gli account per dichiarazioni non veritiere — con avvisi di 7 o 28 giorni, ma senza preavviso nelle violazioni gravi, come documenta la pagina ufficiale sulla misrepresentation — e la causa più comune di problemi è banale: prezzo o disponibilità sul sito diversi da quelli nel feed.
A questo si aggiungono le scadenze delle specifiche, che vanno seguite come si segue una normativa: l' aggiornamento della specifica prodotto del 14 aprile 2026 ha introdotto nuovi attributi di spedizione e il collegamento ai video, e prevede che dal 31 gennaio 2027 le immagini debbano essere almeno 500x500 pixel. Chi controlla lo stato del feed e con quale frequenza è una domanda da risolvere nel contratto, non da scoprire quando il traffico a pagamento crolla.
Marketing in esercizio: cosa cambia dopo il lancio
Dopo il go-live il marketing smette di essere un progetto di lancio e diventa un lavoro ricorrente con tre presidi: il traffico, i canali di proprietà e la misurazione.
Il traffico sta cambiando, e i numeri onesti sono pochi
Il dato con metodologia dichiarata sull'effetto delle risposte generative è quello del Pew Research Center, su quasi 69.000 ricerche reali: in presenza di un riepilogo generato il clic su un risultato tradizionale avviene nell'8% delle visite contro il 15% in sua assenza, e solo l'1% clicca la fonte citata. Google sostiene che il volume complessivo di clic verso i siti sia "relativamente stabile", senza pubblicare alcun numero; le statistiche zero-click che circolano provengono in gran parte da campioni proprietari senza metodo dichiarato.
La conseguenza gestionale non è drammatica ma è concreta: più la ricerca informativa perde clic, più valgono i canali che possiedi — clienti che tornano, email con consenso, marketplace, confronto prezzi — e più vale l'unica cosa che nessun riepilogo può sostituire, cioè una scheda prodotto che permette di comprare. Un negozio che dipende da una sola fonte di traffico ha un rischio di impresa, non un problema di marketing.
Email: le regole tecniche che decidono se arrivi nella posta in arrivo
Dal febbraio 2024 i requisiti di Google e Yahoo non sono consigli: chi invia oltre 5.000 messaggi al giorno a Gmail deve autenticare il dominio con SPF, DKIM e DMARC, offrire la disiscrizione con un clic nel formato tecnico previsto, e mantenere il tasso di segnalazioni spam sotto lo 0,30%, con l'indicazione di restare sotto lo 0,10%. Yahoo applica requisiti analoghi.
Ricaduta. È un lavoro di manutenzione, non di configurazione iniziale: le autenticazioni si rompono quando si cambia fornitore di invio, quando si aggiunge un nuovo servizio che manda email a nome tuo, quando si migra il dominio. Va monitorato il tasso di segnalazioni, e va tenuta la disciplina sulle liste — una lista comprata o vecchia di anni non produce vendite, produce reclami che poi fanno finire nello spam anche le conferme d'ordine. A questo si aggiunge, dal 29 ottobre 2026, il consenso richiesto dal Garante per i pixel che misurano aperture e clic.
Misurare: pochi numeri, tenuti nel tempo
Il presidio minimo è di quattro indicatori letti ogni mese sullo stesso perimetro: tasso di conversione per canale, valore medio dell'ordine, quota di clienti che tornano, e costo di acquisizione confrontato con il margine — non con il fatturato. Un dettaglio tecnico che pochi controllano: la conservazione dei dati in Google Analytics 4 è impostabile a 2 o 14 mesi per i dati a livello di utente, con il valore predefinito basso. Chi non lo alza si accorge dopo un anno che non può più confrontare la stagione con quella precedente.
Va ripetuto perché è la fonte di metà delle discussioni sui budget: non esiste un dato pubblico con metodologia dichiarata sul CPC medio italiano né sul costo di acquisizione medio nel retail. Gli unici parametri utili sono i tuoi, misurati nel tempo sullo stesso metodo.
L'intelligenza artificiale in esercizio: dove rende e cosa va sorvegliato
Le funzioni basate sull'IA non sono cose che si installano e si dimenticano: lavorano sui tuoi dati e cambiano comportamento quando i dati cambiano.
Dove rende: ricerca interna e assistenza
L'uso meno appariscente è il più redditizio, perché agisce su una perdita misurabile. L'aggiornamento di aprile 2026 dei benchmark di Baymard sulla ricerca interna misura che il 56% dei siti ha un'esperienza di ricerca mediocre o peggiore e che il 69% non gestisce gli errori di battitura. Un motore che capisce le query scritte male non è una funzione futuristica: è la riparazione di una perdita quotidiana, e il suo effetto si legge nei log delle ricerche senza risultato.
Gli altri usi che valgono un budget sono dello stesso tipo — normalizzare un catalogo importato da fornitori diversi, dedurre attributi mancanti, smistare e proporre risposte all'assistenza, segnalare ordini anomali. Il criterio di ammissione al budget è che esista un numero prima e un numero dopo: ricerche senza risultati, tempo medio di risposta, ore di data entry.
Cosa va sorvegliato ogni mese
Tre cose. Che l'assistente non inventi: politiche di reso, tempi di consegna e disponibilità devono venire dai tuoi dati, non dalla memoria del modello, e le risposte vanno campionate periodicamente da una persona. Che i contenuti generati non degradino il catalogo: descrizioni pubblicate senza revisione rendono le schede indistinguibili da quelle di chiunque altro. Che gli obblighi di trasparenza siano rispettati: dall'AI Act, applicabile su questo punto dal 2 agosto 2026, l'utente deve sapere che sta interagendo con un sistema automatico.
C'è poi una decisione che va rivista una volta l'anno: il commercio agentico. I protocolli esistono e si stanno muovendo — l'Agentic Commerce Protocol di OpenAI e Stripe, l'AP2 di Google — ma nessuno è ancora uno standard consolidato. La preparazione utile resta la stessa: catalogo strutturato, feed corretto, ordini leggibili e scrivibili via API. Sono anche le tre condizioni che servono per i marketplace e per le schede shopping, quindi non è una scommessa.
La conformità non finisce con il lancio
L'errore più costoso in questo capitolo è considerare gli obblighi come una casella spuntata il giorno del go-live. L'accessibilità è un requisito permanente: ogni modifica fatta dopo il 28 giugno 2025 ricade nell'obbligo, e le linee guida pubblicate da AgID nel marzo 2026 prevedono mantenimento della conformità nel tempo, dichiarazione di accessibilità, gestione delle segnalazioni e partecipazione al monitoraggio. Un tema aggiornato, un plugin nuovo, un banner promozionale possono rompere ciò che era conforme.
Lo stesso vale per il resto: i consensi vanno rivisti quando si aggiunge uno strumento; le informazioni obbligatorie sulle schede prodotto vanno mantenute quando cambia un fornitore; le scadenze normative note vanno messe a calendario come si fa con quelle fiscali. Nel breve periodo ce ne sono due: il consenso per i pixel nelle email entro il 29 ottobre 2026 e le regole di trasparenza sull'IA già applicabili. Un'ora al trimestre di revisione costa molto meno di un adeguamento fatto sotto contestazione.
Gli strumenti della manutenzione e della misurazione
Un negozio in esercizio si tiene in piedi con una cassetta degli attrezzi piccola e sempre la stessa. Qui sotto ci sono le categorie che servono davvero, con i prezzi pubblicati alla verifica del 28 agosto 2026: quasi tutte hanno una versione gratuita sufficiente per un negozio di dimensioni normali, e la spesa vera non è la licenza, è il tempo di chi legge quello che gli strumenti dicono.
Monitoraggio ed errori: accorgersene prima dei clienti
È la categoria che vale più di tutte le altre messe insieme, perché trasforma i guasti da "ce lo dice un cliente arrabbiato" a "arriva un messaggio". Per gli errori dell'applicazione lo strumento diffuso è Sentry, gratuito fino a 5.000 errori al mese con un utente e a 26 $ al mese per il piano Team. Per sapere se il sito risponde, UptimeRobot offre 50 controlli ogni cinque minuti nel piano gratuito, e Better Stack unisce controlli e raccolta dei log con un piano gratuito e i log a consumo. Grafana è gratuito se ospitato da te e ha un piano cloud gratuito con quattordici giorni di conservazione.
Ricaduta. Il valore non sta nell'installazione ma in tre decisioni: quali eventi generano un avviso, a chi arriva e in quale canale, e quali si guardano una volta a settimana senza svegliare nessuno. Un sistema che avvisa per tutto viene silenziato entro un mese, e a quel punto è come non averlo. Vanno sorvegliati almeno quattro segnali: sito irraggiungibile, errori dell'applicazione in aumento, pagamenti rifiutati sopra la media, e sincronizzazione con il gestionale ferma.
Dipendenze e vulnerabilità: il lavoro noioso si automatizza
Tenere aggiornate le librerie è manutenzione pura, e va automatizzata almeno nella parte di segnalazione. Su GitHub, Dependabot è gratuito e segnala le dipendenze con vulnerabilità note. Sul lato PHP il comando composer audit interroga l'archivio delle segnalazioni di Packagist e restituisce un codice di errore, quindi può essere messo nella catena di rilascio e bloccarla; l'equivalente per JavaScript è npm audit. Sono strumenti gratuiti e non usarli non ha giustificazioni tecniche: costa cinque minuti configurarli.
Sul mondo WordPress e WooCommerce esistono servizi specializzati, ed è utile conoscerne le condizioni prima di metterli a budget: Patchstack non ha un piano gratuito permanente e parte da 69 $ al mese, mentre WPScan ha un piano gratuito riservato all'uso non commerciale e limitato a venticinque chiamate al giorno: per un negozio serve una licenza a pagamento, il cui prezzo non è pubblicato.
Test automatici e rilasci: cinque prove che valgono un contratto
Gli stessi strumenti della fase di sviluppo servono in esercizio, e servono di più: PHPUnit o Pest per la logica, Playwright per simulare un acquisto reale dal browser, GitHub Actions per farli girare a ogni modifica. La differenza fra un fornitore di manutenzione affidabile e uno che incrocia le dita è se quei test esistono e se girano prima del rilascio, non quanti sono.
Le cinque prove che coprono il novanta per cento del rischio sono sempre le stesse: ricerca, scheda prodotto, aggiunta al carrello, checkout completo con pagamento di prova, ordine ricevuto dal gestionale. Chiedile come voce esplicita del contratto di manutenzione: sono poche ore una volta sola e ti risparmiano la telefonata del venerdì sera.
Misurare le vendite: gli strumenti di statistica post-vendita
Il gruppo Google è gratuito e copre la base: Analytics 4 per il comportamento e le conversioni, Search Console per la ricerca organica, Merchant Center per lo stato del feed e delle schede prodotto, Looker Studio per costruire un pannello unico. Un limite di GA4 va conosciuto perché condiziona le analisi: la versione gratuita conserva i dati a livello di utente per un massimo di quattordici mesi e limita a venticinque i parametri per evento — se vuoi confrontare due stagioni, o esporti verso un archivio tuo o perdi lo storico.
Le alternative e i complementi, tutti con prezzi pubblici: Matomo è gratuito se ospitato da te e parte da 29 € al mese in cloud, ed è la scelta tipica di chi vuole i dati sul proprio server per ragioni di privacy; PostHog ha un piano gratuito con un milione di eventi al mese e registra anche le sessioni; Microsoft Clarity è gratuito e mostra mappe di calore e registrazioni, utile per capire perché un passaggio del checkout perde persone; Hotjar, oggi parte di Contentsquare, ha un piano gratuito fino a 200.000 sessioni e uno a 49 $ al mese. Per le analisi che incrociano il gestionale con il negozio — margine per categoria, valore del cliente nel tempo, resi per fornitore — Metabase è gratuito se ospitato da te e parte da 100 $ al mese in cloud; se in azienda esiste già una soluzione di business intelligence come Power BI o Tableau, conviene collegarla invece di aggiungerne un'altra.
Ricaduta. Il rischio qui non è spendere troppo, è installarne troppi: ogni strumento aggiunge uno script alla pagina, un consenso da gestire e un dato personale in più da giustificare — e, sulla pagina di pagamento, ricade nell'inventario degli script richiesto dallo standard PCI. Tre strumenti letti ogni mese valgono più di otto installati e mai aperti.
Le prestazioni in esercizio: dati di laboratorio e dati di campo
Vanno tenute distinte due misure che quasi tutti confondono. I dati di laboratorio — Lighthouse, gratuito e integrato in Chrome — simulano una visita e servono a diagnosticare: dicono cosa rallenta una pagina. I dati di campo vengono dagli utenti reali attraverso il Chrome UX Report, alimentano PageSpeed Insights e sono quelli che contano per Google: sono la misura da usare nei contratti. Attenzione a un limite noto: i siti con poco traffico non hanno dati di campo, quindi su un negozio piccolo o appena lanciato si lavora con le misure di laboratorio e con quelle raccolte dal proprio sito.
Perché i benchmark di settore non sostituiscono i tuoi numeri
Vale la pena ripeterlo qui, perché è il punto in cui si prendono più decisioni sbagliate. Le statistiche più citate sugli strumenti e sulle tecnologie hanno metodologie che i loro stessi autori dichiarano limitate: le survey per sviluppatori sono campioni autoselezionati, le classifiche di popolarità dei database misurano menzioni e annunci di lavoro e non installazioni, le rilevazioni sulle quote di mercato delle piattaforme contano siti e non fatturato.
Servono a una cosa sola, ed è una cosa utile: capire quanto sarà facile trovare competenze e componenti. Per tutto il resto — conversione, resi, costo di acquisizione, margine per categoria — l'unico dato che descrive il tuo negozio è quello che raccogli tu, sullo stesso perimetro, mese dopo mese. Tre indicatori misurati male per due anni valgono più di venti misurati bene per un trimestre.
I driver per scegliere chi fa la manutenzione
I mestieri sono gli stessi della fase di progetto — progettazione, sviluppo e integrazione, sicurezza, intelligenza artificiale, marketing — ma i criteri di scelta cambiano, perché non stai comprando una consegna: stai comprando disponibilità nel tempo. Chi è ottimo a costruire non è automaticamente adatto a mantenere, e viceversa.
Sviluppo e integrazione: il driver è la reperibilità dimostrabile
Chiedi come lavora quando qualcosa si rompe: quali strumenti di monitoraggio installa, chi riceve l'allarme, che tempo di presa in carico mette per iscritto, e cosa fa se il problema è del fornitore di pagamento e non suo. Chiedi anche come gestisce gli aggiornamenti — se ha un ambiente di prova e una lista di controllo post-rilascio — e come documenta ciò che ha fatto: in un rapporto di manutenzione devono comparire ore, interventi e stato delle versioni, non un generico "attività di assistenza".
Sicurezza: il driver è l'inventario, non l'audit una tantum
Una verifica di sicurezza fatta una volta e mai più vale poco. Il profilo giusto è chi ti lascia con un inventario aggiornato — estensioni, script attivi sulla pagina di pagamento, utenze, chiavi — e una revisione periodica breve, invece di un rapporto lungo una volta l'anno. Domande decisive: come si accorge di un cambiamento non autorizzato sulla pagina di pagamento, quando è stato provato l'ultimo ripristino, chi ha ancora accesso e non dovrebbe.
Progettazione: il driver è lavorare su dati, non su opinioni
In esercizio il progettista utile non è quello che propone restyling: è quello che parte dai numeri già disponibili — abbandoni per passaggio del checkout, ricerche senza risultato, domande ricorrenti all'assistenza — e propone modifiche piccole e misurabili. Il driver è la disponibilità a lavorare per interventi da poche ore con una verifica dopo, invece che per progetti da tre mesi.
Marketing: il driver è la continuità e la trasparenza sui dati
Qui la differenza fra un professionista e un venditore la fa la proprietà degli account: gli strumenti pubblicitari, l'analisi e il Merchant Center devono essere intestati a te, con il fornitore come utente. Chiedi un rapporto mensile che confronti spesa e margine, non spesa e fatturato, e verifica che sappia spiegare cosa non ha funzionato. Chi presenta solo numeri in crescita sta selezionando i grafici.
Intelligenza artificiale: il driver è chi sorveglia il risultato
Le funzioni IA vanno riviste, non installate. Il driver è banale e quasi nessuno lo chiede: chi legge un campione di risposte ogni mese, con quale criterio, e cosa fa quando trova un errore. Se la risposta è che il sistema si controlla da solo, il presidio non esiste.
Quanto costa mantenere: come si costruisce il budget annuale
Anche qui va detto prima: non esiste alcuna fonte primaria sul costo medio di manutenzione di un eCommerce, e la percentuale "15-20% del costo di sviluppo" che si legge ovunque non ha campione né metodologia. Si costruisce, sommando cinque voci.
I canoni: piattaforma, hosting, ricerca interna, email transazionali, servizi esterni, certificati. Le commissioni sui pagamenti, che sono proporzionali e vanno stimate sul fatturato previsto: sono quasi sempre la voce più grande. Il monte ore di manutenzione tecnica, che va dimensionato sul numero di integrazioni e sul numero di estensioni installate, perché sono quelle a rompersi. Il lavoro delle persone: chi carica il catalogo, chi risponde ai clienti, chi gestisce i resi — di solito la voce più grande in assoluto e l'unica che nessuno mette nel budget del sito. L'acquisizione, che è un investimento e non un costo, ma va nel conto.
A queste va aggiunto un accantonamento per gli adeguamenti non rinviabili: una versione di PHP che esce di supporto, una specifica di feed che cambia, un obbligo normativo con una data. Non sono imprevisti: sono scadenze note in anticipo, e l'unica sorpresa è per chi non le ha messe a calendario.
Quando smettere di manutenere e rifare
Arriva il momento in cui manutenere costa più che ricostruire, e riconoscerlo tardi è caro. I segnali sono quattro e vanno guardati insieme, non presi singolarmente: ogni modifica richiede molte più ore di quante ne richiedeva un anno fa; le versioni fondanti sono fuori supporto e l'aggiornamento è bloccato da una dipendenza che nessuno aggiorna più; nessuno sa dire con certezza cosa succede toccando una certa parte; e il negozio non può fare cose che il mercato dà per scontate senza un lavoro sproporzionato.
Quando la decisione matura, la regola pratica è non rifare tutto insieme: si sostituisce un pezzo alla volta, partendo da quello che genera più lavoro manuale — spesso l'integrazione con il gestionale o il catalogo — mantenendo il resto in funzione. È più lento sulla carta e molto più rapido nei fatti, perché non ferma le vendite. E vale la stessa condizione della prima parte: si può fare solo se codice, account e dati sono tuoi.
Conclusioni
Se di questa seconda parte dovesse restare una riga: un eCommerce non si mantiene intervenendo quando si rompe, si mantiene con quattro presidi ricorrenti — la riconciliazione quotidiana fra sito, gestionale e incassi; l'aggiornamento programmato di ciò che ha una data di scadenza nota; il controllo di chi ha accesso e di cosa gira sulla pagina di pagamento; la lettura mensile di pochi numeri sullo stesso perimetro.
Il resto è contrattuale, e si scrive prima: monte ore separato dall'evoluzione, tempi di presa in carico per gravità, reperibilità nelle settimane che contano, account e codice intestati a te. Le cifre che troverai in rete su quanto costa mantenere non hanno fonte, esattamente come quelle sui costi di sviluppo: l'unico budget difendibile è quello costruito voce per voce sul tuo negozio, e l'unica statistica che conta davvero — sui resi, sulle conversioni, sul costo di acquisizione — è la tua.
Domande frequenti
Quanto costa mantenere un eCommerce all'anno?
Non esiste una risposta documentata: nessuna fonte primaria pubblica un costo medio di manutenzione, e la percentuale "15-20% del costo di sviluppo" che circola non ha campione né metodologia. Il budget si costruisce sommando cinque voci: canoni (piattaforma, hosting, ricerca interna, email, servizi esterni), commissioni sui pagamenti proporzionali al fatturato, monte ore di manutenzione tecnica dimensionato sul numero di integrazioni ed estensioni, lavoro delle persone che caricano il catalogo e gestiscono clienti e resi, e budget di acquisizione. Va aggiunto un accantonamento per gli adeguamenti con data nota, come una versione di PHP che esce di supporto.
Cosa deve contenere un contratto di manutenzione?
Quattro cose scritte per esteso: un monte ore con la regola su cosa succede alle ore non usate; i tempi di presa in carico distinti per gravità, con esempi concreti di cosa è bloccante e cosa no; la reperibilità fuori orario e nelle settimane promozionali; e la separazione netta fra manutenzione ed evoluzione, perché se le nuove funzioni consumano il monte ore, gli aggiornamenti slittano e dopo un anno il sito gira su versioni fuori supporto. Aggiungi le tre condizioni che ti rendono libero di cambiare fornitore: repository intestato a te, account aziendali, istruzioni provate per ricostruire l'ambiente.
Ogni quanto vanno fatti gli aggiornamenti?
Gli aggiornamenti di sicurezza vanno applicati appena disponibili; il resto si programma in finestre concordate, mai il venerdì pomeriggio e mai in campagna promozionale. La cadenza la decidono le date pubblicate dai fornitori: PHP 8.2 riceve solo patch di sicurezza fino al 31 dicembre 2026, Laravel garantisce 18 mesi di correzioni e 2 anni di sicurezza per versione, WooCommerce supporta l'ultima versione e la precedente. Servono comunque tre cose ogni volta: un ambiente di prova, una copia ripristinabile e una lista di controllo di cinque minuti dopo il rilascio — home, ricerca, scheda, carrello, pagamento di prova.
Di chi è la responsabilità della sicurezza dei pagamenti?
Del commerciante, anche quando i dati della carta non passano dal suo server. Con PCI DSS v4.0.1 i requisiti sugli script della pagina di pagamento sono obbligatori dal 31 marzo 2025: sapere quali script girano e autorizzarli (6.4.3) e accorgersi se la pagina viene modificata (11.6.1). Per i negozi che si autocertificano con il questionario semplificato quei requisiti sono stati sostituiti da un criterio di ammissione — poter confermare che il sito non è attaccabile tramite script — che riguarda chi usa campi di pagamento in iframe e si soddisfa anche con una conferma scritta del fornitore. In pratica: tieni un inventario degli script attivi e decidi chi può aggiungerne.
Come si riducono le contestazioni di pagamento?
Prima con le cose noiose: descrizione dell'addebito riconoscibile sull'estratto conto, email di conferma chiara, tracciamento della spedizione, assistenza che risponde. Molte contestazioni sono clienti che non ricordano di aver comprato da te. Poi con il presidio antifrode, che va rivisto quando cambiano assortimento, ticket medio o mercati. Le soglie contano: il programma di monitoraggio Visa, in vigore dal giugno 2025, ha portato la soglia europea per i commercianti da 220 a 150 punti base dal 1° aprile 2026. Su Mastercard, attenzione: le soglie citate ovunque non sono pubblicate dal circuito ma da banche e fornitori di pagamento.
Perché le mie email finiscono nello spam?
Quasi sempre per tre motivi tecnici e uno di disciplina. I tecnici: dominio non autenticato con SPF, DKIM e DMARC, disiscrizione con un clic assente nel formato previsto, autenticazioni rotte dopo un cambio di fornitore di invio. Quello di disciplina è il tasso di segnalazioni spam, che Google richiede sotto lo 0,30% raccomandando di restare sotto lo 0,10%: liste vecchie o comprate lo fanno salire e trascinano nello spam anche le conferme d'ordine. Dal 29 ottobre 2026 si aggiunge il consenso richiesto dal Garante per i pixel che misurano aperture e clic.
Quando conviene rifare il sito invece di mantenerlo?
Quando quattro segnali si presentano insieme: ogni modifica richiede molte più ore di un anno fa; le versioni fondanti sono fuori supporto e l'aggiornamento è bloccato da una dipendenza abbandonata; nessuno sa dire cosa succede toccando una certa parte; il negozio non può fare cose ormai date per scontate senza un lavoro sproporzionato. Quando la decisione matura, la regola è non rifare tutto insieme: si sostituisce un pezzo alla volta, partendo da quello che genera più lavoro manuale — spesso l'integrazione con il gestionale — mantenendo il resto in funzione. È possibile solo se codice, account e dati sono intestati a te.