Lopeta ominaisuuksien myyminen, myy vaihto

Yhteenveto

Asiakkaasi SaaS-sivusto ei epäonnistu, koska se näyttää huonolta. Se epäonnistuu, koska se ei koskaan vastaa ainoaan kysymykseen, jolla on merkitystä: miksi minun pitäisi vaihtaa? Toimistotyössä et voi rakentaa ainutlaatuista suostuttelumallia jokaiselle tuotteelle. Käytä sen sijaan samaa viiden kysymyksen auditointia löytääksesi vaihdon laukaisimen mille tahansa SaaS-tuotteelle. Sovella sitten sitä laukaisinta jokaisella sivulla: ominaisuuksista tulee todisteita, hinnoittelusta selkeyttä, UKK:sta vastaväitteiden murskaaja ja API-dokumenteista kehittäjän ensimmäinen voitto. Tämä malli muuttaa kertaluonteisen uudistuksen toistettavaksi prosessiksi. Tuloksena: nopeampi toimitus, vähemmän tarkistuskierroksia ja sivuja, jotka oikeasti konvertoivat.

Asiakkaallasi ei ole suunnitteluongelmaa. Sillä on vaihto-ongelma. Ostajalla on jo työkalu, työnkulku ja tiimi, joka vihaa muutoksia. He eivät vertaa asiakkaasi ominaisuuksia tyhjään sivuun. He vertaavat siinä pysymisen kipua sieltä lähtemisen kipuun. Sivuston tehtävä ei ole luetella, mitä tuote tekee. Sen tehtävä on saada vaihto näyttämään helpommalta ja arvokkaammalta kuin status quo. Jos se ei tee sitä, sivusto on tapettia.

Toimistossa työskennellessäsi tunnet tämän konkreettisesti. Otat SaaS-asiakkaan, perustaja sanoo 'tarvitsemme modernit sivut', ja kaikki olettavat, että korjaus on visuaalinen. Se ei ole. Voit pakata palkitun muotoilun väärään viestiin, ja se konvertoi täsmälleen samoin kuin vanha sivusto. Mutta kun löydät vaihdon laukaisimen, viesti tekee raskaan työn. Sinun on vain löydettävä se nopeasti — jokaiselle asiakkaalle, joka kvartaali, toimialoilta, joita et vielä tunne. Siksi tarvitset mallin, jota voit käyttää heti ensimmäisestä päivästä ilman kolmen kuukauden löytövaihetta.

Mieti, mitä vaihto vaatii: datan viemisen, tiimin kouluttamisen, uuden käyttöliittymän opettelun, tapojen muuttamisen. Sivustosi on saatava tämä sarja tuntumaan väistämättömältä. Ominaisuuslista ei siihen pysty. Selkeä kuva elämästä vaihdon jälkeen pystyy. Se kuva on viesti. Kaikki muu sivustolla tukee sitä.

Tässä on malli: määrittele vaihto. Pakota sitten jokainen sivu argumentoimaan sen puolesta.

Vastaväite	Mitä se oikeasti suojaa	Mitä tehdä sen sijaan
'Jokainen asiakas on erilainen.'	Pelkosi malleja kohtaan	Löydä vaihdon laukaisin viiden kysymyksen auditoinnilla
'Tarvitsemme lisää kuvakaappauksia.'	Tyhjien osioiden pelko	Korvaa tuotekuvat todisteilla
'Hinnoittelu on pyhää.'	Talousjohtajan ahdistus	Käytä selkeyttä vähentämään hintashokkia
'API-dokumentit ovat devaajan ongelma.'	Dev-tiimin portinvartijuus	Kohtele dokumentteja suostuttelevana välineenä
'UKK on tylsää.'	Tuen ylikuormitettu postilaatikko	Käytä UKK:ta viime hetken epäilyjen sulkemiseen
'Meillä ei ole aikaa räätälöidä.'	Perfektionismi toimitusta vastaan	Rakenna luuranko, älä lumihiutaletta

Käytä tätä taulukkoa tarkistuslistana ensimmäisessä palaverissa. Mikään vastaväite siinä ei ole todellinen este. Se on pyyntö erilaiselle mallille.

'Jokainen asiakas on erilainen' on totta — ja merkityksetöntä

Tässä on muutos: tuote on erilainen, markkina on erilainen, ostajan käyttäytyminen ei ole. Ostajat haluavat kolme asiaa: 'Ymmärränkö tämän?' 'Voinko luottaa siihen?' 'Onko vaihto halvempaa kuin jääminen?' Se on universaalia. Älä siis standardoi muotoilua. Standardoi kuulustelu.

Aloita viiden kysymyksen auditoinnilla. Tee se ensimmäisessä löytöpuhelussa. Se vie kaksikymmentä minuuttia ja toimii mille tahansa SaaS-tuotteelle.

• Kuka on käyttäjä ja kuka on ostaja? (He ovat harvoin sama henkilö.)
• Mitä he tekevät tänään asiakkaasi tuotteen sijasta?
• Mikä on se yksittäinen ärsyttävä kipu nykyisessä työnkulussa?
• Mitä he pelkäävät menevän rikki, jos he vaihtavat?
• Mikä on nopein 'voitto', jonka he saisivat heti vaihdon jälkeen?

Käy läpi kaksi asiakasta nähdäksesi, miten se toimii.

Ensimmäinen on projektinhallintatyökalu. Käyttäjä on tiiminvetäjä, ostaja on myös tiiminvetäjä. Se tekee saman kuin nykyinen työkalu. Kipu? Kukaan ei tiedä, kuka omistaa seuraavan tehtävän. Pelko? Sadojen projektien siirtäminen ja kaiken statuksen menettäminen. Nopea voitto? Hallintapanelointi, joka näyttää tehtävien omistajuuden yhdellä silmäyksellä. Laukaisin: 'Älä koskaan enää jahtaa tehtävän omistajaa.' Se on otsikko.

Toinen on kiinteistöalan liidien seuranta. Käyttäjä on välittäjä, ostaja on välittäjä. Kipu? Päällekkäisiä liidejä ilmestyy kolmeen paikkaan, ja hyvät kylmenevät. Pelko? Välittäjät eivät kirjaa tietoja. Nopea voitto? Automaattinen rikastaminen MLS-listauksista, joten välittäjät ovat valmiita kahdella klikkauksella. Laukaisin: 'Älä koskaan menetä liidiä kahdesti.'

Samat viisi kysymystä. Kaksi erilaista tuotetta. Sinulla on nyt keskeinen viesti etusivulle, ominaisuusosion ensimmäinen kappale ja sähköpostisarjan otsikkorivi. Vaihdon laukaisin on uusiutuva resurssi: jokainen sivu, jokainen osio, jokainen väliotsikko voi argumentoida sen puolesta. Se on lähtöviivasi.

Sama laukaisin antaa sinulle myös sivukartan. Sivu, joka selittää laukaisimen, on etusivu. Sivu, joka todistaa laukaisimen, on ominaisuusosio. Sivu, joka poistaa pelon, on UKK. Sivu, joka näyttää vaihdon hinnan, on hinnoittelusivu. Yhtäkkiä koko sivustolla on yksi tarina sen sijaan, että jokainen sivu olisi oma komiteansa.

Voit myös tehdä kilpailija-analyysin kysymällä samat viisi kysymystä kilpailijan sivustosta. Se on halpa tapa osoittaa arvoa ensimmäisessä puhelussa. Löydät kilpailijan puuttuvan vaihdon laukaisimen, ja asiakkaastasi tulee ilmeinen vaihtoehto.

Entä jos tuote on mukava lisä, ei kivunlievittäjä? Silloin vaihdon laukaisin on isompi: säästetty raha, vältetty riski tai saavutettu status. Vaatimustenmukaisuustyökalulle laukaisin on 'vältä sakko.' Tietoturvatyökalulle laukaisin on 'läpäise auditointi.' Sosiaalisen median ajastimelle laukaisin on 'saa kaksi tuntia takaisin joka viikko.' Auditointi löytää sen silti. Jotkut laukaisimet ovat vain vähemmän emotionaalisia.

Kuvakaappaukset ovat sivun alhaisin arvoinen todiste

Ota asiakkaasi ominaisuustaulukon yksinäisin rivi: 'OAuth 2.0-tuki.' Mitä tunnetta se herättää? Ei mitään. Se on tarkistuslistan kohta kehittäjälle, joka ei ole ostaja. Kun pyydät asiakkaalta ominaisuussivua, he antavat sinulle seinällisen näitä. Täytä sivu kuvakaappauksilla, ja teet jotain vielä yleisempää: näytät tuotteen tuloksen sijaan.

Kuvakaappauksilla on paikkansa. Hyvä GIF tuotteesta toiminnassa on todiste. Mutta useimmat kuvakaappaukset ovat tuotemuotokuvia. Ostajat tarvitsevat ennen-jälkeen-tarinan. Ominaisuusosio on paras paikka kertoa se. Käytä Ominaisuus-Hyöty-Todiste-mallia (FBP). Nimeä ominaisuus, yhdistä se hyötyyn ja todista se faktalla, prosessilla tai pienellä demolla. Ei keksittyjä lukuja — käytä havaittavia tuloksia, kuten 'toimii Google Workspacen kanssa' tai 'asennus alle minuutissa.'

Alkuperäinen lohko asiakkaalta:

• OAuth 2.0-tuki
• Roolipohjainen pääsynhallinta (RBAC)
• SCIM-provisiointi

Kolme bulletia toimittajajargonia. Nyt käännä jokainen FBP:n läpi.

Ominaisuus: OAuth 2.0-tuki.
Hyöty: Yksi kirjautuminen koko tiimille. Ei enää IT-tikettejä.
Todiste: Toimii Google Workspacen ja Microsoft Entran kanssa.

Ominaisuus: Roolipohjainen pääsynhallinta.
Hyöty: Anna ylläpitäjille, muokkaajille ja katselijoille täsmälleen tarvittavat oikeudet.
Todiste: Myönnä katseluoikeus ulkopuoliselle alle minuutissa.

Ominaisuus: SCIM-provisiointi.
Hyöty: Lisää ja poista käyttäjiä automaattisesti HR-järjestelmästäsi.
Todiste: Synkronoi Oktan ja Ripplingin kanssa.

Ominaisuudet eivät muuttuneet. Suostuttelu muuttui. Asiakkaasi sanoo: 'Mutta yritysostajat odottavat näkevänsä sanat OAuth ja SCIM.' Totta. Lisää tekninen alarivi kehittäjille, jotka auditoivat sivun. Mutta laita se rivi pienellä fontilla hyödyn alle. Ensimmäinen yleisö on ostaja, joka päättää, varaako tapaamisen. Toinen yleisö on kehittäjä, joka ruksii kohtia. Rakenna ominaisuuksien esittely todisteiden ympärille, älä tuotekuvien, niin lopetat täyteaineen suunnittelun.

Kun käytät kuvakaappausta, näytä siinä tulos, ei näyttöä. Projektinhallinta-asiakkaalle kuvakaappaus taulusta, jossa jokaisella tehtävällä on selkeä omistaja, on todiste. Kiinteistöasiakkaalle kuvakaappaus yhdestä siististä kontaktitietueesta automaattisesti rikastetulla datalla on todiste. Kuvakaappaus hallintapaneelin tyhjästä tilasta on suunnitteluassets, ei suostutteluassets.

Laita tekniset tiedot taitettavaan osioon tai kehittäjien resurssivälilehteen. Käyttäjä näkee hyödyn; kehittäjä voi sukeltaa syvemmälle. Se pitää sivun siistinä ja auditoijan tyytyväisenä.

Hyvä testi mille tahansa ominaisuusväitteelle: toistaisiko ostaja sen pomolleen? 'Yksi kirjautuminen' on toistettava. 'OAuth 2.0-tuki' ei ole. Jos asiakkaasi ominaisuussivu ei läpäise vesijäähdytintestiä, se ei ole vielä suostutteleva.

Hinnoittelusivut ovat miinakenttä. Siksi niihin pitää koskea

Tulet kuulemaan: 'Älä koske hinnoitteluun. Se on ollut tällainen vuosia.' Mitä he oikeasti sanovat, on 'olemme peloissamme.' Sekava hinnoittelusivu ei suojaa liikevaihtoa; se vuotaa sitä. Sinun tehtäväsi on muuttaa sivu kustannusneuvottelusta selkeyslauseeksi.

Aloita listaamalla kysymykset, joihin myyntitiimisi vastaa joka viikko. Kirjoita ne sanatarkasti. 'Velotatteko käyttäjältä?' 'Mitä tapahtuu, jos siirryn halvempaan suunnitelmaan?' 'Onko perustamismaksua?' 'Voinko kokeilla ilman luottokorttia?' 'Mikä on palautuskäytäntönne?' Laita ne sivulle. Ostajan ei pitäisi joutua varaamaan puhelua oppiakseen, vaaditaanko kokeiluun luottokortti.

Ota seuraavaksi asiakkaan kolme suunnitelmaa: Basic, Pro, Enterprise. Nimeä ne uudelleen asiakkaan tilanteen mukaan. Mitä kukin suunnitelma oikeasti tekee jollekin? Solo, Team, Organization. Tai Creator, Studio, Enterprise. Nimi ei ole koriste; se on ensimmäinen selkeyden hetki.

Tässä on konkreettinen esimerkki uudelleennimetystä suunnitelmataulukosta:

Vanha suunnitelma	Uusi suunnitelma	Lupaus
Basic	Solo	Yhdelle henkilölle, joka tarvitsee yksinkertaisen työnkulun
Pro	Team	Tiimille, joka tarvitsee yhteistyötä ja hallintapaneeleita
Enterprise	Org	Yritykselle, joka tarvitsee tietoturvaa, SSO:ta ja tukea

Rakenna sitten vertailutaulukko. Katkaise kaava, jossa jokainen ominaisuus kaadetaan jokaiseen riviin. Johda jokainen rivi käyttäjäkysymyksellä, johon se vastaa. 'Kuinka monta käyttäjää?' 'Keitä voimme kutsua?' 'Mitä tietoturvaominaisuuksia saamme?' Ostaja lukee taulukkoa etsiäkseen 'sovinko minä.' Tee siitä etsinnästä helppoa.

Lisää lopuksi hinnoittelun UKK. Vastaa ikävään kysymykseen: 'Mitä datalleni tapahtuu, jos lähden?' Kirjoita vastaus kuin ihminen: 'Vie kaikki yhdellä klikkauksella ennen tilauksen päättymistä. Ei maksuja, ei lukkoja.' Se on vaihdon luottamuksen rikkoja. Useimmat asiakkaat eivät kirjoita sitä, koska se tuntuu kutsulta lähteä. Se ei ole. Se on lupa ostaa ilman pelkoa.

Toimistollasi on tässä sisäänrakennettu etu: olet jo tehnyt viiden kysymyksen auditoinnin, joten tiedät pelon. Laita pelko UKK:hon. Jos tarvitset mallin aloittamiseen, hinnoittelusivun konversio-opas on se malli.

Älä anna asiakkaan piilottaa hintoja. 'Ota yhteyttä' -sivu on muuri. Vaihto tarvitsee numeron, johon verrata. Jos hinta on korkea, sivun pitäisi selittää, mitä se sisältää ja miksi se on sen arvoista. Jos hinta on matala, ankkuroi se status quon kustannuksiin. Projektinhallintatyökalulle status quo on kolme erillistä työkalua: tehtäväsovellus, chattisovellus ja laskentataulukko. Vaihdon hinta ei näytä korkealta, kun vertaat sitä kaikkien kolmen kuukausikustannuksiin. Tee tuo vertailu näkyväksi sivulla.

Kun kirjoitat hinnoittelun UKK:ta, älä käytä myyjän kieltä. Sano 'sinä' ja 'sinun datasi.' Hinnoittelusivu, joka käyttää koko ajan 'me tarjoamme, me tarjoamme', tuntuu yritysesitteeltä. Käännä se muotoon 'voit, sinun tiimisi.' Se on vaihto, joka tapahtuu kieliopissa.

Voit testata hinnoittelun UKK:ta samalla tavalla kuin mitä tahansa muuta: lue se ääneen. Jos muukalainen pöydän toisella puolella rentoutuisi, se on hyvä. Jos he nostaisivat kätensä myyjälle, olet lisännyt kitkaa.

Dokumentit, joita ignoroit, sulkevat (tai tappavat) kauppoja

Tässä on kehittäjä läppärin äärellä. Hän arvioi asiakkaasi APIa. Hänen pomonsa kysyi: 'Voimmeko integroida tämän?' Hän haluaa yhden asian: todisteen siitä, että hänen tiiminsä ei hukkaa viikkoa. Hän ei aloita referenssidokumenteista. Hän aloittaa pika-aloituksesta.

Yritykset kuten Stripe, GitHub ja Twilio asettavat standardin API-dokumenteille. Salaisuus ei ole se, että he dokumentoivat jokaisen päätepisteen kauniisti. Se on se, että he saavat ensimmäisen suorituksen kestämään viisi minuuttia. He näyttävät pienen tuloksen, joka näyttää menestykseltä. Se on kehittäjän vaihdon laukaisin: välitön, konkreettinen edistyminen.

Asiakkaasi API-dokumentit ovat ensimmäinen sivu, jonka tekninen ostaja lukee etusivun jälkeen. Jos se lukee kuin puhelinluettelo, kauppa kuolee hiljaa. Dokumentit ovat markkinointiomaisuutta, eivät tekninen velvollisuus. Tee siis näin:

Laita pika-aloitus kaiken muun edelle. Esimerkki. Asiakkaasi rakentaa dokumenttiautomaatio-APIa. Referenssi on tiheä sisällysluettelo, joka jatkuu tuhansia rivejä. Kehittäjä saapuu, näkee 'Authentication' ja menettää intohimon.

Uudelleenjärjestä dokumenttien alku:

1. Kirjoita kolmen lauseen kuvaus selkeällä kielellä. 'Lähetä sopimus, saat takaisin allekirjoitetun kappaleen. Tämä API muuttaa mallit ja datan allekirjoitetuiksi PDF-tiedostoiksi.'
2. Liitä kopioi-liitä-koodiesimerkki, joka kutsuu hiekkalaatikon päätepistettä. Näytä ensimmäinen vastaus-JSON, joka todistaa onnistumisen.
3. Lisää yksi käyttötapaus, 'Itsekokoonpanevat laskut', ja linkitä asiaankuuluvat päätepisteet.

Siirrä täysi referenssi alemmas. Kehittäjä, joka kopioi ensimmäisen pätkän, muuttuu sisäiseksi puolestapuhujaksi. Puolestapuhuja pyytää tietoturvatarkistusta, ei hylkäystä. Asiakkaasi voittaa ennen myyntipuhelua. API-dokumentaatio-opas käy läpi saman prosessin.

Käyttötapaus on lupaus reitin kanssa. Dokumenttiautomaatio-asiakkaalle kirjoita 'Itsekokoonpanevat laskut: lähetä ostotilausnumero ja saat muotoillun laskun, rivit ja PDF:n takaisin yhdellä kutsulla.' Se ei ole dokumenttisivu; se on myyntisivu, joka sattuu sisältämään koodia.

Sisällytä upotettu API-avain hiekkalaatikkoa varten. Heti kun kehittäjä voi liittää ja nähdä onnistumisen, vaihdosta tulee todellinen. Ei myyntipuhelua tarvita.

Dokumenttisivu ruokkii myös hakukoneoptimointia. Kehittäjät etsivät tarkkoja virheilmoituksia ja integraationimiä. Kirjoita sivuja niille kyselyille: kappale jokaiselle virhekoodille, sivu jokaiselle integraatiolle. Niin dokumenteista tulee kanava.

Käytä pysyvää sivupalkkia, jossa on 'kokeile nyt' -painike. Lisää hakupalkki, joka indeksoi koodiesimerkit. Mitä sujuvampi haku, sitä pätevämmältä yritys näyttää. Äläkä unohda alle 90 sekunnin videota, joka näyttää toimivan esimerkin, ei yrityksen yleisesittelyä.

UKK ei ole tukisisältöä. Se on viimeisen esteen konversio

'Kukaan ei lue UKK:ta' — niin kuulet, kunnes muistat, kuka lukee: ostaja hiljaisessa huoneessa, epäröimässä kysyä kysymystä. UKK on sivu, jossa kaupat sulkeutuvat yksityisesti. Kohtele sitä sellaisena.

HubSpot, Slack ja Zendesk tekevät tämän oikein. Heidän UKK- ja ohjeosionsa ovat organisoituja, haettavissa ja ytimekkäitä. Se rakenne on pointti. Se viestii pätevyydestä. Haettava UKK saa ostajan ajattelemaan: nämä ihmiset ovat miettineet minun ongelmaani.

Tässä on halvin parannus, jonka voit tehdä minkä tahansa asiakkaan sivustoon tänään: järjestä olemassa oleva UKK neljään ostovaiheen ämpäriin: Aloittaminen, Hinnoittelu ja laskutus, Tietoturva ja vaatimustenmukaisuus, Vaihto ja siirtyminen. Kirjoita sitten yksi vastaus uudelleen jokaiseen ämpäriin.

Tehdään vaihtoämpäri. Nykyinen vastaus kysymykseen 'Kuinka vaikeaa siirtyminen on?' sanoo: 'Tuontityökalumme tukee CSV:tä ja APIa.' Se on ominaisuuslista. Kirjoita se uudelleen lupaukseksi plus vaihelistaksi:

'Tuomme datasi puolestasi. Lähetä CSV, ajamme kuivan ajon, vahvistat otoksen, ja teemme siirron 30 minuutin ikkunassa. Jos jokin näyttää väärältä, palaamme välittömästi takaisin.'

Vertaa nyt kahta vastausta. Kumpi sulkee kaupan? Ensimmäinen kuvailee mekanismin; toinen kuvailee turvallisen prosessin. Se on sama rakenne kuin ominaisuussivulla: hyöty plus todiste.

Mene pidemmälle: poimi jokainen kysymys, johon tuki vastaa kahdesti viikossa, ja kirjoita vastaus ennen kuin tiketti syntyy. Se on loputon laskutusmaan sisällön lähde. Kun UKK lakkaa olemasta kaatopaikka ja alkaa olla suostuttelutyökalu, koko tarina pysyy yhtenäisenä. Se on osa sisältä ulospäin -lähestymistapaa, jota käytät kaikessa muussakin.

Järjestä haku mielessä. Haettava UKK, joka löytää vastauksen yhdellä näppäinpainalluksella, tuntuu tuoteominaisuudelta. Se on juuri se pätevyyssignaali, jonka haluat.

Älä pakota ostajia avaamaan erillistä tukikeskusta. Laita UKK sivulle, joka herätti kysymyksen. Jos hinnoittelukysymys ilmestyy hinnoittelusivulle, vastaa siellä. Jos tietoturvakysymys ilmestyy hinnoittelusivulle, vastaa myös siellä. Vastaus kuuluu epäilyksen kohtaan.

Tietoturvaämpäri on paikka, jossa IT päättää estää työkalun. Vastaa asioihin, kuten 'Missä dataa säilytetään?' yksityiskohtaisesti. Jos sanot 'EU:ssa', sano alue. Jos sanot 'salattu levossa', nimeä standardi. Ytimekäs vastaus on vahvempi kuin whitepaper-linkki.

Jokaisen UKK-vastauksen tulisi olla mahdollisimman lyhyt ja päättyä seuraavaan vaiheeseen: 'Rekisteröidy hiekkalaatikko tilillä' tai 'Keskustele tuen kanssa.' Vastaus ilman seuraavaa vaihetta on umpikuja.

Ei aikaa? Rakenna luuranko, älä lumihiutaletta

Viimeinen vastaväite on se, jonka luultavasti tunnet juuri nyt: 'Mutta minulla on neljä asiakasta ja deadline maanantaina.' Reilua. Kohtele jokaista projektia yksilöllisenä muotokuvana, ja olet aina paniikissa. Rakenna sen sijaan yksi uudelleenkäytettävä toimitus: Vaihtomuistio. Sen täyttäminen vie 90 minuuttia, ja se hahmottelee jokaisen sivun.

Vaihtomuistio — yksi sivu, kuusi riviä:

1. Käyttäjä/ostaja-jako: kuka ilmestyy, kuka maksaa.
2. Nykyinen käyttäytyminen: mitä he tekevät tänään sen sijaan.
3. Yksittäinen kipu: yksi lause, se ärsytys.
4. Pelko: mitä he pelkäävät menevän rikki vaihdossa.
5. Nopea voitto: ensimmäinen näkyvä parannus vaihdon jälkeen.
6. Todiste: logot, tulokset tai tietoturva-asennot, jotka poistavat pelon.

Tuo tämä ensimmäiseen löytöpuheluun. Täytä se samalla kun kysyt viisi kysymystä. Mennessäsi takaisin työpöydällesi sinulla on viestin runko. Etusivun otsikko on nopea voitto. Ominaisuussivun johdanto on kipu. Hinnoittelutaulukon keskimmäinen sarake on ostaja. UKK on pelkolista. API-dokumenttien pika-aloitus on nopea voitto kehittäjille.

Tämä luuranko ei tee jokaisesta sivustosta identtistä. Se tekee jokaisesta sivustosta suostuttelevan samalla tavalla. Suunnittelet edelleen jokaisen asiakkaan äänellä, mutta lopetat viestin alisuunnittelun. Jos viesti on jo selvillä, voit tuottaa ensimmäisen luonnoksen jokaisesta sivusta päivässä. Toimiston todellinen tuote on prosessi, ei pikseli.

Tässä on muutos: et enää suunnittele sivustoja uudelleen. Asemoit ne uudelleen. Ja koska vaihtomalli toimii toimialasta riippumatta, voit veloittaa strategiasta, toimittaa sen toistettavassa muodossa ja luovuttaa toimituksia, jotka oikeasti konvertoivat. Seuraavan kickoffin tulisi alkaa viiden kysymyksen auditoinnilla, ei moodboardilla.

Käytä muistiota asiakkaan odotusten asettamiseen varhain. Perustaja näkee, että sivusto ei ole taideprojekti; se on suostutteluasiakirja. Se estää 'laita se vaan poksahtamaan' -palautteen ja kääntää keskustelun tuloksiin. Jaa muistio asiakkaan sisäiselle markkinointitiimille, jotta he voivat kirjoittaa uusia sivuja myöhemmin keksimättä viestiä uudelleen.

Kun esität sivuston, aloita vaihtomuistiosta, et muotoilusta. Asiakkaat hyväksyvät strategian nopeammin kuin estetiikan. Saat vähemmän 'voimmeko suurentaa logoa' -pyyntöjä, koska olet antanut heille syyn arvioida sivua viestin perusteella.

Vaihto on strategia. Kaikki muu on koristelua.

Ota tästä yksi asia: älä tilaa uutta uudistusta, ennen kuin olet vastannut vaihtokysymykseen. Useimmat SaaS-sivustot epäonnistuvat, koska kävijät eivät koskaan löydä syytä hylätä nykyistä työnkulkuaan. Sivusto ei epäonnistu siksi, että logo on liian pieni tai gradientti on vanhentunut.

Seuraavan kickoff-puhelusi tulisi olla viiden kysymyksen auditointi. Jos perustaja ei osaa artikuloida vaihtoa, työnnä häntä. Jos osaat artikuloida sen, jokaisella sivulla on tehtävä: ominaisuussivut todistavat sen, hinnoittelusivut oikeuttavat sen, UKK-sivut puolustavat sitä ja API-dokumentit osoittavat sen. Toimitat paremman tuotteen nopeammin. Ja sinulla on malli, jota voit käyttää jokaiselle asiakkaalle aina.

Vaihtokehystetty sivusto myös paranee ajan myötä. Sinulla on nyt hypoteesi — laukaisin — ja voit testata sitä heatmapien, istuntotallenteiden tai A/B-testien avulla. Malli muuttaa uudistuksen tapahtumasta kokeiluksi.

Et tarvitse 40-sivuista strategiapakkausta. Tarvitset kuusi riviä ja halukkuuden sanoa ei sivuille, jotka eivät palvele vaihtoa. Se selkeys on sitä, mistä asiakkaat maksavat sinulle.

Lopeta ominaisuuksien myyminen. Myy vaihto. Se on koko strategia.