Tavoite: määritellä minimidata, joka kertoo asiakkaan valinnan syyt (voitto, häviö, ei päätöstä) niin, että tieto on myöhemmin analysoitavissa ja sillä voidaan mitata kehityskokeilujen vaikutusta. Kaikki kirjaaminen, joka ei palvele tätä tavoitetta, on todennäköisesti turhaa.
1) Mitä “päätösnäyttö” Tarkoittaa CRM:ssä?
Päätösnäyttö = asiakkaan ostopäätöksen lopputulos + perustelut niin kuin asiakas ne ilmaisi, kirjattuna rakenteisesti ja toistettavasti.
- Ei ole sama asia kuin myyjän näkemys (“hinta oli este”), vaan asiakkaan vahvistama syy (“valitsimme halvimman, koska budjetti lukittiin”).
- Päätösnäyttöä tarvitaan, jotta:
- tunnistat toistuvat ostokriteerit ja niiden painot,
- erotat kilpailukyvyn ongelmat myyntiprosessin ongelmista,
- pystyt arvioimaan, muuttuiko jokin 30 päivän kokeilun seurauksena.
2) Minimikirjaamisen periaatteet
Pidä kiinni kolmesta periaatteesta:
Kirjaa vain se, mitä käytetään päätöksiin
Jos tietoa ei käytetä analyysissä, katselmuksessa tai kokeilun mittaamisessa, se kannattaa kyseenalaistaa.Rakenne + lyhyt tarina
Pelkkä vapaateksti ei skaalaudu. Pelkkä valikko taas menettää nyanssit. Tarvitset molemmat:- valittavat kentät (vertailtavuus)
- lyhyt perustelumuistiinpano (konteksti)
Tiedon lähde näkyväksi
Merkitse, onko syy:- asiakkaan kertoma (vahva näyttö)
- todennettu epäsuorasti (esim. sähköposti, tarjousvertailu)
- myyjän arvio (heikko näyttö)
3) Minimidata: Mitä kirjataan joka casesta?
Alla on suositeltu minimikenttäsetti. Ajattele tätä “päätösnäytön ydinlomakkeena”.
A. Päätöksen lopputulos (pakollinen)
Kirjaa jokaiselle myyntimahdollisuudelle selkeä loppu:
- Voitto (asiakas valitsi meidät)
- Häviö (asiakas valitsi muun ratkaisun / kilpailijan)
- Ei päätöstä (asiakas keskeytti / siirsi / jäi roikkumaan)
Miksi: Ilman lopputulosta et voi laskea konversioita, etkä eritellä syitä eri lopputuloksissa.
B. Päätöspäivä ja päätösvaihe (pakollinen)
- Päätöspäivä (tai arvioitu, jos tarkkaa ei saada)
- Vaihe, jossa päätös tapahtui (esim. “tarjous”, “pilotti”, “hankintaneuvottelu”)
Miksi: Tarvitset ajallisen ankkuroidun tiedon ennusteisiin, syklianalyyseihin ja siihen, missä kohtaa prosessi yleensä katkeaa.
C. Päätöksentekorooli ja kanava (pakollinen, Kevyt)
- Kuka vahvisti syyn? (rooli riittää: esim. liiketoimintajohto / IT / hankinta / loppukäyttäjä)
- Miten tieto saatiin? (puhelu / sähköposti / tapaaminen / kilpailutusmateriaali)
Miksi: Syyt vaihtelevat rooleittain. Lisäksi tiedon luotettavuus kasvaa, kun lähde näkyy.
D. Ostokriteerit ja niiden paino (pakollinen)
Valitse 3–5 ostokriteeriä valmiista listasta ja merkitse niiden paino:
- Kriteeri 1–5: valinta listasta
- Paino: ratkaiseva / tärkeä / sivuroolissa
Miksi: Kun kriteerit on kirjattu samalla tavalla kaikille caseille, voit nähdä mikä oikeasti ohjaa valintaa (ei vain yksittäiset tarinat).
Esimerkki kriteerilistasta (räätälöi toimialaan):
- Hinta / kokonaiskustannus
- Toiminnallisuus / soveltuvuus
- Integraatiot / tekninen yhteensopivuus
- Käyttöönoton nopeus / resursointi
- Toimitusvarmuus / kyvykkyys
- Referenssit / luottamus / riski
- Tietoturva / compliance
- Palvelumalli / tuki
- Sopimusehdot / hankintaprosessi
- Strateginen sopivuus / suunta
E. Valinnan syy (pakollinen)
Kirjaa yksi ensisijainen syy + tarvittaessa 1–2 toissijaista:
- Ensisijainen valinnan syy: valinta listasta
- Lyhyt asiakkaan sanoin -tekstikenttä (1–3 lausetta)
Miksi: Ostokriteeri kertoo “mitä arvioitiin”. Valinnan syy kertoo “miksi lopulta valittiin näin”.
Tyypillisiä syykategorioita:
- Me voitimme, koska: parempi kokonaisratkaisu / nopeampi käyttöönotto / pienempi riski / parempi yhteensopivuus / luotettavuus / hinnoittelu sopi / vahva referenssi
- Me hävisimme, koska: hinta / puuttuva ominaisuus / kilpailijan vahvempi referenssi / päätöksentekijä preferoi toista / tietoturvavaatimus / hankinnan prosessi
- Ei päätöstä, koska: budjetti jäädytettiin / prioriteetti muuttui / sisäinen omistaja puuttui / päätös siirtyi / kilpailutus keskeytettiin
F. Kilpailutilanne (kevyt mutta tärkeä)
- Oliko kilpailija? (kyllä/ei)
- Jos kyllä: kilpailija (valintalistasta tai vapaa kenttä)
- Kilpailun tyyppi: “nykyinen toimittaja”, “uusi vaihtoehto”, “ei kilpailutusta”
Miksi: Ilman kilpailutilannetta et pysty erottamaan, hävisitkö “todelliseen” kilpailuun vai esimerkiksi nykytoimittajan inertiaan.
G. Kaupalliset perustiedot mittaamista varten (pakollinen)
- Deal-arvo (tai luokka: pieni/keskisuuri/suuri)
- Tuote-/palvelulinja (valinta)
- Segmentti (valinta: esim. SMB/mid/enterprise tai toimialat)
Miksi: Kokeiluja mitataan usein segmenteittäin tai tarjoomittain. Muuten tulokset sekoittuvat.
H. Päätösnäytön vahvuus (pakollinen, 3 Tasoa)
Merkitse luotettavuus:
- Vahvistettu asiakkaalta suoraan
- Epäsuorasti todennettu (dokumentti, tarjousvertailu, usea lähde)
- Myyjän arvio (ei varmistusta)
Miksi: Kun analysoit, voit painottaa vahvaa näyttöä ja tunnistaa kohdat, joissa tiedonkeruu pitää parantaa.
4) Mitä EI kannata pakottaa CRM:ään (ainakaan alussa)
Jos tavoite on päätösnäyttö, vältä näitä yleisiä “raportoinnin ansakuoppia”:
- Liian tarkka aktiviteettiloki (jokainen sähköposti) ilman käyttötapaa analyysissä
- Pitkät pakolliset kenttälistat “varmuuden vuoksi”
- Yksityiskohtaiset kilpailijavertailut joka casesta (tee vain, jos oikeasti käytät)
- Subjektiiviset arviot ilman lähdemerkintää (“asiakas tykkäsi meistä”) päätösnäytön korvikkeena
Pidä prosessi kevyenä: tarkoitus on saada kattava ja vertailukelpoinen päätösnäyttö, ei täydellinen myyntipäiväkirja.
5) Käytännön esimerkki: Miltä hyvä päätösnäyttö näyttää?
Case: Häviö, B2B SaaS
- Lopputulos: Häviö
- Päätöspäivä: 2026-09-18
- Päätösvaihe: Tarjousvertailu
- Syyn vahvisti: Hankintapäällikkö (puhelussa)
- Ostokriteerit (paino):
- Tietoturva (ratkaiseva)
- Integraatiot (tärkeä)
- Hinta (tärkeä)
- Ensisijainen valinnan syy: Tietoturvavaatimus ei täyttynyt
- Asiakkaan sanoin: “Emme voi edetä, koska vaadittu sertifiointi puuttuu ja auditointi on pakollinen tänä vuonna.”
- Kilpailija: Nykytoimittaja
- Deal-arvo: 48 000 €/vuosi
- Segmentti: Enterprise
- Tuotelinja: Core
Tästä syntyy suoraan analysoitava signaali: Enterprise-kaupoissa tietoturva on ratkaiseva, ja sertifiointi on konkreettinen kehityskohde.
6) Soveltava kysymys (pohdinta omaan työhön)
Jos saisit kirjata CRM:ään vain 5 kenttää jokaisesta casesta, mitkä valitsisit, jotta pystyisit 30 päivän päästä vastaamaan kahteen kysymykseen:
- Miksi voitamme ja häviämme?
- Muuttiko kokeilu asiakkaan valinnan perusteluja?