SaaS-webbdiagnostiken som din byrå kan återanvända utan att kunderna ser likadana ut

Sammanfattning

Hur många gånger det här kvartalet har du kört exakt samma discovery-samtal – samma frågor om produkten, kunden, konkurrenten – för två kunder som insisterade på att de var helt olika? Du vet redan att svaren kommer att vara olika, men de uppgifter som varje SaaS-webbplats måste utföra är inte det. Varje SaaS-produktwebbplats är en liten uppsättning maskiner som kör samma uppgifter: förklara vad produkten gör, visa vad den kostar, berätta för utvecklare hur de integrerar, besvara invändningarna som stoppar ett köp och bevisa att företaget är trovärdigt. En repeterbar diagnostik som granskar dessa fem uppgifter överlever kontakt med vilken kund som helst, eftersom uppgifterna inte förändras. Systemet du bygger runt den är det som gör att du kan gå från ett uppdrag till nästa utan att börja från noll. Det tar mindre tid än din nuvarande discovery-process, det ger kunden en tydlig anledning att lita på dig, och det producerar en leverans som inte ser mallad ut, eftersom frågorna är standard men svaren är specifika.

Hur många gånger det här kvartalet har du kört exakt samma discovery-samtal – samma frågor om produkten, kunden, konkurrenten – för två kunder som insisterade på att de var helt olika? Du vet redan att svaren kommer att vara olika, men de uppgifter som varje SaaS-webbplats måste utföra är inte det. Varje SaaS-produktwebbplats är en liten uppsättning maskiner som kör samma uppgifter: förklara vad produkten gör, visa vad den kostar, berätta för utvecklare hur de integrerar, besvara invändningarna som stoppar ett köp och bevisa att företaget är trovärdigt. En repeterbar diagnostik som granskar dessa fem uppgifter överlever kontakt med vilken kund som helst, eftersom uppgifterna inte förändras. Systemet du bygger runt den är det som gör att du kan gå från ett uppdrag till nästa utan att börja från noll. Det tar mindre tid än din nuvarande discovery-process, det ger kunden en tydlig anledning att lita på dig, och det producerar en leverans som inte ser mallad ut, eftersom frågorna är standard men svaren är specifika.

'Mina kunder är för olika för ett enda system'

Kör samma fempunktsdiagnostik på varje kund innan du skriver ett ord av copy eller öppnar ett designverktyg. Skillnaderna som gör dina kunder speciella – bransch, målgrupp, prismodell – ligger ovanpå en gemensam grund. En löne-SaaS och ett verktyg för sociala medier-schemaläggning har inget gemensamt förutom de fem uppgifterna som varje sida utför. Om du granskar dessa uppgifter hittar du samma mönster på samma ställen.

Sida eller sektion	Vad din kund vanligtvis ber om	Vad som faktiskt händer på sidan
Funktionsvisning	'Visa varje funktion vi byggt'	Visar resultatet användaren får, inte bara funktionen. Bilder som skärmdumpar, GIF:ar eller videor bör demonstrera ett ögonblick där produkten förändrar hur någon arbetar.
Prissättning	'Gör priserna lätta att läsa'	Köparen tvingas bestämma vilken plan som är för dem. Nivåerna behöver läsas som en progression som vägleder ett val, inte en platt lista av priser.
API-dokumentation	'Våra utvecklare hittar det i dokumentationen'	Ofta det första testet en utvecklare kör för att utvärdera om produkten går att lita på. Tydlighet här är en funktion, inte en extra detalj.
FAQ-sektion	'Svara på frågor så att supportsamtalen minskar'	Det sista en köpare läser innan de klickar på en knapp. Den bör hantera prisinvändningar och gränsfall, inte bara generiska företagsfrågor.
Sociala bevis	'Sätt upp logotyperna'	Beviset på att påståendena som gjordes tidigare är sanna. Logotyper och vittnesmål är förtroendeindikatorer, inte dekoration.

En diagnostik är inte en mall. Det är en uppsättning frågor du ställer till varje sida: gör detta så att köparen förstår vad produkten gör, gör det nästa steg uppenbart, besvarar det invändningen som för närvarande blockerar försäljningen? När du ställer dessa frågor med en kund närvarande, ser kunden dig som den person som förstår deras marknad, snarare än som den tionde byrån som visade ett bildspel. Forskningen om SaaS-webbplatser pekar på företag som HubSpot, Slack och Zendesk som exempel på välorganiserade FAQ-sektioner, och på Stripe, GitHub och Twilio som standarder för dokumentationstydlighet. Inget av dessa företag nådde dit genom att behandla FAQ som en hög med supportärenden. De behandlade den som en konverteringsyta. Det är den attityden din diagnostik behöver föra till varje kund.

Tänk dig en kund som säljer lagerhanteringsprogramvara och en annan som säljer lönehanteringsprogramvara. Diagnostiken hittar ofta samma tre luckor: funktionssidan nämner moduler istället för resultat, prissidan motiverar inte hoppet mellan planerna, och FAQ svarar på supportfrågor snarare än köptveksamheter. Eftersom du har sett dessa luckor i båda, vet du exakt vad du ska be om i designstadiet. Kunden ser en process som är specifik, inte generisk. Skriv diagnostiken som en PDF på en sida med en poäng från 1 till 5 för varje uppgift och en anteckning för varje. Dela den med kunden före designkickoffen. Detta ger er ett gemensamt språk och gör granskningen till en leverans du kan ta betalt för. Detta är kärnan i ett repeterbart system, och vi har en separat genomgång av hur du sätter upp det systemet här.

'Det får vårt arbete att se ut som alla andras'

Standardisera frågorna du ställer, inte svaren du levererar. Diagnostiken ger dig en poängsättningsmatris, inte en layout. Forskningen om SaaS-funktionsvisningar visar att de använder bilder som skärmdumpar, GIF:ar eller videor – men innehållet i dessa bilder är olika för varje produkt. Lönerapporteringsfunktionen i ett HR-verktyg och streckkodsskanningsfunktionen i lagerprogramvara kommer aldrig att se likadana ut. Det som förblir konstant är frågan du ställer till ditt strategiska sinne: 'Visar den här sidan resultatet, eller bara funktionen?'

En läkares intagsformulär gör inte alla diagnoser likadana; det gör läkaren pålitlig. Ditt ramverk är intagsformuläret. Kunden får fortfarande en skräddarsydd webbplats, men du får en diagnostik som är repeterbar. Det som faktiskt kommer att få ditt arbete att se generiskt ut är avsaknaden av en diagnostik – för utan den faller du tillbaka på samma hero-bild, samma trekolumners funktionslayout, samma hemsidestruktur som du använde för det förra projektet bara för att komma snabbt framåt. Diagnostiken tvingar dig att motivera strukturen utifrån bevisen, så att varje webbplats är strukturellt annorlunda där den behöver vara.

I praktiken innebär detta att diagnostiken kan säga åt dig att börja en kunds funktionssida med en video av en importguide och en annans med en GIF av en dra-och-släpp-rapportbyggare. Sidstrukturen förblir densamma, men tillgångarna, copy och rytm är unika. Kunden ser skräddarsytt arbete; du ser en repeterbar process. När du presenterar diagnostiken för en kund, visar du att du vet vad varje SaaS-webbplats måste göra. Det är en starkare pitch än 'vi skapar en unik design.' Designen är en konsekvens av diagnosen, inte startpunkten.

'Vi har inte tid att granska varje sida'

Gör den fokuserade 90-minutersversionen, inte en fullständig granskning. De flesta byråernas discovery-processer är redan en granskning, bara en ostrukturerad sådan. Du spenderar fyrtiofem minuter på ett discovery-samtal som täcker bakgrund, konkurrenter och 'vad vill du få ut av detta', och sedan tillbringar du veckor med att reagera. Diagnostiken vänder på det: du poängsätter de fem uppgifterna, listar de mest hävstångsstarka åtgärderna och går vidare till design. Det sparar tid eftersom du slutar göra om arbete efter den första designgranskningen. De billigaste åtgärderna är de du gör innan någon ser pixlar.

Här är en konkret 90-minutersuppdelning: block ett (30 minuter) granskar hemsidan och funktionssidan för de fem uppgifterna. Block två (30 minuter) skummar igenom prissidan och FAQ. Block tre (15 minuter) kontrollerar om API-dokumentationen svarar på 'kan jag få ut data', och de sista 15 minuterna listar de viktigaste åtgärderna och ansvarig för varje. Du behöver inte läsa varje sida från topp till botten; du behöver ta reda på om uppgiften utförs. Om prissidan inte har någon FAQ kommer designen att godkännas snabbare om du upptäcker det innan du mockar upp den fjärde priskolumnen. Om API-dokumentationen är skriven enligt en intern standard snarare än utvecklarens standard, vet du det innan du briefar copywritern.

I ett uppdrag visade diagnostiken att målköparen var livrädd för datamigrering. FAQ:en vi lade till för det svaret kostade två timmars skrivande. Utan diagnostiken skulle den rädslan ha följt oss genom design, genom utveckling och in i en överbelastning av support efter lansering. 90-minutersversionen är inte en fas som föregår projektet; det är projektets första fas. Den ger dig också ett ärligt sätt att uppskatta: du lämnar sessionen med en lista över vad som finns och vad som inte finns, så att offerten du skriver bygger på bevis snarare än gissningar.

'Min icke-tekniska kund behöver inte API-dokumentation'

Använd ett beslutsträd, inte en checklista: om produkten har ett publikt API eller en integrationsberättelse, är API-dokumentationen en kärnsida; om inte, hoppa medvetet över den. Forskningen om API-dokumentation är tydlig: företag som Stripe, GitHub och Twilio sätter standarden för dokumentationstydlighet, eftersom deras utvecklare i praktiken är köparna. Om din kund har en utvecklarinriktad integration, är dokumentationen inte en bekvämlighet för utvecklare; den är en förtroendeenhet som sitter bredvid prissidan. En icke-teknisk kund kanske aldrig tittar på den, men utvecklaren som utvärderar ett köp kommer absolut att göra det.

Beslutsträdet är en del av systemet. När kunden säger 'vi har ingen utvecklarpublik', ställ en fråga: 'kräver någon del av er onboarding att en utvecklare kopplar produkten till ett annat system?' Om ja, behålls dokumentationen. Om nej, hoppa över den och satsa på FAQ och sociala bevis. Tillämpa samma logik på sociala bevis: för en kund räcker en rad logotyper; för en annan krävs ett detaljerat vittnesmål med mätbara resultat. Diagnostiken säger dig vilket, snarare än att alltid använda varje logotyp du kan samla in. Det valet är vad som gör ramverket repeterbart utan att vara stelt. Om du behöver lista ut vad 'tydlighet' innebär i praktiken, går den här guiden till API-dokumentation igenom strukturen.

'Men min kund vill ha en funktionslista, inte resultat'

När kunden säger att de vill visa upp sina funktioner, be dem att namnge den användaruppgift som varje funktion möjliggör. Det vanliga antagandet är att funktionsvisningen är där du vinner försäljningen. Diagnostiken föreslår något annat: på en typisk SaaS-webbplats sker den sista mentala uträkningen på prissidan, och FAQ är där den sista invändningen löses. Funktionsvisningen är viktig, men dess uppgift är snäv – att visa ögonblicket då produkten blir värdefull. En lång lista med funktioner med ett stycke under varje gör inte det.

Kunder motstår detta eftersom en lista känns påtaglig och lätt att godkänna. Men en sida med femtio funktioner ger en besökare som skummar, och en besökare som skummar din funktionssida har redan flyttat sin uppmärksamhet till pristabellen. Ditt systems uppgift är att få kunden att känna sig bekväm med avvägningen: du tar inte bort funktioner, du flyttar dem till där de kommer att läsas. En välplacerad FAQ som säger 'vi integrerar med verktygen du redan använder' gör ofta mer nytta än en funktionssida som säger samma sak under fel rubrik. Detta är nyansen de flesta artiklar hoppar över, och det är just den typen av avvägning som en diagnostik kan göra explicit.

Diagnostiken ger dig också en försvarbar anledning att stå emot kravglidning. När en kund ber att lägga till ytterligare en rad funktioner på hemsidan, kan du peka på tabellen och säga 'den sidans uppgift är att visa resultat, inte att katalogisera funktionalitet.' En generisk sidbyggare kan generera ett funktionsrutnät, men den kan inte avgöra om rutnätet ska ersättas av en video eller en FAQ. Det beslutet är den verkliga produkten, och det är anledningen till att ett ramverk inte kommodifierar ditt arbete.

'Vi har redan en intern process'

Om din byrå har en hemsideprocess eller en checklista för prissidan, handlar invändningen vanligtvis om att man inte vill ersätta den. Det behöver du inte. Femuppgiftsdiagnostiken är inte en ersättning för din kreativa process; den är ett front-end som matar den. Problemet med de flesta interna processer är att de är osynliga. De lever i senior designers huvud. Diagnostiken externaliserar processen så att en juniormedlem kan göra den första genomgången, och du kan granska den på några minuter. Det är den repeterbarhet du faktiskt behöver på en byrå med flera kunder.

En synlig process förändrar också samtalet med kunderna. Istället för 'vi har en egen designprocess' kan du säga 'vi kör en diagnostik mot de fem uppgifter som varje SaaS-webbplats måste utföra, och sedan designar vi utifrån resultaten.' Den första meningen är en svart låda som gör kunder nervösa. Den andra är en tydlig metod som bjuder in dem. Diagnostiken blir en del av din säljberättelse, inte bara ett produktionsverktyg.

'Kunden säger att den nuvarande webbplatsen är bra'

Diagnostiken fungerar även om kunden inte vill ha mer än en uppfräschning. Den ger dig en baslinje. Du poängsätter den nuvarande webbplatsen och visar att en specifik sida misslyckas med en specifik uppgift. Du kan säga: 'Din FAQ-sida är organiserad, men den svarar inte på frågan som ditt säljteam hör varje vecka', och det är en faktabaserad anledning att förändra, inte en estetisk preferens. Detta är ofta det skonsammaste sättet att starta en redesign: du säger inte till kunden att deras webbplats är ful, du säger att en uppgift inte utförs.

Detta skyddar dig också från det vanliga misslyckandet där en kund insisterar på att behålla ett älskat hemsideselement som skadar konverteringen. Diagnostiken ger dig språket för att säga 'det elementet utför ingen av de fem uppgifterna', och kunden kan se bevisen. Invändningen är inte längre en fråga om smak.

Diagnosen är produkten

Repeterbarhet handlar inte om att pressa in varje kund i samma mall. Det handlar om att köra en standardprocess som får fram det som är unikt för varje kund. Femuppgiftsdiagnostiken tar mindre än två timmar, ger ditt team ett gemensamt språk och ger kunden en tydlig lista med beslut. En byrå som kan lova en konsekvent diagnostik kan landa en kund på en vecka och leverera på en månad, inte för att arbetet är lättare utan för att discovery är förutsägbar. Och när kunden frågar varför du behöver ställa så många frågor, är svaret enkelt: du provspelar inte, du diagnostiserar.

För en djupare titt på hur funktionsvisningen och prissidan bör samverka, och varför myterna kring dem består, se den här mytavslöjande guiden.