Pyysin kerran tekoälyä tekemään verkkosivutekstistä ammattimaisemman. Se teki juuri niin. Teksti oli sujuvaa, huoliteltua ja niin vierasta, etten olisi itse sanonut siitä yhtäkään lausetta.
Tyhjän paperin syndrooma on nykyään helppo ratkaista. Tekstiä saa ruudulle niin paljon kuin jaksaa pyytää. Minun tapauksessani lopputuloksena oli kolme kappaletta hajutonta ja mautonta yritystekstiä, joka olisi voinut olla kenen tahansa kirjoittamaa.
Kiinnostavampi ongelma alkaa vasta sen jälkeen. Jonkun pitää edelleen päättää, mikä tässä on lukijalle olennaista, missä järjestyksessä asiat kannattaa kertoa ja mitä lukijan pitäisi tehdä seuraavaksi. Jos näitä ei ole päätetty, tekoäly täydentää puuttuvat asiat itse. Lopputulos voi olla sujuva, mutta helposti myös sellainen, jossa kaikki saa saman painoarvon.
Eppu Normaalilla on kokonainen kappale siitä, ettei tekstiä synny. Nyt reppuni jupiset riimisi rupiset nauratti minua jo ensimmäisellä kuuntelulla. Martti Syrjä jos kuka osaa kirjoittaa, mutta näköjään hänkin on joskus joutunut aloittamaan siitä, ettei päästä tule mitään.
AIDA, PAS ja FAB ovat minulle hyödyllisiä juuri tässä kohdassa. En ajattele niitä sääntöinä tai psykologisina temppuina, vaan kolmena tapana järjestää sama aineisto eri tavalla sen mukaan, mitä tekstillä halutaan saada aikaan.
Jokaisen osion lopussa on prompti, jonka voi kopioida omaan työhön. Ne eivät pyydä tekoälyä vain ”kirjoittamaan AIDAlla”, vaan käymään ensin lähtöaineiston läpi ja kysymään, jos jotain olennaista puuttuu.
Käytän seuraavissa esimerkeissä yhtä täysin kuvitteellista B2B-tuotetta. Se ei perustu asiakastyöhön tai olemassa olevaan tuotteeseen. Lähtötiedot ovat tarkoituksella niukat:
- tuote on projektityökalu tuote- ja suunnittelutiimeille
- siinä on päätösloki, joka liitetään projektin tehtäviin
- lokiin tallennetaan päätös, perustelu, tekijä ja päivämäärä
- päätöksiä etsitään nyt kokousmuistioista, sähköpostista ja keskustelukanavista
- seuraava askel on varata 20 minuutin esittely
- meillä ei ole vielä asiakastuloksia, säästettyjä tuntimääriä tai muita todisteita
Viimeinen kohta on yhtä tärkeä kuin muut. Kun näyttöä ei ole, tekoäly ei saa keksiä sitä.
AIDA: huomio, kiinnostus, halu ja toiminta
Olet avaamassa uuden palvelun laskeutumissivua. Ensimmäinen lause lupaa ”uuden sukupolven kokonaisvaltaista ratkaisua”. Suljet välilehden tietämättä edelleenkään, oliko palvelu sinulle. Huomio ehkä heräsi sekunniksi, mutta syytä kiinnostua ei tullut.
AIDA auttaa juuri tässä: ensin lukijan pitää tunnistaa, että asia koskee häntä. Sen jälkeen hänelle pitää antaa syy kiinnostua ratkaisusta ja lopuksi tehdä seuraava askel selväksi. Mallin neljä vaihetta ovat Attention, Interest, Desire ja Action eli huomio, kiinnostus, halu ja toiminta. Tässä yksi esimerkki:
Huomio
Kun projektiin palataan kuukauden päästä, muistaako kukaan enää, miksi jokin ratkaisu valittiin?
Kiinnostus
Päätösloki tallentaa projektin tehtävän yhteyteen päätöksen, sen perustelun, tekijän ja päivämäärän. Perusteluja ei tarvitse myöhemmin etsiä kokousmuistioista, sähköpostista tai keskustelukanavista.
Hyöty
Kun joku avaa tehtävän myöhemmin, hän näkee heti, mitä päätettiin ja miksi. Samoja perusteluja ei tarvitse selvittää tai käydä uudelleen läpi.
Toiminta
Varaa 20 minuutin esittely, niin näet, miten päätösloki toimii käytännössä.
Huomio-kysymys toimii, jos lukija tunnistaa tilanteen omakseen. Desire suomennetaan yleensä haluksi, mutta B2B-tekstissä ajattelen sitä mieluummin kysymyksenä: mitä tästä olisi lukijalle hyötyä? Vasta sen jälkeen pyydetään varaamaan esittely ja kerrotaan, mitä siellä tapahtuu.
Kiinnostus ja hyöty menevät helposti sekaisin, koska molemmissa puhutaan lukijan tilanteesta. Minulle ero on käytännössä tämä: kiinnostus saa ajattelemaan ”tämä koskee minua”, hyöty taas ”tästä voisi olla minulle hyötyä”. Ensimmäinen pitää lukijan mukana, toinen antaa syyn harkita seuraavaa askelta.
Jos aloitus on vain irrallinen huomionherättäjä, kiinnostus ei kanna pitkälle. Jos ominaisuuksista puhutaan ennen kuin niiden yhteys lukijan tilanteeseen on selvä, lukija joutuu itse päättelemään, miksi niillä on väliä. Ja jos lopussa pyydetään yhtä aikaa varaamaan tapaaminen, tilaamaan uutiskirje ja lataamaan opas, tekstiltä katoaa suunta. AIDA toimii parhaiten, kun koko teksti vie kohti yhtä seuraavaa päätöstä.
Kopioitava AIDA-prompti
Kirjoita lähdemateriaalista käyttövalmista tekstiä AIDA-rakenteella.
Kirjoitustehtävä:
- Tekstilaji ja paikka: [esim. laskeutumissivun yläosa, sähköposti, tuotejulkistus]
- Ensisijainen lukija: [kenelle teksti on tarkoitettu]
- Toivottu seuraava askel: [yksi konkreettinen toiminto]
- Toivottu pituus ja muoto: [esim. otsikko + 3 lyhyttä kappaletta + CTA]
- Sävy tai tyylirajoitteet: [kuvaa lyhyesti]
Lähdemateriaali:
[liitä tähän briiffi, muistiinpanot, haastattelu tai tuotetiedot]
Työskentele tässä järjestyksessä:
1. Poimi aineistosta todennettavat faktat, olennaiset tilanteet ja aineiston tukemat väitteet.
2. Rakenna niistä:
- Attention: aloitus, josta lukija tunnistaa heti, että aihe koskee häntä
- Interest: yhteys lukijan todelliseen tilanteeseen tai tehtävään
- Desire: aineistoon perustuva hyöty tai muutos lukijan kannalta
- Action: yksi selkeä seuraava askel
3. Jos kohderyhmä, tavoite, aineistoon perustuva hyöty tai toimintakehotus puuttuu, kysy ensin enintään viisi täsmällistä kysymystä. Älä luonnostele ennen vastauksia.
4. Kirjoita sitten käyttövalmis teksti. Älä selitä tai merkitse AIDA-vaiheita lopulliseen tekstiin.
Älä keksi ominaisuuksia, asiakasongelmia, todisteita, numeroita, tuloksia, suosituksia, kiirettä tai niukkuutta. Älä esitä mahdollista hyötyä varmana tuloksena. Kerro lähteiden ristiriidoista ennen luonnostelua.
Listaa lopuksi lyhyesti kunkin olennaisen väitteen kohdalla, mihin aineistoon se perustuu ja mikä siinä on vielä epävarmaa.PAS: ongelma ensin, ratkaisu vasta sitten
Moni tuote-esittely alkaa ratkaisusta. ”Päätöslokimme kokoaa projektin tärkeät päätökset yhteen.” Lause on selkeä, mutta lukija joutuu itse päättelemään, miksi hänen pitäisi välittää ominaisuudesta.
Tekoäly tekee tätä paljon, koska ratkaisu on usein briiffin parhaiten kuvattu osa. Tuotteen ominaisuuksista on dokumentaatio. Asiakkaan tilanteesta on ehkä yksi sivulause. Malli kirjoittaa siitä, mitä sille annettiin, ja lopputuloksena syntyy teknisesti siisti vastaus kysymykseen, jota kukaan ei vielä esittänyt.
PAS auttaa, kun yleisö tunnistaa jo todellisen ongelman. Käytännössä ajattelen sen rakenteena ongelma → seuraukset → ratkaisu. Alkuperäisen mallin keskimmäinen A tulee sanasta agitate, mutta käytännössä puhun mieluummin ongelman seurauksista. Agitate ei tarkoita pelottelua tai tavallisen vaivan paisuttelua katastrofiksi. Sen tehtävä on näyttää, mitä tunnistettu ongelma käytännössä aiheuttaa.
Kuulin PAS-rakenteen kerran Samu Haberin laulussa ennen kuin ajattelin sitä copywritingina. Kertoja tuntee kaikkien tuijottavan ja olevansa kuin väärissä juhlissa väärän juoman kanssa. Nolo olo muuttuu ahdistukseksi. Vasta sen jälkeen laulu tarjoaa tarkoituksella hieman omituisen ratkaisun: syödään sieniä. Siinä PAS näkyy selvästi: ensin ongelma, sitten sen seuraukset ja vasta lopuksi ratkaisu. Markkinointiteksti ei silti saa keksiä lisää hätää tai paisutella seurauksia vain tehdäkseen ratkaisusta tärkeämmän.
Esimerkkituotteen todellinen ongelma ei ole ”tehoton yhteistyö”. Päätös voi löytyä jostain, mutta sen perustelu ei ole tehtävän yhteydessä. Kun joku palaa tehtävään myöhemmin, hän näkee lopputuloksen mutta joutuu etsimään taustaa kokousmuistioista, sähköpostista ja keskustelukanavista. Jos perustelua ei löydy, sama keskustelu joudutaan ehkä käymään uudelleen. Siinä on riittävästi kitkaa ilman kuvitteellisia menetettyjä tuhansia euroja tai väistämättä myöhästyviä projekteja.
Ratkaisusta ei pidä luvata enempää kuin mitä se tekee. Päätösloki tuo päätöksen perustelun tehtävän yhteyteen. Se ei tee päätöksistä hyviä, poista erimielisyyksiä tai korjaa projektin johtamista.
Siksi tuote tulee PAS-versiossa mukaan vasta lopussa:
Ongelma
Kuukauden päästä kukaan ei enää muista, miksi ratkaisu valittiin.
Seuraukset
Päätös on kyllä tehty, mutta perustelut ovat jääneet kokousmuistioihin, sähköpostiin tai keskustelukanaviin. Kun joku palaa asiaan myöhemmin, hän joutuu etsimään perustelut itse — tai samat asiat käydään porukalla uudelleen läpi.
Ratkaisu
Päätösloki tallentaa päätöksen ja sen perustelut suoraan projektin tehtävän yhteyteen. Kun asiaan palataan myöhemmin, näkyvissä on sekä se, mitä päätettiin, että miksi.
Toiminta
Varaa 20 minuutin esittely, niin näet, miten se toimii käytännössä.
PAS:ssa ongelmaa ei tarvitse paisutella. Riittää, että näyttää, mitä siitä oikeasti seuraa. Jos seurauksia ei tiedetä, niitä ei pidä antaa tekoälyn keksiä.
Kopioitava PAS-prompti
Kirjoita lähdemateriaalista käyttövalmista tekstiä PAS-rakenteella.
Kirjoitustehtävä:
- Tekstilaji ja paikka: [esim. palvelusivu, myyntisähköposti, ominaisuuden esittely]
- Ensisijainen lukija: [kenelle teksti on tarkoitettu]
- Toivottu seuraava askel: [yksi konkreettinen toiminto]
- Toivottu pituus ja muoto: [määritä]
- Sävy tai tyylirajoitteet: [kuvaa lyhyesti]
Lähdemateriaali:
[liitä tähän asiakashaastattelut, tukipyynnöt, tutkimusmuistiinpanot tai tuotetiedot]
Työskentele tässä järjestyksessä:
1. Poimi aineistosta vain asiat, joille löytyy tuki:
- Problem: todellinen, lähteistä tunnistettava ongelma
- Agitate: ongelman konkreettiset seuraukset, ongelman aiheuttama työ tai epävarmuus
- Solution: ratkaisu ja se osa ongelmasta, johon ratkaisu vastaa
2. Merkitse jokainen suunniteltu väite joko faktaksi, aineiston tukemaksi tulkinnaksi tai puuttuvaksi tiedoksi.
3. Jos ongelmaa, seurausta, kohderyhmää tai sitä, miten ratkaisu vastaa ongelmaan, ei voi osoittaa aineistosta, kysy ensin enintään viisi täsmällistä kysymystä. Älä luonnostele ennen vastauksia.
4. Kirjoita sitten käyttövalmis teksti. Älä selitä tai merkitse PAS-vaiheita lopulliseen tekstiin.
Agitate ei tarkoita pelottelua. Älä liioittele haittaa, keksi uusia seurauksia tai esitä mahdollista seurausta varmana. Älä keksi ominaisuuksia, asiakasongelmia, todisteita, numeroita, tuloksia, suosituksia, kiirettä tai niukkuutta. Kerro ratkaisusta vain se, minkä lähdemateriaali tukee.
Liitä loppuun lyhyt lähdetarkistus: ongelman ja seurausten lähteet sekä väitteet, joille tarvitaan lisää näyttöä.FAB: ominaisuudesta asiakkaan hyödyksi
Päätösloki tallentaa päätöksen, perustelun, tekijän ja päivämäärän projektin tehtävään. Täsmällistä tietoa, mutta asiakkaalle se ei vielä kerro, miksi ominaisuudesta olisi hänelle hyötyä.
Kun päätös ja perustelu ovat tehtävän yhteydessä, niitä ei tarvitse etsiä erillisistä muistioista ja keskusteluista. Tehtävään myöhemmin palaava ihminen näkee samasta paikasta, mitä päätettiin ja miksi.
FAB tulee sanoista Feature, Advantage ja Benefit. Käytännössä ajattelen rakennetta suomeksi näin: ominaisuus → vaikutus → hyöty. Vaikutus kertoo, mitä ominaisuus muuttaa, ja hyöty, miksi muutos on asiakkaalle tärkeä.
Kun opin erottamaan FAB:n vaiheet, aloin huomata saman lähes jokaisessa tuote-esittelyssä: ominaisuus kerrotaan kyllä, mutta usein jää selittämättä, mitä se muuttaa asiakkaan työssä ja miksi muutoksesta olisi hänelle hyötyä.
Ominaisuus
Päätösloki tallentaa päätöksen, perustelun, tekijän ja päivämäärän projektin tehtävän yhteyteen.
Vaikutus
Päätöksen perustelu löytyy samasta paikasta kuin tehtävä, eikä sitä tarvitse etsiä kokousmuistioista, sähköpostista tai keskustelukanavista.
Hyöty
Kun joku palaa tehtävään myöhemmin, hän näkee heti, mitä päätettiin ja miksi.
Ominaisuus kertoo, mitä tuotteessa on tai mitä se tekee. Sen pitää olla todennettava, ei arvio kuten ”älykäs”, ”tehokas” tai ”helppo”. Vaikutus kertoo, mitä ominaisuus mahdollistaa tai miten se muuttaa nykyistä tapaa toimia. ”Keskitetty päätösloki” ei vielä kerro vaikutusta; ”päätöksen perustelu löytyy tehtävän yhteydestä” kertoo.
Hyöty kertoo, mitä ominaisuuden tuoma muutos merkitsee lukijan omassa työssä. Sen ei tarvitse olla suuri. Uskottava pieni hyöty on arvokkaampi kuin tuloslupaus, jonka tueksi ei ole näyttöä. Neljästä tietokentästä ei voi hypätä suoraan parempaan yhteistyöhön, kasvuun tai mitattuun ajansäästöön.
Tuotekeskusteluissa ominaisuudesta siirrytään helposti suoraan hyötyyn perustelematta, mitä ominaisuus käytännössä muuttaa. Ominaisuus on tekijöille niin tuttu, että sen merkitys tuntuu itsestään selvältä. Asiakkaalle sama yhteys ei välttämättä aukea. FAB toimii silloin tarkistuksena: ymmärtääkö ulkopuolinen, mitä hyötyä ominaisuudesta on hänen työssään?
Valmiissa tuotekstissä FAB-otsikoita ei tarvita:
Päätös ja sen perustelu kuuluvat samaan paikkaan kuin työ. Päätösloki tallentaa päätöksen, perustelun, tekijän ja päivämäärän suoraan projektin tehtävään. Kun tehtävään palataan myöhemmin, päätöksen tausta on näkyvissä ilman että tietoa tarvitsee etsiä kokousmuistioista, sähköpostista ja keskustelukanavista.
FAB auttaa tarkistamaan, mitä ominaisuus käytännössä muuttaa asiakkaan kannalta. Jos hyötyä ei pysty selittämään näin yksinkertaisesti, ongelma ei välttämättä ole tekstissä vaan siinä, ettei hyötyä ole vielä selvitetty tarpeeksi hyvin.
Kopioitava FAB-prompti
Kirjoita tuote-, palvelu- tai ominaisuusmateriaalista asiakkaalle ymmärrettävää tekstiä FAB-rakenteella.
Kirjoitustehtävä:
- Tekstilaji ja paikka: [määritä]
- Ensisijainen käyttäjä tai ostaja: [kenelle teksti on tarkoitettu]
- Tilanne, jossa hän käyttää tuotetta tai palvelua: [kuvaa, jos tiedossa]
- Toivottu seuraava askel: [jos tekstissä tarvitaan CTA]
- Toivottu pituus ja muoto: [määritä]
- Sävy tai tyylirajoitteet: [kuvaa lyhyesti]
Lähdemateriaali:
[liitä ominaisuuslista, määrittely, palvelukuvaus, haastattelut ja todisteet]
Työskentele tässä järjestyksessä:
1. Palauta ensin lyhyt taulukko, jossa jokaisesta olennaisesta ominaisuudesta erotellaan:
- Feature: todennettava ominaisuus, toiminto tai työvaihe
- Advantage: vaikutus eli mitä ominaisuus mahdollistaa tai muuttaa
- Benefit: miksi tästä on hyötyä juuri tälle käyttäjälle tai ostajalle
2. Merkitse, jos vaikutusta tai hyötyä ei voi perustella aineiston perusteella.
3. Jos käyttötilanne, kohderyhmä, nykyinen tapa tai olennainen hyöty puuttuu, kysy ensin enintään viisi täsmällistä kysymystä. Älä luonnostele ennen vastauksia.
4. Kirjoita sitten käyttövalmis teksti. Varmista, että vaikutus perustuu ominaisuuteen ja hyöty siihen, mitä ominaisuus käytännössä muuttaa. Älä näytä FAB-termejä lopullisessa tekstissä.
Älä keksi ominaisuuksia, asiakasongelmia, todisteita, numeroita, tuloksia, suosituksia, kiirettä tai niukkuutta. Älä esitä oletettua hyötyä todennettuna tuloksena. Käytä teknisiä termejä vain, jos kohderyhmä tarvitsee niitä.
Listaa luonnoksen lopuksi jokainen olennainen väite. Kerro, mihin aineiston kohtaan se perustuu ja onko kyseessä fakta, aineiston tukema tulkinta vai vielä varmistettava tieto.Sama aineisto, kolme eri tehtävää
AIDA aloittaa kysymyksellä, jonka lukija tunnistaa omakseen. Tuote tulee mukaan jo toisessa kappaleessa, koska tekstin pitää ensin herättää kiinnostus ja sitten antaa syy varata esittely. AIDA auttaa siis vastaamaan kysymykseen: miksi lukisin tämän loppuun ja mitä teen sen jälkeen?
PAS aloittaa ongelmasta eikä kiirehdi tuotteeseen. Keskimmäinen kappale näyttää, mitä hajallaan oleva tieto käytännössä aiheuttaa: etsimistä, puuttuvaa taustaa ja samoihin asioihin palaamista. Päätösloki tulee mukaan vasta, kun on selvää, mihin ongelmaan se vastaa. PAS auttaa kysymään: tunnistanko tämän ongelman ja tuntuuko ratkaisu siihen järkevältä?
FAB lähtee toisesta suunnasta. Lähtökohtana on ominaisuus: päätösloki tallentaa neljä tietoa projektin tehtävän yhteyteen. Ensin katsotaan, mitä ominaisuus muuttaa käytännössä, ja vasta sen jälkeen, miksi muutos olisi käyttäjälle hyödyllinen. Kysymys on yksinkertainen: miksi tällä ominaisuudella pitäisi olla minulle mitään väliä?
Samat faktat, mutta kolme eri tapaa järjestää ne. Siksi ”kirjoita tästä myyvä teksti” on tekoälylle kehno toimeksianto. Ensin pitää päättää, pitääkö lukijan kiinnostus herättää ja ohjata hänet seuraavaan askeleeseen, näyttää tutun ongelman todelliset seuraukset vai selittää, miksi tuotteen ominaisuudella on asiakkaalle väliä.
Prompti ei saa keksiä puuttuvia faktoja
Jokainen näistä rakenteista vaatii tiettyjä lähtötietoja. Jos niitä ei ole, tekoäly alkaa helposti täydentää puuttuvaa itse. AIDA tarvitsee uskottavan hyödyn tai muutoksen, PAS todellisen ongelman ja FAB tiedon siitä, mitä ominaisuus käytännössä muuttaa ja mitä hyötyä muutoksesta on. Jos jokin näistä puuttuu aineistosta, tekoäly saattaa täydentää puuttuvan tiedon uskottavalta kuulostavalla arvauksella.
Malli ei saa keksiä:
- ominaisuuksia
- asiakkaan ongelmia
- todisteita
- numeroita
- tuloksia
- suosituksia tai asiakaslainauksia
- kiirettä tai niukkuutta
Jos jotain näistä puuttuu, mallin pitää kysyä siitä. On parempi pyytää puuttuva tieto kuin täyttää aukko arvauksella.
Kun luonnos jää latteaksi, ensimmäinen reaktio on helposti pyytää siitä terävämpi, rohkeampi tai myyvempi. Kokeilen mieluummin kysyä, mitä lähtötiedoista puuttuu. Usein latteus johtuu siitä, että lähtötiedoista puuttuu jotain olennaista. Silloin tekoäly joko arvaa tai kiertää asian ympärillä yleisillä ilmaisuilla.