Il problema non è il cliente che dà feedback. Il problema è il cliente che dà feedback nel modo sbagliato, nel momento sbagliato, senza una struttura che permetta di raccoglierli, consolidarli e applicarli in modo efficiente. Il risultato è quello che ogni agenzia conosce: il ciclo di revisione infinito. Prima revisione, seconda revisione, terza revisione con nuovi elementi che non erano stati menzionati nelle prime due, quarta revisione che riporta elementi già approvati e poi cambiati di nuovo.
Questo problema non si risolve con più pazienza o più ore di lavoro. Si risolve con un processo definito, comunicato al cliente prima che il progetto inizi, e applicato con coerenza durante tutta la durata del progetto. Le agenzie che hanno strutturato questo processo raccontano quasi sempre la stessa cosa: i cicli di revisione si dimezzano, il tempo totale di progetto si riduce e la relazione con il cliente migliora perché entrambe le parti sanno esattamente cosa aspettarsi.
Il problema alla radice: feedback aperti senza struttura
Qualche mese fa un’agenzia con cui lavoriamo ci ha raccontato una situazione che conoscevamo bene. Stava sviluppando il sito per uno studio di consulenza aziendale milanese. Il cliente era una persona sola, il titolare, ma durante il progetto aveva coinvolto la sua assistente, il suo commercialista e la moglie. Ognuno aveva mandato feedback separati via email in momenti diversi, su aspetti diversi, con priorità diverse. Dopo sei settimane di sviluppo e quattro round di revisione, il sito non era ancora approvato. Non perché fosse sbagliato: perché ogni revisione introduceva elementi nuovi che contraddicevano quelli approvati nel round precedente.
Il costo extra non fatturato per quell’agenzia era di circa venti ore di lavoro. Il cliente era convinto di stare ricevendo un servizio scadente. L’agenzia era esausta. Nessuno era soddisfatto, e il problema non era il design.
Quando si chiede a un cliente “dimmi cosa ne pensi” senza una struttura, si apre una porta senza cornice. Il cliente risponde qualsiasi cosa, in qualsiasi momento, su qualsiasi aspetto. “Mi piace ma il logo potrebbe essere un po’ più grande” arriva insieme a “mia moglie dice che il colore non va bene” insieme a “ho visto un sito ieri che aveva una cosa interessante, potresti aggiungere qualcosa di simile?” Sono tre categorie completamente diverse: una modifica tecnica, un’opinione soggettiva di un terzo non coinvolto, e una richiesta fuori scope. Se il processo non le distingue, finiscono tutte nella stessa lista di cose da cambiare e il progetto non finisce mai.
Il sistema delle due revisioni
La struttura più efficace che abbiamo visto funzionare nella pratica è semplice: due round di revisione inclusi nel processo standard, con regole chiare su cosa si può modificare in ciascuno.
Primo round: il cliente riceve la versione di staging del sito o del design e ha un tempo definito, tipicamente cinque o sette giorni lavorativi, per raccogliere tutti i feedback. Non feedback parziali mandati man mano che emergono: tutti i feedback in un unico documento consolidato. Il cliente deve raccogliere le opinioni di tutti i decisori interni prima di mandare il documento. Non si accettano feedback da persone che non erano state identificate come approvatori al momento dell’avvio del progetto.
Secondo round: dopo che le modifiche del primo round sono state applicate, il cliente ha un secondo periodo di revisione per verificare che le modifiche siano state implementate correttamente. Non per aggiungere nuovi elementi: solo per verificare quanto richiesto nel primo round.
Tutto quello che arriva dopo il secondo round è una modifica aggiuntiva fatturabile separatamente. Non come punizione, ma come conseguenza naturale del fatto che il lavoro era stato approvato e poi richiesto di essere modificato di nuovo.
Questo sistema funziona solo se viene comunicato chiaramente nel contratto e nel documento di avvio del progetto, prima che il lavoro inizi. Se lo si introduce durante il terzo ciclo di revisione, il cliente lo percepisce come un tentativo di bloccare le sue richieste invece che come un processo professionale.
Lo applichiamo anche internamente nel processo con le agenzie partner che ci affidano lo sviluppo. Quando consegniamo su staging, forniamo sempre un documento di feedback strutturato con le sezioni già predisposte e un termine di risposta definito. Le agenzie che lo usano sistematicamente chiudono i progetti in tempi mediamente inferiori del 30-40% rispetto a quelle che raccolgono il feedback in modo informale. Non è una stima: è quello che vediamo nei dati di progetto che monitoriamo internamente.
Gli strumenti che rendono il feedback raccoglibile
Il feedback verbale o via email è il nemico del processo. È frammentato, non tracciabile, soggetto a interpretazioni diverse e quasi impossibile da consolidare senza perdere qualcosa.
Gli strumenti che funzionano meglio per raccogliere feedback su design e siti web sono quelli che permettono di commentare direttamente sull’elemento visivo a cui il feedback si riferisce.
Per il design in Figma, i commenti integrati nella piattaforma permettono al cliente di cliccare su un elemento e aggiungere un commento contestuale. L’agenzia vede esattamente a cosa si riferisce il feedback senza ambiguità. Per i siti web su staging, strumenti come Usersnap o BugHerd permettono di annotare direttamente sulla pagina. Il cliente mostra il problema invece di descriverlo, eliminando la maggior parte delle incomprensioni che nascono quando il feedback è solo testuale.
Per le agenzie che preferiscono non aggiungere strumenti esterni, anche un Google Doc strutturato con sezione, elemento e descrizione del feedback funziona meglio di una catena di email. L’importante è che il feedback sia consolidato in un unico posto, non distribuito su email, WhatsApp, Zoom e telefonate.
Come gestire il cliente che bypassa il processo
Ogni agenzia ha incontrato questo cliente. Manda i feedback un po’ per volta invece di aspettare il documento consolidato. Chiama per comunicare modifiche verbali. Aggiunge nuovi elementi durante la seconda revisione come se fossero parte del primo round.
Ci è capitato direttamente con un progetto che seguivamo per un’agenzia partner. Il cliente mandava modifiche via WhatsApp alle undici di sera, chiamava per comunicare cambiamenti verbali e aveva coinvolto un “amico grafico” che aveva visto il sito su staging e aveva suggerimenti. Dopo il terzo intervento dell’amico, abbiamo suggerito all’agenzia di fare una cosa semplice: chiedere al cliente di mettere per iscritto, in un unico documento, tutti i feedback inclusi quelli dell’amico, con una scadenza di tre giorni.
Il cliente ha impiegato cinque giorni, ma ha mandato un documento con dodici punti chiari e ordinati. Ne abbiamo applicati dieci in un giorno. I due rimanenti erano fuori scope e sono stati fatturati separatamente senza discussione. Il progetto si è chiuso nella settimana successiva, dopo settimane di stallo.
La risposta al cliente che bypassa il processo non è rifiutare il feedback: è ricondurlo alla struttura con fermezza e gentilezza. “Ho ricevuto la tua email con i feedback. Li aggiungo al documento di revisione insieme a quelli che ricevo dagli altri stakeholder entro venerdì, poi procediamo con le modifiche del primo round insieme.” Non è un rifiuto: è una conferma che il feedback è stato ricevuto e sarà gestito nel modo corretto.
Il documento di avvio come prevenzione dei problemi
Il 90% dei problemi con i feedback si previene nel documento di avvio del progetto, non si risolve a metà progetto quando sono già emersi.
Un documento di avvio efficace definisce: chi sono i decisori finali sul design e sui contenuti, una persona sola e non un comitato, quanti round di revisione sono inclusi, cosa si intende per revisione e cosa si intende per modifica aggiuntiva, i tempi di risposta attesi dal cliente e dall’agenzia, e il processo di approvazione formale che segna la chiusura di ogni fase.
Non è un documento burocratico: è la mappa del progetto che entrambe le parti firmano prima di iniziare. Quando emergono incomprensioni a metà progetto, si torna a quella mappa invece di improvvisare. Quando il cliente prova ad aggiungere un quinto decisore a progetto avviato, quella mappa è la risposta più rispettosa che si possa dare.
Per approfondire come gestiamo i progetti in collaborazione con le agenzie partner, leggi come gestire i clienti quando lo sviluppo lo fa un partner esterno. Per capire come presentare al cliente un sito realizzato da terzi mantenendo credibilità, leggi l’articolo dedicato. Per approfondire come spiegare le scelte di design al cliente e farsele approvare, leggi l’articolo dedicato.
Su blurr.it/contatti/ puoi prenotare una chiamata per capire come strutturiamo il processo di revisione nei progetti che sviluppiamo per le agenzie partner.
FAQ
Due round di revisione è lo standard più diffuso e quello che funziona meglio nella pratica. Il primo round per raccogliere tutti i feedback consolidati dal cliente dopo la prima presentazione. Il secondo per verificare che le modifiche siano state implementate correttamente. Tutto quello che va oltre i due round è una modifica aggiuntiva da fatturare separatamente. Questo numero deve essere comunicato chiaramente nel preventivo e nel contratto prima dell’avvio del progetto, non introdotto quando i cicli di revisione sono già diventati un problema.
Con strumenti che permettono di commentare direttamente sull’elemento visivo a cui il feedback si riferisce: commenti in Figma per il design, strumenti come Usersnap o BugHerd per i siti su staging. In alternativa, un documento condiviso con sezione, elemento e descrizione del feedback. L’importante è che tutti i feedback siano consolidati in un unico documento prima di procedere con le modifiche, non distribuiti su email, chat e telefonate in momenti diversi.
Chiedendogli di consolidare tutto in un unico documento con una scadenza definita. Non come rifiuto ma come processo: i feedback vengono ricevuti, registrati e gestiti nel round corretto. Se arrivano dopo la chiusura del round, sono modifiche aggiuntive da quotare separatamente. Il processo deve essere stato comunicato e accettato prima dell’avvio del progetto: solo in quel contesto diventa uno strumento di gestione efficace invece che un conflitto.
Una sola persona, identificata prima dell’avvio del progetto. Non un comitato, non un team, non un decisore collettivo che include figure non coinvolte nel progetto. Quando i decisori sono multipli e non gerarchizzati, i feedback sono contraddittori e impossibili da applicare in modo coerente. Il documento di avvio deve specificare esplicitamente il nome della persona con potere di approvazione finale, e quella persona deve essere l’unico interlocutore per le approvazioni durante tutta la durata del progetto.