Il cliente che non sente notizie per tre settimane non è un cliente tranquillo. È un cliente che sta iniziando a preoccuparsi, a mandare email con tono sempre più teso, o peggio a parlare con un’altra agenzia.
La comunicazione durante lo sviluppo è uno dei punti dove le agenzie perdono più clienti, non per errori tecnici ma per silenzio. Il progetto può procedere benissimo internamente, i tempi possono essere rispettati, il risultato può essere esattamente quello concordato: se il cliente non lo sa, la sua percezione è che qualcosa stia andando storto.
Non è una questione di fiducia personale. È una questione di processo. Le agenzie che strutturano la comunicazione durante lo sviluppo hanno meno richieste di aggiornamento urgenti, meno telefonate di controllo, e clienti che al momento della consegna sono già allineati con quello che vedranno.
Perché il silenzio è il problema principale
Un’agenzia di Bologna che seguivamo aveva un problema ricorrente: clienti che a metà sviluppo chiedevano di rivedere tutto il brief. Non perché il lavoro fosse sbagliato, ma perché nel vuoto di comunicazione si erano convinti che la direzione presa fosse diversa da quella che avevano immaginato.
Il fondatore ci ha raccontato che lo stesso cliente che aveva approvato il wireframe senza obiezioni, tre settimane dopo senza aggiornamenti nel mezzo, pretendeva modifiche strutturali sostanziali. Aveva riempito il silenzio con aspettative che non corrispondevano a quello che stava per ricevere.
Da quando quella agenzia ha introdotto un aggiornamento settimanale fisso, le richieste di modifica post-consegna si sono ridotte di circa il 40%. Non avevano cambiato il modo di lavorare. Avevano cambiato il modo di comunicare.
La cadenza giusta non è quella massima
L’errore opposto al silenzio è l’aggiornamento ossessivo: un messaggio al giorno, notifiche continue su ogni piccola decisione, richieste di approvazione per dettagli che il cliente non è in grado di valutare. Stanca il cliente, lo spinge a micro-gestire il progetto, e crea una dipendenza dal feedback che rallenta lo sviluppo.
La cadenza che funziona su quasi tutti i progetti che gestiamo è settimanale. Un aggiornamento ogni sette giorni, in un formato fisso, in un canale concordato all’inizio del progetto. Il cliente sa quando aspettarsi notizie, non deve chiederle, e il team può lavorare senza interruzioni nel mezzo della settimana.
Per progetti con fasi critiche, come il lancio di un ecommerce o la migrazione di un sito con molto traffico, la cadenza può diventare bisettimanale nelle settimane più dense. Ma come regola di base, settimanale è sufficiente per quasi tutti i contesti.
Cosa includere nell’aggiornamento settimanale
Il formato conta quanto la cadenza. Un aggiornamento vago del tipo “i lavori procedono” è quasi inutile: non dà al cliente elementi concreti, non riduce l’ansia, e non previene le telefonate.
L’aggiornamento efficace ha tre componenti fisse. La prima è cosa è stato fatto questa settimana: specifico, con riferimento a elementi visibili o verificabili. Non “abbiamo lavorato sul frontend” ma “abbiamo completato il template della homepage e delle pagine categoria, visibile in staging”. La seconda è cosa succede la prossima settimana: crea aspettativa positiva e orienta l’attenzione del cliente verso il futuro invece che verso possibili ritardi. La terza è cosa serve dal cliente in quel momento preciso: una risposta, un’approvazione, un contenuto da fornire. Questa parte è fondamentale perché sposta parte della responsabilità sul cliente e documenta eventuali rallentamenti causati da mancanze sue.
Noi di Blurr, quando lavoriamo in white label per le agenzie partner, forniamo aggiornamenti in questo formato direttamente all’agenzia, che poi li gira al cliente con il proprio brand. È un elemento del nostro processo standard che le agenzie apprezzano particolarmente perché gli risparmia il lavoro di dover chiedere a noi “a che punto siamo” prima di rispondere al cliente.
Il canale: email, non chat
La scelta del canale di comunicazione ha impatto diretto sulla qualità della relazione durante lo sviluppo. Le chat (WhatsApp, Telegram, Slack) creano aspettativa di risposta immediata, rendono difficile tenere traccia di decisioni prese, e mescolano urgente con non urgente in modo che genera confusione.
L’email settimanale è lo strumento giusto per gli aggiornamenti di avanzamento: è asincrona, è documentata, e stabilisce implicitamente una cadenza invece di un canale sempre aperto. Il cliente può leggerla quando vuole, rispondere con calma, e non si aspetta una risposta entro l’ora.
La chat rimane utile per comunicazioni urgenti reali, come un problema tecnico emerso durante lo sviluppo o una decisione che blocca il lavoro. Ma come canale principale di aggiornamento progetto genera più problemi di quanti ne risolva, soprattutto su progetti che durano settimane o mesi.
Il momento peggiore per comunicare un problema
C’è un caso specifico in cui la gestione della comunicazione diventa critica: quando qualcosa va storto, o quando ci sono ritardi rispetto alla timeline concordata.
L’istinto di molte agenzie è aspettare di avere la soluzione prima di comunicare il problema. È comprensibile: non si vuole allarmare il cliente senza avere qualcosa di concreto da offrire. Ma nella pratica questa scelta quasi sempre peggiora le cose, perché il cliente scopre il ritardo tardi, spesso senza preavviso, e lo percepisce come occultamento invece che come gestione.
Il modo corretto è comunicare il problema appena è chiaro che impatterà sulla timeline, anche senza avere ancora la soluzione completa. Un messaggio del tipo “ci siamo imbattuti in un problema con l’integrazione del gestionale che richiede più tempo del previsto, ti aggiorniamo entro domani con i nuovi tempi” è molto più efficace di un silenzio seguito da una comunicazione di ritardo a cose fatte.
Abbiamo visto questa dinamica su un progetto ecommerce gestito per un’agenzia di Padova: un problema con l’API del corriere ha spostato la data di lancio di cinque giorni. L’agenzia ha comunicato il ritardo con anticipo, ha spiegato la causa, ha proposto una data alternativa. Il cliente ha risposto con comprensione. Lo stesso ritardo comunicato il giorno prima del lancio previsto avrebbe quasi certamente generato una crisi.
Come strutturare la comunicazione se lavori con un partner tecnico
Se l’agenzia gestisce il cliente ma il lavoro tecnico lo fa un partner esterno come Blurr, la comunicazione interna tra agenzia e partner deve essere altrettanto strutturata di quella esterna con il cliente.
Il rischio tipico è che l’agenzia faccia da filtro passivo: aspetta che il cliente chieda, poi chiede al partner, poi gira la risposta. Questo schema crea ritardi, genera doppio lavoro e mette l’agenzia in una posizione di costante rincorsa.
Il modo migliore è concordare con il partner tecnico gli stessi aggiornamenti settimanali fissi che si danno al cliente, riceverli in anticipo rispetto all’aggiornamento al cliente per poterli rielaborare, e usarli come base per la comunicazione esterna. Se vuoi capire come strutturiamo questo flusso con le agenzie che lavorano con noi, scrivici da blurr.it/contatti/: è una delle prime conversazioni che facciamo prima di iniziare un progetto.
Sull’argomento più ampio della gestione del rapporto con il cliente durante lo sviluppo, vale la pena leggere anche il nostro articolo su come gestire i feedback sul design con un partner esterno e quello su cosa succede quando il cliente cambia agenzia per capire i segnali da non ignorare.
Domande frequenti
Una volta a settimana è la cadenza giusta per la maggior parte dei progetti web. Più frequente stanca il cliente e lo invita alla micro-gestione. Meno frequente crea vuoti di comunicazione che generano ansia. Per fasi critiche del progetto, come il periodo prima del lancio, si può passare a due aggiornamenti a settimana per qualche giorno.
Email, senza eccezioni per gli aggiornamenti formali di avanzamento. L’email è asincrona, documentata e non crea aspettativa di risposta immediata. La chat va bene per comunicazioni urgenti e per domande rapide, ma usarla come canale principale degli aggiornamenti genera confusione e rende impossibile tenere traccia delle decisioni prese nel tempo.
Prima possibile, non quando il ritardo è già avvenuto. Un’agenzia che comunica un problema con anticipo, spiega la causa e propone una soluzione alternativa viene percepita come professionale. Un’agenzia che comunica il ritardo all’ultimo momento, o peggio quando il cliente se ne accorge da solo, viene percepita come inaffidabile, indipendentemente dal motivo del ritardo.
Dipende dal cliente e dal tipo di progetto. L’accesso allo staging può ridurre le sorprese alla consegna, ma su clienti che tendono alla micro-gestione può generare richieste continue di modifica su elementi non ancora finiti. La soluzione intermedia che funziona meglio è condividere screenshot o registrazioni video delle sezioni completate negli aggiornamenti settimanali, senza dare accesso diretto allo staging fino a quando il progetto non è in uno stato sufficientemente avanzato.