La diagnosi del sito web SaaS che la tua agenzia può riutilizzare senza rendere i clienti tutti uguali

Sintesi

Quante volte in questo trimestre hai svolto la stessa identica call di scoperta—stesse domande sul prodotto, sul cliente, sul concorrente—per due clienti che insistevano di essere completamente diversi? Sai già che le risposte saranno diverse, ma i compiti che ogni sito SaaS deve svolgere non lo sono. Ogni sito web di prodotto SaaS è un piccolo insieme di macchine che eseguono gli stessi compiti: spiegare cosa fa il prodotto, mostrare quanto costa, dire agli sviluppatori come integrarlo, rispondere alle obiezioni che bloccano l'acquisto e dimostrare che l'azienda è credibile. Una diagnosi ripetibile che verifica questi cinque compiti sopravviverà al contatto con qualsiasi cliente, perché i compiti non cambiano. Il sistema che costruisci attorno ad essa è ciò che ti permette di passare da un incarico all'altro senza ricominciare da zero. Richiede meno tempo del tuo attuale processo di scoperta, dà al cliente un chiaro motivo per fidarsi di te e produce un deliverable che non sembra un template, perché le domande sono standard ma le risposte sono specifiche.

Quante volte in questo trimestre hai svolto la stessa identica call di scoperta—stesse domande sul prodotto, sul cliente, sul concorrente—per due clienti che insistevano di essere completamente diversi? Sai già che le risposte saranno diverse, ma i compiti che ogni sito SaaS deve svolgere non lo sono. Ogni sito web di prodotto SaaS è un piccolo insieme di macchine che eseguono gli stessi compiti: spiegare cosa fa il prodotto, mostrare quanto costa, dire agli sviluppatori come integrarlo, rispondere alle obiezioni che bloccano l'acquisto e dimostrare che l'azienda è credibile. Una diagnosi ripetibile che verifica questi cinque compiti sopravviverà al contatto con qualsiasi cliente, perché i compiti non cambiano. Il sistema che costruisci attorno ad essa è ciò che ti permette di passare da un incarico all'altro senza ricominciare da zero. Richiede meno tempo del tuo attuale processo di scoperta, dà al cliente un chiaro motivo per fidarsi di te e produce un deliverable che non sembra un template, perché le domande sono standard ma le risposte sono specifiche.

'I miei clienti sono troppo diversi per un unico sistema'

Esegui la stessa diagnosi in cinque punti su ogni cliente prima di scrivere una parola di copy o aprire uno strumento di design. Le differenze che rendono speciali i tuoi clienti—settore, pubblico, modello di prezzo—poggiano su una base condivisa. Un SaaS per le paghe e uno strumento di pianificazione dei social media non hanno nulla in comune tranne i cinque compiti che ogni pagina sta svolgendo. Se verifichi questi compiti, troverai gli stessi schemi negli stessi punti.

Pagina o sezione	Cosa chiede di solito il tuo cliente	Cosa succede realmente nella pagina
Vetrina delle funzionalità	'Mostra ogni funzionalità che abbiamo costruito'	Mostrare il risultato che ottiene l'utente, non solo la funzione. Le immagini come screenshot, GIF o video dovrebbero dimostrare un momento in cui il prodotto cambia il modo di lavorare di qualcuno.
Prezzi	'Rendi i prezzi facili da leggere'	L'acquirente è costretto a decidere quale piano fa per lui. I livelli devono essere letti come una progressione che guida una scelta, non come un elenco piatto di prezzi.
Documentazione API	'I nostri sviluppatori la troveranno nella documentazione'	Spesso il primo test che uno sviluppatore esegue per valutare se il prodotto è affidabile. La chiarezza qui è una funzionalità, non un dettaglio.
Sezione FAQ	'Rispondi alle domande per ridurre le chiamate di supporto'	L'ultima cosa che un acquirente legge prima di cliccare un pulsante. Dovrebbe gestire le obiezioni sui prezzi e i casi limite, non solo le domande generiche dell'azienda.
Prova sociale	'Metti i logo'	La prova che le affermazioni fatte in precedenza sono vere. Loghi e testimonianze sono indicatori di fiducia, non decorazioni.

Una diagnosi non è un template. È un insieme di domande che poni a ogni pagina: questa fa capire all'acquirente cosa fa il prodotto, rende ovvio il passo successivo, risponde all'obiezione che attualmente blocca la vendita? Quando poni queste domande con un cliente presente, il cliente ti vede come la persona che capisce il suo mercato, piuttosto che come la decima agenzia che ha mostrato una presentazione. La ricerca sui siti web SaaS indica aziende come HubSpot, Slack e Zendesk come esempi di sezioni FAQ ben organizzate, e Stripe, GitHub e Twilio come standard per la chiarezza della documentazione. Nessuna di queste aziende ci è arrivata trattando le FAQ come un mucchio di ticket di supporto. Le hanno trattate come una superficie di conversione. Questo è l'atteggiamento che la tua diagnosi deve portare a ogni cliente.

Considera un cliente che vende software di inventario e un altro che vende software per le paghe. La diagnosi spesso fa emergere le stesse tre lacune: la pagina delle funzionalità menziona i moduli invece dei risultati, la pagina dei prezzi non giustifica il salto tra i piani e le FAQ rispondono a domande di supporto piuttosto che a esitazioni d'acquisto. Poiché hai visto queste lacune in entrambi, sai esattamente cosa chiedere in fase di design. Il cliente vede un processo specifico, non generico. Scrivi la diagnosi come un PDF di una pagina con un punteggio da 1 a 5 per ogni compito e una nota per ciascuno. Condividilo con il cliente prima del kickoff del design. Questo ti dà un vocabolario condiviso e trasforma l'audit in un deliverable per cui puoi far pagare. Questo è il cuore di un sistema ripetibile, e abbiamo una guida separata su come impostare quel sistema qui.

'Renderà il nostro lavoro simile a quello di tutti gli altri'

Standardizza le domande che poni, non le risposte che consegni. La diagnosi ti dà una rubrica di valutazione, non un layout. La ricerca sulle vetrine delle funzionalità SaaS mostra che usano immagini come screenshot, GIF o video—ma il contenuto di queste immagini è diverso per ogni prodotto. La funzionalità di reportistica degli stipendi in uno strumento HR e la funzionalità di scansione dei codici a barre nel software di inventario non saranno mai simili. Ciò che rimane costante è la domanda che poni alla tua mente strategica: 'Questa pagina mostra il risultato o solo la funzione?'

Il modulo di accettazione di un medico non rende tutte le diagnosi uguali; rende il medico affidabile. Il tuo framework è il modulo di accettazione. Il cliente riceve comunque un sito web personalizzato, ma tu ottieni una diagnosi ripetibile. La cosa che renderà davvero generico il tuo lavoro è la mancanza di una diagnosi—perché senza di essa, ricadi nella stessa hero image, nello stesso layout a tre colonne per le funzionalità, nella stessa struttura della homepage che hai usato per l'ultimo progetto solo per andare veloce. La diagnosi ti obbliga a giustificare la struttura sulla base delle prove, così ogni sito è strutturalmente diverso dove serve.

In pratica, questo significa che la diagnosi potrebbe dirti di iniziare la pagina delle funzionalità di un cliente con un video di una procedura guidata di importazione e quella di un altro con una GIF di un generatore di report tramite trascinamento. La struttura della pagina rimane la stessa, ma gli asset, i testi e il ritmo sono unici. Il cliente vede un lavoro personalizzato; tu vedi un processo ripetibile. Quando presenti la diagnosi a un cliente, dimostri di sapere cosa deve fare ogni sito SaaS. Questa è una proposta più forte di 'creeremo un design unico nel suo genere.' Il design è la conseguenza della diagnosi, non il punto di partenza.

'Non abbiamo tempo per analizzare ogni pagina'

Fai la versione mirata da 90 minuti, non un audit completo. La maggior parte dei processi di scoperta delle agenzie sono già un audit, solo non strutturato. Trascorri quarantacinque minuti in una call di scoperta che copre background, concorrenti e 'cosa vuoi ottenere da questo,' poi passi settimane a reagire. La diagnosi ribalta tutto: assegni un punteggio ai cinque compiti, elenchi le correzioni a più alto impatto e passi al design. Risparmi tempo perché smetti di rifare il lavoro dopo la prima revisione del design. Le correzioni più economiche sono quelle che fai prima che qualcuno veda i pixel.

Ecco una suddivisione concreta dei 90 minuti: il blocco uno (30 minuti) rivede la homepage e la pagina delle funzionalità per i cinque compiti. Il blocco due (30 minuti) esamina la pagina dei prezzi e le FAQ. Il blocco tre (15 minuti) verifica se la documentazione API risponde a 'posso estrarre i dati,' e gli ultimi 15 minuti elencano le correzioni principali e il responsabile per ciascuna. Non devi leggere ogni pagina dall'inizio alla fine; devi capire se il compito viene svolto. Se la pagina dei prezzi non ha FAQ, il design verrà approvato più velocemente se lo noti prima di creare il mockup della quarta colonna dei prezzi. Se la documentazione API è scritta secondo uno standard interno piuttosto che secondo lo standard dello sviluppatore, lo sai prima di dare le istruzioni al copywriter.

In un incarico, la diagnosi ha rivelato che l'acquirente target aveva il terrore della migrazione dei dati. La FAQ che abbiamo aggiunto per quella risposta è costata due ore di scrittura. Senza la diagnosi, quella paura ci avrebbe accompagnato attraverso il design, lo sviluppo e un sovraccarico di supporto post-lancio. La versione da 90 minuti non è una fase che precede il progetto; è la prima fase del progetto. Ti dà anche un modo onesto per fare stime: esci dalla sessione con un elenco di ciò che esiste e di ciò che non esiste, così la proposta che scrivi si basa su prove, non su supposizioni.

'Il mio cliente non tecnico non ha bisogno della documentazione API'

Usa un albero decisionale, non una checklist: se il prodotto ha un'API pubblica o una storia di integrazione, la documentazione API è una pagina fondamentale; se non ce l'ha, saltala consapevolmente. La ricerca sulla documentazione API è netta: aziende come Stripe, GitHub e Twilio stabiliscono lo standard per la chiarezza della documentazione perché i loro sviluppatori sono di fatto gli acquirenti. Se il tuo cliente ha un'integrazione rivolta agli sviluppatori, la documentazione non è una comodità per gli sviluppatori; è un dispositivo di fiducia che si trova accanto alla pagina dei prezzi. Un cliente non tecnico potrebbe non guardarla mai, ma lo sviluppatore che valuta un acquisto lo farà di sicuro.

L'albero decisionale fa parte del sistema. Quando il cliente dice 'non abbiamo un pubblico di sviluppatori,' fai una domanda: 'qualche parte della tua onboarding richiede a uno sviluppatore di collegare il prodotto a un altro sistema?' Se sì, la documentazione rimane. Se no, la salti e investi lo sforzo nelle FAQ e nella prova sociale. Applica la stessa logica alla prova sociale: per un cliente, una fila di logo è sufficiente; per un altro, è necessaria una testimonianza dettagliata con risultati misurabili. La diagnosi ti dice quale, invece di ripiegare su ogni logo che potresti collezionare. Questa scelta è ciò che rende il framework ripetibile senza essere rigido. Se devi capire cosa significa 'chiarezza' nella pratica, questa guida alla documentazione API ne illustra la struttura.

'Ma il mio cliente vuole un elenco di funzionalità, non risultati'

Quando il cliente dice di voler mostrare le proprie funzionalità, chiedigli di nominare l'attività dell'utente che ogni funzionalità sblocca. L'assunto comune è che la vetrina delle funzionalità sia il punto in cui si vince la vendita. La diagnosi suggerisce il contrario: in un tipico sito SaaS, la pagina dei prezzi è il luogo in cui avviene il calcolo mentale finale e le FAQ sono il luogo in cui si risolve l'ultima obiezione. La vetrina delle funzionalità è essenziale, ma il suo compito è ristretto: mostrare il momento in cui il prodotto diventa prezioso. Un lungo elenco di funzionalità con un paragrafo sotto ciascuna non lo fa.

I clienti resistono a questo perché un elenco sembra tangibile e facile da approvare. Ma una pagina con cinquanta funzionalità produce un visitatore che scorre veloce, e un visitatore che scorre la tua pagina delle funzionalità ha già spostato la sua attenzione sulla tabella dei prezzi. Il compito del tuo sistema è far sentire il cliente a suo agio con il compromesso: non stai rimuovendo funzionalità, le stai spostando dove verranno lette. Una FAQ ben posizionata che dice 'ci integriamo con gli strumenti che già usi' spesso fa più lavoro di una pagina di funzionalità che dice la stessa cosa sotto il titolo sbagliato. Questa è la sfumatura che la maggior parte degli articoli salta, ed è proprio il tipo di compromesso che una diagnosi può rendere esplicito.

La diagnosi ti dà anche una ragione difendibile per opporsi allo scope creep. Quando un cliente chiede di aggiungere un'altra riga di funzionalità alla homepage, puoi indicare la tabella e dire 'il compito di quella pagina è mostrare i risultati, non catalogare funzionalità.' Un page builder generico potrebbe generare una griglia di funzionalità, ma non può decidere se la griglia debba essere sostituita da un video o da una FAQ. Quella decisione è il vero prodotto, ed è la ragione per cui un framework non banalizza il tuo lavoro.

'Abbiamo già un processo interno'

Se la tua agenzia ha un processo per la homepage o una checklist per la pagina dei prezzi, l'obiezione di solito riguarda il non volerlo sostituire. Non devi farlo. La diagnosi in cinque punti non è un sostituto del tuo processo creativo; è un front-end che lo alimenta. Il problema della maggior parte dei processi interni è che sono invisibili. Vivono nella testa del designer senior. La diagnosi esternalizza il processo così un membro junior del team può eseguire la prima passata e tu puoi rivederla in pochi minuti. Questa è la ripetibilità di cui hai davvero bisogno in un'agenzia con più clienti.

Un processo visibile cambia anche la conversazione con i clienti. Invece di 'abbiamo un processo di design proprietario,' puoi dire 'eseguiamo una diagnosi sui cinque compiti che ogni sito SaaS deve svolgere, poi progettiamo in base ai risultati.' La prima frase è una scatola nera che rende i clienti nervosi. La seconda è un metodo chiaro che li invita a partecipare. La diagnosi diventa parte della tua storia di vendita, non solo uno strumento di produzione.

'Il cliente dice che il sito attuale è a posto'

La diagnosi funziona anche se il cliente vuole solo un rinfrescamento. Ti dà una baseline. Dai un punteggio al sito attuale e mostri che una pagina specifica non sta svolgendo un compito specifico. Puoi dire: 'La tua pagina FAQ è organizzata, ma non risponde alla domanda che il tuo team di vendita sente ogni settimana,' e questa è una ragione basata sui fatti per cambiare, non una preferenza estetica. Questo è spesso il modo più gentile per iniziare una riprogettazione: non stai dicendo al cliente che il suo sito è brutto, gli stai dicendo che un compito non viene svolto.

Questo ti protegge anche dal fallimento comune in cui un cliente insiste per mantenere un amato elemento della homepage che danneggia la conversione. La diagnosi ti dà il vocabolario per dire 'questo elemento non sta svolgendo nessuno dei cinque compiti,' e il cliente può vedere le prove. L'obiezione non è più una questione di gusti.

La diagnosi è il prodotto

La ripetibilità non significa costringere ogni cliente nello stesso template. Significa eseguire un processo standard che faccia emergere ciò che è unico in ogni cliente. La diagnosi in cinque punti richiede meno di due ore, dà al tuo team un linguaggio comune e al cliente un chiaro elenco di decisioni. L'agenzia che può promettere una diagnosi coerente può conquistare un cliente in una settimana e consegnare in un mese, non perché il lavoro è più facile ma perché la scoperta è prevedibile. E quando il cliente chiede perché devi fare così tante domande, la risposta è semplice: non stai facendo un'audizione, stai diagnosticando.

Per uno sguardo più approfondito su come la vetrina delle funzionalità e la pagina dei prezzi dovrebbero lavorare insieme, e perché i miti che le circondano persistono, consulta questa guida che sfata i miti.