Az SaaS-weboldal diagnosztika, amelyet ügynöksége újra felhasználhat anélkül, hogy ügyfelei egyformának tűnnének

Összefoglaló

Hányszor futtatta le ebben a negyedévben pontosan ugyanazt a felmérő hívást – ugyanazokkal a kérdésekkel a termékről, a vásárlóról, a versenytársról – két olyan ügyfél esetében, akik kitartottak amellett, hogy teljesen mások? Ön már tudja, hogy a válaszok különbözni fognak, de azok a feladatok, amelyeket minden SaaS-weboldalnak el kell végeznie, nem változnak. Minden SaaS-termék weboldala olyan, mint egy kis gépezet, amely ugyanazokat a feladatokat látja el: elmagyarázza, mit csinál a termék, megmutatja, mennyibe kerül, elmondja a fejlesztőknek, hogyan kell integrálni, megválaszolja a vásárlást gátló ellenvetéseket, és bizonyítja, hogy a cég hiteles. Egy megismételhető diagnosztika, amely ezt az öt feladatot vizsgálja, minden ügyféllel szemben megállja a helyét, mert a feladatok nem változnak. A rendszer, amelyet köré épít, az teszi lehetővé, hogy egyik megbízásból a másikba lépjen anélkül, hogy a nulláról indulna. Kevesebb időt vesz igénybe, mint a jelenlegi felmérési folyamata, világos okot ad az ügyfélnek arra, hogy megbízzon Önben, és olyan eredményt hoz létre, amely nem tűnik sablonosnak, mert a kérdések általánosak, de a válaszok egyediek.

Hányszor futtatta le ebben a negyedévben pontosan ugyanazt a felmérő hívást – ugyanazokkal a kérdésekkel a termékről, a vásárlóról, a versenytársról – két olyan ügyfél esetében, akik kitartottak amellett, hogy teljesen mások? Ön már tudja, hogy a válaszok különbözni fognak, de azok a feladatok, amelyeket minden SaaS-weboldalnak el kell végeznie, nem változnak. Minden SaaS-termék weboldala olyan, mint egy kis gépezet, amely ugyanazokat a feladatokat látja el: elmagyarázza, mit csinál a termék, megmutatja, mennyibe kerül, elmondja a fejlesztőknek, hogyan kell integrálni, megválaszolja a vásárlást gátló ellenvetéseket, és bizonyítja, hogy a cég hiteles. Egy megismételhető diagnosztika, amely ezt az öt feladatot vizsgálja, minden ügyféllel szemben megállja a helyét, mert a feladatok nem változnak. A rendszer, amelyet köré épít, az teszi lehetővé, hogy egyik megbízásból a másikba lépjen anélkül, hogy a nulláról indulna. Kevesebb időt vesz igénybe, mint a jelenlegi felmérési folyamata, világos okot ad az ügyfélnek arra, hogy megbízzon Önben, és olyan eredményt hoz létre, amely nem tűnik sablonosnak, mert a kérdések általánosak, de a válaszok egyediek.

'Az én ügyfeleim túl különbözőek egy rendszerhez'

Futtassa le ugyanezt az ötpontos diagnosztikát minden ügyfélen, mielőtt egy szót is írna a szövegből, vagy kinyitna egy tervezőeszközt. A különbségek, amelyek az ügyfeleit egyedivé teszik – iparág, célközönség, árazási modell – egy közös alapra épülnek. A bérszámfejtő SaaS és a közösségimédia-ütemező eszköz semmiben sem hasonlít, kivéve azt az öt feladatot, amelyet minden oldal ellát. Ha ezekre a feladatokra auditál, ugyanazokat a mintákat fogja megtalálni ugyanazokon a helyeken.

Oldal vagy szekció	Mit kér általában az ügyfél	Mi történik valójában az oldalon
Funkcióbemutató	'Mutassuk meg az összes általunk fejlesztett funkciót'	Annak az eredménynek a bemutatása, amelyet a felhasználó kap, nem csak a funkcióé. A képernyőképek, GIF-ek vagy videók olyan pillanatot demonstráljanak, amikor a termék megváltoztatja valakinek a munkamódját.
Árazás	'Az árak legyenek könnyen áttekinthetők'	A vásárlónak döntenie kell, melyik csomag való neki. A csomagoknak progresszióként kell olvasódniuk, amely a választást irányítja, nem pedig lapos árak listájaként.
API-dokumentáció	'A fejlesztőink megtalálják a dokumentációban'	Gyakran az első teszt, amit egy fejlesztő lefuttat, amikor felméri, hogy a termék megbízható-e. A világosság itt funkció, nem pedig luxus.
GYIK rovat	'Válaszoljunk a kérdésekre, hogy csökkenjenek a támogatási hívások'	Az utolsó dolog, amit a vásárló elolvas, mielőtt egy gombra kattintana. Az árazással kapcsolatos ellenvetéseket és határeseteket kell kezelnie, nem pedig csak általános vállalati kérdéseket.
Referenciák	'Tegyük fel a logókat'	Annak bizonyítéka, hogy a korábban tett állítások igazak. A logók és az ajánlások bizalmi jelzők, nem pedig dekoráció.

A diagnosztika nem sablon. Olyan kérdésrendszer, amelyet minden oldalhoz fel kell tennie: vajon a vásárló megérti-e, mit csinál a termék, vajon nyilvánvalóvá teszi-e a következő lépést, vajon megválaszolja-e az eladást jelenleg blokkoló ellenvetést? Amikor ezeket a kérdéseket az ügyfél jelenlétében teszi fel, az ügyfél olyan személyként látja Önt, aki érti a piacát, nem pedig a tizedik ügynökségként, amely bemutatta a prezentációját. A SaaS-weboldalakkal kapcsolatos kutatások olyan cégekre mutatnak, mint a HubSpot, a Slack és a Zendesk, mint a jól szervezett GYIK-rendszerek példái, valamint a Stripe, a GitHub és a Twilio a dokumentáció világosságának mércéjére. Egyikük sem jutott el idáig azzal, hogy a GYIK-et támogatási jegyek halmazaként kezelte. Konverziós felületként kezelték. Ezt a hozzáállást kell a diagnosztikának minden ügyfélhez vinnie.

Vegyünk egy ügyfelet, aki készletnyilvántartó szoftvert árul, és egy másikat, aki bérszámfejtő szoftvert. A diagnosztika gyakran ugyanazt a három hiányosságot tárja fel: a funkciókat bemutató oldal modulokról beszél eredmények helyett, az árak oldala nem indokolja a csomagok közötti ugrást, és a GYIK támogatási kérdésekre válaszol vásárlási fenntartások helyett. Mivel mindkét esetben látta ezeket a hiányosságokat, pontosan tudja, mit kell kérnie a tervezési szakaszban. Az ügyfél egy specifikus, nem pedig generikus folyamatot lát. Készítse el a diagnosztikát egylapos PDF-ként, minden feladatra 1-től 5-ig terjedő pontszámmal, és mindegyikhez egy megjegyzéssel. Ossza meg az ügyféllel a tervezés megkezdése előtt. Ez közös szókincset ad Önnek, és az auditot olyan leadandóvá alakítja, amelyért pénzt kérhet. Ez a megismételhető rendszer lényege, és elérhető egy külön útmutató is, amely bemutatja a rendszer felállítását itt.

'Ettől a munkánk olyan lesz, mint mindenki másé'

Szabványosítsa a kérdéseket, amelyeket feltesz, ne a válaszokat, amelyeket szállít. A diagnosztika pontozási szempontrendszert ad, nem pedig elrendezést. A SaaS-funkcióbemutatókkal kapcsolatos kutatások azt mutatják, hogy képernyőképeket, GIF-eket vagy videókat használnak – de ezeknek a vizuális elemeknek a tartalma minden terméknél más. A HR-eszköz bérjelentési funkciója és a raktárkészlet-szoftver vonalkód-leolvasó funkciója soha nem fog ugyanúgy kinézni. Ami állandó, az a kérdés, amelyet stratégiai gondolkodásához intéz: 'Ez az oldal az eredményt mutatja, vagy csak a funkciót?'

Az orvos kórtörténeti űrlapja nem teszi egyformává az összes diagnózist; megbízhatóvá teszi az orvost. Az Ön keretrendszere ez az űrlap. Az ügyfél továbbra is egyedi weboldalt kap, de Ön egy megismételhető diagnosztikát. Az, ami valójában általánossá teszi a munkáját, a diagnosztika hiánya – mert nélküle ugyanarra a főképre, ugyanarra a három oszlopos funkcióelrendezésre, ugyanarra a honlapszerkezetre támaszkodik, mint az előző projektnél, csak hogy gyorsan haladjon. A diagnosztika arra kényszeríti, hogy a bizonyítékokból indokolja a szerkezetet, így minden weboldal szerkezetileg ott különbözik, ahol annak kell.

A gyakorlatban ez azt jelenti, hogy a diagnosztika azt mondhatja Önnek, hogy az egyik ügyfél funkcióoldalát egy importáló varázsló videójával kezdje, a másikét pedig egy drag-and-drop jelentéskészítő GIF-jével. Az oldal szerkezete ugyanaz marad, de az eszközök, a szöveg és a ritmus egyediek. Az ügyfél egyedi munkát lát; Ön egy megismételhető folyamatot. Amikor bemutatja a diagnosztikát az ügyfélnek, azt demonstrálja, hogy tudja, mit kell teljesítenie minden SaaS-weboldalnak. Ez erősebb ajánlat, mint hogy 'egyedi dizájnt fogunk készíteni.' A dizájn a diagnózis következménye, nem pedig kiindulópont.

'Nincs időnk minden oldalt auditálni'

Végezze el a fókuszált 90 perces változatot, ne a teljes auditot. A legtöbb ügynökségi felderítési folyamat valójában már audit, csak éppen strukturálatlan. Negyvenöt percet tölt egy felmérő hívással, amely lefedi a hátteret, a versenytársakat és azt, hogy 'mit is szeretnél ebből,' majd hetekig reagál. A diagnosztika ezt megfordítja: pontozza az öt feladatot, felsorolja a legnagyobb hatású javításokat, és áttér a tervezésre. Időt takarít meg, mert nem kell újra elvégeznie a munkát az első tervezési áttekintés után. A legolcsóbb javítások azok, amelyeket még azelőtt végez el, hogy bárki is képpontokat látna.

Itt van egy konkrét 90 perces bontás: az első blokk (30 perc) átnézi a kezdőlapot és a funkciók oldalát az öt feladatra. A második blokk (30 perc) átfutja az árak oldalát és a GYIK-et. A harmadik blokk (15 perc) ellenőrzi, hogy az API-dokumentáció megválaszolja-e, hogy 'ki tudom-e exportálni az adatokat,' az utolsó 15 perc pedig felsorolja a főbb javításokat és a felelősöket. Nem kell minden oldalt elejétől a végéig elolvasnia; csak azt kell megállapítania, hogy az adott feladat teljesül-e. Ha az árak oldalán nincs GYIK, a tervezést hamarabb jóváhagyják, ha ezt még azelőtt észreveszi, hogy felvázolná a negyedik árkategóriát. Ha az API-dokumentáció belső szabványnak íródott, nem pedig a fejlesztői szabványnak, ezt már a szövegíró eligazítása előtt tudni fogja.

Az egyik megbízás során a diagnosztika feltárta, hogy a célvásárló retteg az adatmigrációtól. A válaszhoz hozzáadott GYIK két óra munkába került. Diagnosztika nélkül ez a félelem végigkísérte volna a tervezést, a fejlesztést, és a bevezetés utáni támogatási túlterheléshez vezetett volna. A 90 perces verzió nem a projektet megelőző fázis; ez a projekt első fázisa. Ezenkívül becsületes becslési módot ad: a foglalkozás végén Ön a létező és nem létező dolgok listájával távozik, így az ajánlat, amelyet ír, bizonyítékokra, nem pedig feltételezésekre épül.

'Az én nem technikai ügyfelemnek nincs szüksége API-dokumentációra'

Használjon döntési fát, nem pedig ellenőrzőlistát: ha a termék rendelkezik nyilvános API-val vagy integrációs történettel, az API-dokumentáció alapvető oldal; ha nem, tudatosan hagyja ki. Az API-dokumentációval kapcsolatos kutatások őszinték: az olyan cégek, mint a Stripe, a GitHub és a Twilio határozzák meg a dokumentáció tisztaságának mércéjét, mert a fejlesztőik gyakorlatilag a vásárlók. Ha ügyfelének van fejlesztőknek szóló integrációja, a dokumentáció nem fejlesztői kényelem, hanem bizalmi eszköz, amely az árak oldala mellett helyezkedik el. Egy nem technikai vásárló soha nem nézi meg, de a vásárlást értékelő fejlesztő feltétlenül meg fogja.

A döntési fa a rendszer része. Amikor az ügyfél azt mondja, hogy 'nincs fejlesztői közönségünk,' tegyen fel egy kérdést: 'az Önök bevezetési folyamatának bármely része megköveteli-e, hogy egy fejlesztő kapcsolja a terméket egy másik rendszerhez?' Ha igen, a dokumentáció marad. Ha nem, kihagyja, és az erőfeszítést a GYIK-re és a társadalmi bizonyítékra fordítja. Alkalmazza ugyanezt a logikát a társadalmi bizonyítékra: az egyik ügyfélnek elég egy sor logó; a másiknak részletes ajánlásra van szüksége mérhető eredményekkel. A diagnosztika megmondja, melyikre van szükség, ahelyett hogy alapértelmezetten az összes begyűjthető logót használná. Ez a választás teszi a keretrendszert megismételhetővé anélkül, hogy merev lenne. Ha pontosan meg kell határoznia, mit jelent a 'világosság' a gyakorlatban, ez az API-dokumentációs útmutató végigvezeti a szerkezeten.

'De az ügyfelem funkciólistát akar, nem eredményeket'

Amikor az ügyfél azt mondja, hogy szeretné megmutatni a funkciókat, kérje meg, hogy nevezze meg azt a felhasználói feladatot, amelyet minden funkció elérhetővé tesz. Az általános feltételezés az, hogy a funkcióbemutató az, ahol megnyeri az eladást. A diagnosztika mást sugall: egy tipikus SaaS-weboldalon az árak oldala az, ahol a végső gondolati számítás történik, és a GYIK az, ahol az utolsó ellenvetés megoldódik. A funkcióbemutató elengedhetetlen, de a feladata szűk – megmutatni azt a pillanatot, amikor a termék értékessé válik. Egy hosszú funkciólista, mindegyik alatt egy bekezdéssel, ezt nem teszi meg.

Az ügyfelek ellenállnak ennek, mert a lista kézzelfoghatónak és könnyen jóváhagyhatónak tűnik. De egy ötven funkciót tartalmazó oldal átfutó látogatót eredményez, és az a látogató, aki átfut a funkciókat bemutató oldalon, már át is helyezte a figyelmét az árak táblázatára. Az Ön rendszerének feladata, hogy az ügyfelet kényelmesen érezze a kompromisszummal: nem távolítja el a funkciókat, hanem áthelyezi őket oda, ahol elolvassák. Egy jól elhelyezett GYIK, amely azt mondja, hogy 'integrálódunk azokkal az eszközökkel, amelyeket már használ,' gyakran többet ér, mint egy funkcióoldal, amely ugyanezt mondja rossz címszó alatt. Ez az a finomság, amelyet a legtöbb cikk kihagy, és pontosan az a fajta kompromisszum, amelyet egy diagnosztika egyértelművé tud tenni.

A diagnosztika védhető okot ad arra is, hogy ellenálljon a terjedelmi kúszásnak. Amikor egy ügyfél azt kéri, hogy adjon hozzá még egy sor funkciót a kezdőlaphoz, rámutathat a táblázatra, és azt mondhatja: 'ennek az oldalnak a feladata az eredmények megmutatása, nem a funkciók katalogizálása.' Egy általános oldalépítő létrehozhat funkciórácsot, de nem tudja eldönteni, hogy a rácsot videóra vagy GYIK-re kell-e cserélni. Ez a döntés az igazi termék, és ez az oka annak, hogy egy keretrendszer nem árucikké teszi a munkáját.

'Már van egy belső folyamatunk'

Ha az Ön ügynöksége rendelkezik kezdőlap-folyamattal vagy árak-ellenőrző listával, a kifogás általában az, hogy nem akarja lecserélni. Nem is kell. Az öt feladaton alapuló diagnosztika nem a kreatív folyamat helyettesítője; ez egy front-end, amely táplálja azt. A legtöbb belső folyamat problémája, hogy láthatatlan. A vezető tervező fejében élnek. A diagnosztika externalizálja a folyamatot, így egy junior csapattag elvégezheti az első átfutást, és Ön percek alatt ellenőrizheti. Ez az a megismételhetőség, amelyre valójában szüksége van egy több ügyfelet kiszolgáló ügynökségnél.

A látható folyamat megváltoztatja az ügyfelekkel folytatott beszélgetést is. Ahelyett, hogy 'saját, védett tervezési folyamatunk van,' azt mondhatja: 'minden SaaS-weboldal öt feladata alapján futunk egy diagnosztikát, majd a megállapítások köré tervezzük meg a weboldalt.' Az első mondat egy fekete doboz, amely idegessé teszi az ügyfeleket. A második egy világos módszer, amely beengedi őket. A diagnosztika az értékesítési története részévé válik, nem csak egy gyártási eszköz.

'Az ügyfél azt mondja, a jelenlegi weboldal rendben van'

A diagnosztika akkor is működik, ha az ügyfél nem akar mást, mint egy megújítást. Alapvonalat ad Önnek. Pontozza a jelenlegi weboldalt, és megmutatja, hogy egy adott oldal egy adott feladatot nem teljesít. Mondhatja: 'Az Ön GYIK oldala szervezett, de nem válaszol arra a kérdésre, amelyet az értékesítési csapata minden héten hall,' és ez tényeken alapuló ok a változtatásra, nem esztétikai preferencia. Ez gyakran a legkíméletesebb módja az újraindításnak: nem azt mondja az ügyfélnek, hogy a weboldala csúnya, hanem azt, hogy egy feladat nincs elvégezve.

Ez megvédi Önt attól a gyakori buktatótól is, amikor az ügyfél ragaszkodik egy kedvenc kezdőlapi elem megtartásához, amely rontja a konverziót. A diagnosztika szókincset ad Önnek ahhoz, hogy azt mondja: 'az az elem nem végez egyetlen feladatot sem az öt közül,' és az ügyfél látja a bizonyítékot. A kifogás ekkor már nem ízlés kérdése.

A diagnózis a termék

A megismételhetőség nem arról szól, hogy minden ügyfelet ugyanabba a sablonba szorítsunk. Arról szól, hogy olyan standard folyamatot futtassunk, amely felszínre hozza minden ügyfél egyediségét. Az öt feladaton alapuló diagnosztika kevesebb mint két órát vesz igénybe, közös nyelvet ad a csapatának, és világos döntési listát ad az ügyfélnek. Az az ügynökség, amely egységes diagnosztikát tud ígérni, egy hét alatt megszerezhet egy ügyfelet, és egy hónap alatt szállíthat, nem azért, mert a munka könnyebb, hanem azért, mert a felderítés kiszámítható. És amikor az ügyfél megkérdezi, miért kell ilyen sok kérdést feltenni, a válasz egyszerű: nem próbál szerepelni, hanem diagnosztizál.

Ha mélyebben szeretné látni, hogyan működik együtt a funkcióbemutató és az árak oldala, és miért tartanak ki a körülöttük lévő mítoszok, nézze meg ezt a mítoszromboló útmutatót.