SaaS-FAQ-sider er konverteringsarbeidshesten byråer overser

Sammendrag

De fleste SaaS-FAQ-sider er bygget på supportbilletter, noe som betyr at de svarer på spørsmål fra folk som allerede har kjøpt – mens de ignorerer innvendingene som hindrer potensielle kunder i å kjøpe. Denne artikkelen snur FAQ-en fra en ettertanke etter lansering til en salgsressurs. Skrevet for byråer som bygger nettsteder for flere kunder, dekker den en repeterbar prosess: samle innvendinger fra salgsteamet, grupper spørsmål etter kjøpsfase, skriv svar som er fullstendige nok til å avslutte søket, par hver innvending med spesifikke sosiale bevis, og vedlikehold siden i en kvartalsvis rytme. Myte-vs.-virkelighet-formatet viser hva som faktisk fungerer, med et praktisk eksempel i hver seksjon. Resultatet er en FAQ-side som reduserer supportbelastningen og øker sjansen for at en potensiell kunde melder seg.

De fleste råd om SaaS-FAQ-sider starter fra feil sted. De behandler dem som opprydding etter lansering – et sted å parkere svar på supportbilletter slik at supportteamet kan slutte å gjenta seg selv. Den innrammingen er grunnen til at kundens FAQ-side gjør nesten ingenting for virksomheten. Det som faktisk fungerer: en FAQ-side er en av de få sidene en potensiell kunde besøker etter at de allerede har bestemt seg for at de kanskje vil kjøpe. Det er en beslutningsfaseside, ikke en dokumentasjonsside. Den bør bygges for å fjerne innvendingene som står mellom en besøkende og en påmelding, og den fortjener samme strategiske oppmerksomhet som prissiden.

Hvis du er i et byrå, er problemet enda skarpere. Hver kunde er forskjellig: forskjellig produkt, forskjellig kjøper, forskjellig supporthistorikk. Likevel må du produsere noe som fungerer uten å starte fra null hver gang. Fristelsen er å kopiere strukturen til den siste FAQ-en du bygde. Det fungerer helt til det ikke gjør det, fordi innvendingene som betyr noe for en fintech-kunde er ikke de samme som betyr noe for en team-samarbeidskunde. Rammeverket må være det samme; innholdet må være forskjellig. Myteknusingen nedenfor er det rammeverket. Mønsteret under er enkelt: forvent at FAQ-en selger, ikke bare informerer. Det endrer hvordan du samler inn spørsmål, hvordan du grupperer dem, hvor lange hvert svar blir, og hva du plasserer ved siden av dem.

Start med salget, ikke supportbilletter

Begynn med å be kundens salgsteam om de siste fem avtalene som gikk i stå. Spørsmålene som stanset disse avtalene er de første ti spørsmålene FAQ-siden din bør svare på. De fleste FAQ-sider er bygget på supportbilletter – spørsmål fra folk som allerede har kjøpt. Spørsmålene som faktisk blokkerer salg, kommer fra folk som ikke har kjøpt, og de pleier å handle om migrering, sikkerhet, priser og hva som skjer etter at prøveperioden utløper.

Slik ser det ut i praksis. En kunde innen arbeidsflytautomatisering kom til oss med en FAQ full av spørsmål som «Hvordan tilbakestiller jeg passordet?» og «Hvilke nettlesere støttes?» Siden var teknisk nyttig, men kommersielt sett inert. Så spurte vi salgsteamet hva de hørte i tapte avtaler. Det viste seg at potensielle kunder spurte om verktøyet kunne erstatte deres nåværende regneark, om migreringen ville kreve IT, og om selgerens pristilbud samsvarte med hva faktureringen faktisk ville belaste. Vi bygde om FAQ-en rundt disse tre innvendingene, hver med et kort svar og en lenke til en relevant side. Spørsmålene om passordtilbakestilling ble flyttet til supportsenteret. Siden ble et avslutningsverktøy i stedet for en hjelpdesk.

Når du gjennomfører dette intervjuet, ikke nøye deg med «de spør om priser.» Be om den nøyaktige ordlyden. «Er prisen per bruker eller per arbeidsområde?» er handlekraftig. «De spør om priser» er det ikke. Spør også hva konkurrenten gjør som kunden ikke lett kan matche – det pleier å avdekke innvendingene som salgsteamet er lei av å høre. Plasser dem helt øverst på siden.

Dette er et sted hvor bygge en SaaS-nettside fra innsiden og ut lønner seg: du starter fra spørsmålene ekte kjøpere stiller, og bygger deretter nettsiden rundt dem. Forbeholdet er at du ikke kan hoppe over supportspørsmål helt. Noen besøkende er eksisterende kunder. Men sidens beste plass bør gå til spørsmål som dukker opp før kjøpet, ikke etter. Hvis du må beholde noen supportspørsmål på siden, flytt dem til bunnen under en tydelig merket overskrift «Eksisterende kunder». På den måten betjener du begge målgruppene uten å la supportspørsmål dominere. En nyttig måte å gjennomføre intervjuet på er å sende salgsteamet en enkel forespørsel: list opp alle spørsmål en potensiell kunde stilte forrige måned som du måtte svare manuelt på. Du får to lister. Spørsmålene som krever skjønn er FAQ-materiale; de som kan besvares med en lenke, hører hjemme i dokumentasjonen.

Lengde er ikke grundighet

Prinsippet som er verdt å holde fast på, er relevans etter plassering. En besøkende som er tre minutter inn i en gratis prøveperiode, har et annet spørsmål enn en innkjøpsansvarlig som vurderer verktøyet. Hvis FAQ-en er en enkelt alfabetisk liste, må den innkjøpsansvarlige grave gjennom «Hvordan endrer jeg avatar?» for å finne «Hvordan håndterer dere datalagring?» De fleste besøkende vil ikke. De vil forlate siden.

En kunde, en SaaS for prosjektstyring, hadde en FAQ som var alfabetisert og strakte seg over flere sider. Vi omgrupperte den i fire bøtter: «Før du begynner» (hva den gjør, hvordan den sammenlignes), «Under prøveperioden» (oppsett, begrensninger), «Kjøp» (priser, fakturering, sikkerhetsgjennomganger) og «Etter du har kjøpt» (fakturaendringer, support). Kjøpsbøtta ble satt først, fordi det var der pengene gikk tapt. Ordtellingen endret seg ikke mye, men siden gikk fra en liste til en veiledet sti.

Innen hver bøtte, bruk en av to sorteringsregler. Hvis produktet har en tydelig måte å kjøpe på, sorter etter alvorlighetsgrad: spørsmålet som stopper en avtale helt, kommer først. Hvis produktet ikke har noen åpenbar sekvens, sorter etter frekvens – men bare innenfor bøtta, ikke på tvers av hele siden. Det som betyr noe, er at en besøkende kan finne spørsmålet de bryr seg om uten å lese alt. Bruk ankerkoblinger øverst på siden slik at en innkjøpsansvarlig kan hoppe direkte til «Kjøp» og en prøvebruker kan hoppe til «Under prøveperioden». På et typisk SaaS-nettsted er dette de to gruppene som gir flest påmeldinger og flest tapte avtaler, så de får toppen av siden.

For prisspørsmål spesielt, gjelder den samme logikken som du ville brukt på en prisside bygget for konvertering inni FAQ-en: legg de beslutningsrelevante detaljene først, deretter begrunnelsen, deretter lenken. Ikke få en besøkende til å lete etter prisen på planen de vil ha. Og innen Kjøp-bøtta, tenk på sekvens igjen. Sett sikkerhet og samsvar før betalingsmetoder, fordi en sikkerhetsgjennomgang ofte er en portvokter som stopper evalueringen før et betalingsspørsmål i det hele tatt oppstår.

Myte	Virkelighet
En FAQ eksisterer for å svare på spørsmål	En FAQ eksisterer for å fjerne kjøpsinnvendinger
Lengre FAQ betyr mer grundig	Skannbar, gruppert FAQ utkonkurrerer en lang liste
Svar bør være korte	Svar bør være fullstendige nok til å avslutte søket
Sosiale bevis hører bare hjemme på forsiden	Bevis plassert ved siden av en innvending konverterer bedre
FAQ er en lanseringsleveranse	FAQ er et levende dokument med en revisjonsrytme

Kostnaden ved et for kort svar

Her er før-og-etter-eksempelet vi bruker med kunder når de protesterer på «lange» svar.

Før: «Støtter dere SSO? Ja, det gjør vi.»

Etter: «SSO er tilgjengelig på Pro-planen og oppover. Du kan aktivere det når du er arbeidsområdeeier, fra Innstillinger > Sikkerhet. Her er en steg-for-steg-guide. Hvis teamet ditt bruker Okta eller Azure AD, støttes begge.»

Det andre svaret er lengre, men det er også endelig. Den besøkende slutter å søke fordi svaret forutser oppfølgingsspørsmålene. Å skrive slik virker enkelt, men det krever at du vet hva oppfølgingsspørsmålene faktisk er. Den enkleste måten å finne dem på er å se på de øverste supportbillettene for hvert funksjonsområde og brette svarene inn i FAQ-en.

Strukturen å bruke er: direkte svar, én setning med kontekst, deretter en lenke. Marker det direkte svaret med fet skrift slik at en skumleser ser det umiddelbart. Hvis du har et skjermbilde, legg det etter konteksten, ikke før. Ikke begrav svaret i et avsnitt som beskriver funksjonen. Dette er samme prinsipp som gjør API-dokumentasjonen til selskaper som Stripe og Twilio fremragende: du kan lande, få svaret og forlate. Vi går dypere inn i den standarden i guiden vår om å skrive SaaS-API-dokumentasjon utviklere faktisk bruker. Forbeholdet er at «fullstendig» ikke betyr «lang for langhetens skyld.» En tekstvegg er fortsatt en tekstvegg.

Det er også et tone-spørsmål. Et for kort svar har en tendens til å høres kortfattet eller til og med frekt ut; et for langt svar høres defensivt ut. Gylne middelvei er svaret en kompetent supportperson ville gitt i en e-post: et direkte svar, en kort forklaring og et neste steg. Hvis kundens supportteam skriver nyttige e-poster, be om noen og bruk dem som modell. Hvis de ikke gjør det, kan du skrive modellen selv og la supportteamet korrigere den. Det er også en god måte å få støtte fra supportteamet på, fordi FAQ-en begynner å ligne deres beste e-poster, ikke et bedriftsdokument.

Par innvendingen med beviset

Ta hver innvending på kundens FAQ og still ett spørsmål: hvilket sosialt bevis ville avvæpnet dette? En kunde innen e-signatur hadde en sterk kundeuttalelsesdel på forsiden. Men da vi så på FAQ-ens sikkerhetsspørsmål – «Hvordan holder du dokumentene mine trygge?» – var svaret tørr samsvarsjargong. Kundeuttalelsen fra et juridisk team som sa «vårt samsvarsteam godkjente dem på under en dag» var akkurat den tryggheten svaret trengte.

Vi begynte å pare hver innvending med et bevis: sikkerhetsspørsmålet fikk samsvarsuttalelsen, prisspørsmålet fikk et sitat fra en kunde som byttet fra en konkurrent, migreringsspørsmålet fikk en linje om en kunde som flyttet hele selskapet uten nedetid. FAQ-en sluttet å være en separat side og ble en del av salgsargumentet.

Forbeholdet her er relevans. En logovegg nær FAQ-en gir lite; en kundeuttalelse som direkte adresserer innvendingen, har vekt, spesielt hvis den angir rollen til personen som gir den. Hvis kunden din ikke har den typen bevis ennå, begynn å samle det fra de samme salgssamtalene som produserer innvendingene. De to ressursene kommer fra samme kilde. Når du har en kundeuttalelse, trekk ut en klausul som samsvarer med et FAQ-spørsmål. Du trenger ikke hele sitatet; én spesifikk setning er nok. Be salgsteamet legge merke til om kunden nevnte en spesifikk bekymring når en avtale lukkes. Den bekymringen er et fremtidig FAQ-spørsmål, og kundens egne ord er det beste svaret.

Det er en andre, mindre åpenbar type bevis: produktbevis. Hvis en potensiell kunde spør «Kan jeg eksportere dataene mine?» inkluderer det sterkeste svaret et skjermbilde av eksportskjermen, ikke bare en setning som sier ja. Hvis de spør «Hvor lenge varer prøveperioden?» inkluderer det sterkeste svaret en linje om hva som skjer når den slutter. Skjermbilder og korte GIF-er fungerer her fordi de viser i stedet for å påstå. Dette er også der FAQ-en kobles til funksjonspresentasjonen: et spørsmål som «Hvordan er dette annerledes fra et regneark?» bør lenke til delen av nettstedet som demonstrerer forskjellen, ikke en vegg av sammenligningstekst.

En FAQ er en prosess, ikke en lanseringsleveranse

Det varige prinsippet for et byrå er at en FAQ-side er en prosess, ikke en side. Kundens produkt endrer seg hver måned; nye innvendinger dukker opp med hver prisendring, hver nye konkurrent, hvert kvartal. Siden du lanserer i januar er gjetning innen mars. Byråene som gjør dette repeterbart, bygger en lett vedlikeholdsrytme inn i engasjementet.

Etter lansering, sett opp en kvartalsvis gjennomgang der du ser på tre input: nye supportbilletter, spørsmål fra salgssamtaler og endringer i produktet. Del gjennomgangen i to trinn. Først fjerner du spørsmål som ikke lenger betyr noe. For det andre legger du til spørsmål som dukket opp i løpet av de siste 90 dagene. Du trenger ikke en innholdsstrateg for dette. Du trenger en vane.

Vi innførte dette for en kunde ved å be supportlederen om å tagge alle billetter som kunne vært besvart av nettstedet. Etter et par kvartaler begynte supportlederen å sende oss en liste over tilbakevendende spørsmål før vi spurte. FAQ-en ble et felles prosjekt, som er den eneste måten den forblir relevant på. For ethvert byrå som driver denne typen arbeid på tvers av flere engasjementer, er det å behandle FAQ-en som en del av et repeterbart SaaS-nettstedssystem det som holder kvaliteten konsistent uten å finne opp prosessen på nytt hver gang.

Gjennomgangen trenger ikke ta lenger enn en time. Femten minutter til supportbilletter, femten til salgsspørsmål, femten til produktendringer og femten til å oppdatere siden. Hvis du fakturerer for innholdsvedlikehold, blir det en tilbakevendende inntektslinje. Hvis du ikke gjør det, hindrer den siden i å eldes. Det er én beregning verdt å følge med på, selv om du ikke kan knytte et hardt tall til den: om supportteamet rapporterer færre av de samme spørsmålene. Når supportteamet slutter å svare på et spørsmål som nå står på FAQ-en, er det en seier, og det er vanligvis synlig i teamets tone før det dukker opp i noe dashbord. Når supportteamet begynner å foreslå nye FAQ-oppføringer, vet du at vedlikeholdsprosessen har slått rot.

Ingen av dette krever en redesign eller et nytt verktøy. Det som kreves, er et skifte i hvordan du snakker om FAQ-en med kunden din. Slutt å kalle det «FAQ-en» i prosjektplaner og begynn å kalle det «innvendingssiden.» Den ene endringen vil omforme alle beslutninger som følger, fra spørsmålene du samler inn til svarene du skriver. Det vil også gjøre argumentet for å vedlikeholde siden mye enklere, fordi ingen kunde bestrider behovet for å fortsette å avverge innvendinger.