Curiosità
di Redazione Picenotime
Quali criteri contano davvero quando un'azienda sceglie chi realizzerà il suo sito? Quelli verificabili prima della firma: proprietà di dominio, codice e dati; approccio tecnico dichiarato; livelli di servizio dopo il lancio; metodo di progetto; soglie di performance misurabili; azioni tracciate; adempimenti presidiati. Il portfolio serve, ma racconta il passato. Questi criteri riguardano gli anni successivi alla pubblicazione.
Risposta secca, per chi sta confrontando due o tre preventivi in questi giorni: si scegliendo bene leggendo l'offerta come farebbe un ufficio acquisti davanti a un fornitore critico. Chi possiede cosa a fine progetto, entro quante ore si intervieni in caso di guasto, quali fasi e approvazioni sono previste, con quali numeri si collauda la velocità, quali azioni vengono tracciate, quali documenti e requisiti sono inclusi. Se queste sette risposte sono scritte, il confronto diventa possibile. Se restano verbali, si sta comparando solo il prezzo.
Proprietà: dominio, accessi, codice e dati intestati all'azienda committente.
Approccio: su misura o impianto preconfezionato, dichiarato apertamente e con i suoi compromessi.
Livelli di servizio: manutenzione programmata e assistenza espresse in ore e giorni lavorativi, non in aggettivi.
Metodo: fasi riconoscibili, approvazioni formali, regole scritte per le richieste fuori perimetro.
Performance: obiettivi numerici sulle metriche di esperienza utente, con strumenti di verifica indicati.
Misurazione: azioni da tracciare definite prima del design, con reportistica leggibile e periodica.
Conformità: documenti legali, gestione del consenso e requisiti di accessibilità inseriti nel collaudo tecnico.
Chi raccoglie preventivi in un mercato affollato come quello milanese si accorge presto di un problema di traduzione. Le offerte usano le stesse parole per indicare cose diverse: assistenza, ottimizzazione, manutenzione. Cambia il perimetro, cambiano i deliverable, cambia il numero di ore implicite. Alla fine la decisione rischia di appoggiarsi sui due soli elementi immediatamente leggibili, l'estetica delle referenze e la cifra in fondo alla pagina.
Una precisazione utile riguarda la geografia, perché allarga il campo delle opzioni. Per un responsabile marketing a Milano la prossimità fisica pesa meno di quanto si creda: riunioni, condivisione dei prototipi, ambienti di test e rilasci avvengono in remoto da anni, e il bacino di scelta include professionisti che operano da altre città. Un esempio: Alberto Di Meo si presenta come web designer a Torino e dichiara di realizzare siti internet ed eCommerce su misura, evitando soluzioni copia e incolla; nel suo sito pubblica una sezione di progetti realizzati. Sono dichiarazioni di metodo, e come tali vanno trattate: interessanti nella misura in cui sono ispezionabili.
Perché è proprio questo il punto. Il sito raccoglie richieste di preventivo, prenotazioni, candidature, ordini; alimenta il CRM; genera i dati che finiscono nelle piattaforme pubblicitarie. Quando smette di funzionare, o quando l'azienda perde il controllo degli accessi, il danno è operativo e commerciale, non decorativo. Il metro di giudizio corretto somiglia quindi a quello di chi valuta un fornitore critico: cosa mi consegni, cosa possiedo io alla fine, con quali tempi intervieni, come dimostri che il lavoro ha prodotto effetti.
Un consiglio operativo elementare, e che funziona: scegliete tre lavori dal portfolio di ciascun candidato, apriteli da smartphone su rete mobile, provate a compilare un modulo di contatto, guardate come sono organizzati i menu. Dieci minuti di test dicono più di un'ora di presentazione commentata.
La domanda da porre nella prima call è secca: al termine del progetto, cosa resta intestato a me? Un elenco minimo di verifica comprende il dominio registrato a nome dell'azienda e non del fornitore, le credenziali amministrative del CMS, l'accesso al pannello dell'hosting, il codice sorgente o quantomeno un backup completo esportabile, le licenze dei componenti a pagamento con indicazione di quali sono trasferibili, la titolarità delle proprietà analitiche.
Il problema si manifesta quasi sempre in differita. Un'azienda decide di cambiare partner dopo tre anni e scopre che il dominio risulta intestato allo studio precedente, che il tema è proprietario e non esportabile, che i contenuti vivono dentro un pannello chiuso privo di funzione di esportazione. Non è per forza malafede: spesso è un'abitudine consolidata che nessuno ha messo in discussione. Il costo, però, lo sostiene il committente, e può tradursi in giorni o settimane di lavoro aggiuntivo per ricostruire ciò che esisteva già.
Lo stesso ragionamento vale per i dati. Proprietà di analytics, contenitore dei tag, pixel pubblicitari e caselle che ricevono i moduli di contatto andrebbero creati sotto account aziendali, con il fornitore invitato come utente autorizzato. È una differenza minima in fase di configurazione e sostanziale nel momento della separazione. Un modo utile per testare la trasparenza di un interlocutore è chiedergli di mettere per iscritto, dentro il preventivo, l'elenco delle credenziali che verranno consegnate alla chiusura: chi lavora in modo ordinato non ha ragione di esitare.
Tra un sito costruito su un tema commerciale e uno sviluppato da zero non esiste un vincitore assoluto. Esistono contesti. Per una vetrina istituzionale di cinque pagine, un impianto standard ben configurato può essere una scelta economicamente sensata e perfettamente dignitosa. Per un eCommerce con logiche di catalogo particolari, o per un'azienda che punta su un'identità visiva riconoscibile, l'assemblaggio di componenti generici tende a produrre un debito tecnico che si paga in rigidità e in tempi di caricamento.
Quello che conta in sede di valutazione è che il fornitore espliciti l'approccio e ne mostri le conseguenze, anche quelle scomode: quanti componenti di terze parti verranno installati, quali sono a canone annuale, cosa succede se uno di essi viene abbandonato dal suo sviluppatore. Un preventivo che tace su questi punti non è più economico, è soltanto meno dettagliato. E la differenza emerge al primo aggiornamento importante del CMS.
La pubblicazione non è la fine del progetto, è l'inizio dell'esercizio. Conviene distinguere due attività che spesso finiscono sotto la stessa voce. La manutenzione programmata è l'insieme delle operazioni pianificate: aggiornamento del CMS e dei componenti, backup verificati, monitoraggio della raggiungibilità, revisione periodica degli utenti, interventi di irrobustimento. L'assistenza è invece la risposta a un evento non previsto. Il sito è irraggiungibile. Il modulo contatti smette di inviare il venerdì sera. Un aggiornamento ha rotto la pagina dei servizi.
Per rendere comparabili le offerte servono numeri. Tre parametri bastano: tempo massimo di presa in carico distinto per gravità dell'incidente, finestra oraria di copertura, obiettivo di ripristino in caso di fermo. A questi va aggiunta una domanda che quasi nessuno pone in trattativa: i backup sono stati ripristinati per prova, e quando è avvenuto l'ultimo test? Un backup non verificato è un'ipotesi, non una procedura di continuità.
Chiedete anche se esiste un ambiente di test separato dal sito pubblico. Applicare aggiornamenti direttamente in produzione su un negozio online attivo è una pratica che può funzionare per mesi e poi costare molto in un pomeriggio di alta stagione.
I progetti web raramente si arenano per incapacità tecnica. Si arenano per contenuti che non arrivano, revisioni che si moltiplicano e responsabilità non assegnate. Un metodo credibile prevede fasi riconoscibili — analisi degli obiettivi, architettura delle informazioni, prototipi, interfaccia, sviluppo, collaudo, pubblicazione — e per ciascuna un punto di approvazione formale, anche solo una mail di accettazione.
Le domande che riducono il rischio sono concrete. Quante tornate di revisione sono incluse sui prototipi e quante sulla grafica? Chi scrive i testi: il fornitore, l'azienda, un copywriter esterno? Chi produce le fotografie? Chi carica i contenuti nelle pagine, e quante schede prodotto sono comprese nel prezzo? Come viene gestita una richiesta che esce dal perimetro iniziale, con quale impatto dichiarato su tempi e costi?
Un documento di poche pagine che fissa perimetro, ruoli e criteri di accettazione vale più di qualunque rassicurazione verbale. Protegge entrambe le parti, fornitore incluso, dalla deriva progressiva delle aspettative. Chi tiene un registro delle decisioni prese, con data e motivazione, riesce anche a spiegare a distanza di mesi perché una certa scelta è stata fatta: è tracciabilità elementare, e costa pochi minuti per riunione.
Qui il terreno diventa misurabile, ed è un vantaggio per chi compra. I Core Web Vitals sono un insieme di metriche che misurano l'esperienza utente reale su tre dimensioni: prestazioni di caricamento, interattività e stabilità visiva della pagina. La documentazione di Google Search Central raccomanda ai proprietari di siti di mantenere buoni valori su queste metriche per ottenere il meglio dalla ricerca e garantire un'ottima esperienza utente, in linea con ciò che i sistemi di ranking principali tendono a premiare.
Le soglie indicate come obiettivo di buona esperienza sono tre: LCP entro 2,5 secondi dall'inizio del caricamento della pagina, INP inferiore a 200 millisecondi, CLS inferiore a 0,1 (riferimenti aggiornati a dicembre 2025). Sono numeri che possono entrare in un capitolato. Anziché scrivere che il sito sarà veloce e ottimizzato, si può stabilire che le pagine principali dovranno collocarsi entro quelle soglie nei test al momento della consegna, indicando lo strumento e il tipo di dispositivo usato per la verifica.
Sul metodo di misurazione conviene essere precisi, perché è lì che nascono i malintesi. Il report Core Web Vitals disponibile in Search Console si basa su dati di utilizzo reali e raggruppa le pagine per stato — scarso, da migliorare, buono — per tipo di metrica e per gruppi di URL simili. Due conseguenze pratiche. In quel report possono comparire soltanto URL indicizzate. E su un sito appena pubblicato la dicitura che segnala l'assenza di dati disponibili è un esito normale: la proprietà è nuova, oppure il volume raccolto non è sufficiente a fornire informazioni significative per quel tipo di dispositivo. Per questo la verifica alla consegna si esegue su singole URL con strumenti come PageSpeed Insights e Lighthouse, mentre il monitoraggio sui dati di campo diventa leggibile nei mesi successivi. Chi promette risultati sui dati reali il giorno del lancio sta descrivendo qualcosa che tecnicamente non esiste ancora.
Le fonti di degrado più frequenti sono note e vanno discusse in fase di offerta: immagini non ottimizzate, accumulo di plugin, script di terze parti caricati senza criterio, caratteri tipografici serviti male, hosting sottodimensionato rispetto al traffico previsto. Un fornitore che affronta questi punti spontaneamente sta mostrando il proprio metodo di lavoro, non vendendo una funzionalità aggiuntiva.
La domanda da porre all'inizio non è quante pagine avrà il sito, ma quali azioni deve produrre. Richieste di preventivo, chiamate, prenotazioni, ordini, candidature: la risposta orienta la gerarchia dei contenuti e la struttura delle pagine molto più della tavolozza cromatica.
Sul piano operativo, un insieme minimo di azioni da tracciare comprende l'invio dei moduli, i clic sul numero di telefono e sui contatti di messaggistica, i download di materiali commerciali e, per l'eCommerce, i passaggi del percorso d'acquisto fino alla conferma d'ordine. Va concordato chi configura questi eventi, chi ne verifica il funzionamento dopo il lancio e con quale cadenza arriva un rapporto leggibile. Un report mensile di tre pagine, commentato da chi lo ha prodotto, genera decisioni. Un pannello pieno di grafici che nessuno apre genera soltanto l'impressione del controllo.
Un dettaglio spesso trascurato riguarda la qualità del dato a monte. Se il modulo contatti non distingue le richieste commerciali dall'assistenza, o se le chiamate arrivano su un numero non tracciato, il report dirà poco anche con la migliore configurazione tecnica. Vale la pena mappare il percorso completo, dal clic alla risposta commerciale, e individuare il punto di rottura in cui l'informazione si perde: di solito è un passaggio di consegne tra marketing e vendite, non un problema di software.
Il perimetro degli adempimenti va chiarito in fase contrattuale, perché determina attività reali e ore di lavoro. Su questo terreno, però, un articolo può solo indicare dove guardare. In un transcript divulgativo sul tema si indica come dotazione minima per un negozio online tre documenti legali: informativa privacy, termini di vendita e cookie policy. Sull'accessibilità dei servizi digitali rivolti ai consumatori esistono linee guida AgID (versione 1.0, marzo 2026) che affrontano interpretazione e attuazione degli obblighi anche per il commercio elettronico: materia in evoluzione, la cui applicazione al proprio caso va verificata con un consulente legale e non desunta da una sintesi giornalistica.
Quello che interessa nella scelta del fornitore è la parte tecnica, ed è perfettamente verificabile. Chiedete se nel collaudo sono previsti: contrasti cromatici conformi, navigazione completa da tastiera, testi alternativi sulle immagini, struttura semantica delle intestazioni, etichette esplicite sui campi dei moduli, messaggi di errore leggibili anche da tecnologie assistive. Chiedete inoltre chi installa e configura lo strumento di gestione del consenso, chi pubblica i documenti forniti dal legale e chi verifica che gli script di marketing non partano prima dell'accettazione.
Se questi punti compaiono nel preventivo come criteri di accettazione, siete davanti a un processo. Se emergono soltanto quando siete voi a nominarli, la circostanza non squalifica nessuno, ma indica che quelle attività andranno negoziate e pagate a parte: meglio saperlo prima della firma che a collaudo aperto.
Il confronto funziona solo se si impone lo stesso schema a tutti i candidati. Prima di inviare la richiesta, preparate un documento di due pagine con obiettivi di business, numero indicativo di pagine e modelli, integrazioni necessarie, chi fornisce testi e immagini, aspettative di manutenzione. Poi chiedete a ciascuno di rispondere su queste voci, possibilmente nello stesso ordine:
elenco dei deliverable e di ciò che resta escluso, con attenzione a testi, fotografie, traduzioni e caricamento contenuti;
numero di modelli di pagina e di componenti riutilizzabili, perché determina la flessibilità futura;
credenziali e proprietà consegnate alla chiusura, con distinzione tra licenze trasferibili e licenze legate al fornitore;
livelli di servizio post-lancio, con tempi espressi in ore o giorni lavorativi e finestra di copertura;
costi ricorrenti annui: hosting, dominio, licenze, manutenzione, eventuali canoni di piattaforma;
tariffa oraria per le attività evolutive fuori perimetro e modalità di autorizzazione preventiva;
criteri di collaudo su performance e accessibilità, con strumenti di verifica indicati;
formazione prevista per il personale interno e documentazione rilasciata.
La stessa griglia, portata a voce nella medesima call, dice molto anche per la prontezza con cui arrivano le risposte. Chi lavora con procedure già in uso cita numeri, nomi di strumenti, esempi di casi chiusi. Un segnale da annotare, invece, è lo spostamento del discorso sul rapporto personale e sulla fiducia reciproca ogni volta che si chiede un dettaglio contrattuale: la fiducia, in un progetto, si costruisce proprio scrivendo queste cose nero su bianco.
Chi acquista un progetto web compra due cose sovrapposte: un prodotto, che si vede subito, e un processo, che diventa visibile quando qualcosa va storto. Proprietà documentata, livelli di servizio espressi in numeri, fasi di lavoro con approvazioni formali, obiettivi di performance verificabili con strumenti pubblici, azioni tracciate e rendicontate, documenti e requisiti tecnici inseriti nel collaudo. Sono elementi che si possono chiedere, scrivere e controllare prima di firmare, indipendentemente dalle dimensioni dell'azienda e dal budget disponibile.
Il portfolio resta importante, perché è la prova che qualcuno sa fare. Da solo, però, racconta il passato. I criteri descritti qui riguardano gli anni successivi alla pubblicazione, l'orizzonte in cui un sito aziendale produce valore oppure diventa una voce di costo da rifare. Chi arriva al tavolo con queste risposte già pronte, e le mette per iscritto senza che glielo si chieda, di solito è anche l'interlocutore che durante il progetto riserverà meno sorprese.
commenti 0****
