Loading...

Kuinka rakentaa myyvä demo?

Home / Digitalisaatio / Kuinka rakentaa myyvä demo?

Kun ollaan hankkimassa uutta järjestelmää asiakkaiden palvelemiseen tai sisäiseen käyttöön, on käytettävyys yksi merkittävä punnittava ominaisuus. Demo eli järjestelmän esittely livenä tai verkkopalaverissa on hyvä tapa saada käsitys järjestelmän käytettävyydestä. Olen nähnyt muutaman viime kuukauden aikana joukon demoja liittyen Pajun omien järjestelmätarpeiden täyttämiseen sekä asiakkaiden kilpailutusprosesseihin liittyen. Tässä blogissa käyn läpi muutamia aiheita, jotka tulevat esiin hyvässä demossa.

Lisäarvoa tuova yritysesittely

Jos demolle on varattu aikaa 30-60 min, ei yritysesittely saa kestää yli 5 minuuttia. Perustiedot kannattaa käydä läpi: asiakasta kiinnostaa lähtökohtaisesti toimitusvarmuus sekä palvelutaso erilaisissa tilanteissa. Lisäksi asiakasta usein kiinnostaa, ovatko samat asiantuntijat tekemässä projektia ja hoitamassa tukipalvelua, vai tapahtuuko yrityksen sisällä sisäistä tiedonsiirtoa.

Jos tämä esittelyaika eri riitä, asiakkaalle voi lähettää jälkikäteen yrityksen historiikin tai muuta lisätietoa, jos tuntuu, että se on se asia, mikä vakuuttaa asiakkaan.

Olemme teknologian x platinapartneri

Wau, mutta mitä sitten?

Mitä kumppannus tarkoittaa asiakkaan näkökulmasta? Tarkoittaako se, että teidän kauttanne asiakas saa tukiticketit ratkaistua nopeammin? Tarkoittaa se, että yrityksen henkilökunta on niin hyvin koulutettua, että heiltä työ onnistuu tehokkaammin ja laadukkaammin kuin pronssi- tai hopeapartnereilta? Saatteko nopeammin käyttöön uusia versioita? Mitä sertifikaatit ja tunnustukset käytännössä tarkoittavat, what’s in it for me?

Peruskäyttötapausten esittely

Jos järjestelmän yleistä logiikkaa ei pysty esittelemään muutamassa minuutissa, on järjestelmän käytettävyys mahdollisesti kotoisin 1990-luvulta. B2B-käyttäjät ovat tottuneet intuitiivisiin ja käyttäjäystävällisiin sovelluksiin kuluttajamaailmassa (verkkokaupat, mobiilisovellukset yms.), ja samaa tasoa odotetaan yritysten operatiivisilta järjestelmiltä. Tämä on monille pitkään toimineille IT-toimijoille haaste: kymmeniä vuosia vanhalle pohjalle on kallista ja työlästä rakentaa nykyaikaista sovellusta.

Asiakkaan käyttötapausten esittely

Jos asiakas on pyytänyt erityisesti tiettyjen käyttötapausten demoamista, keskitytään yhteisen ajan aikana niihin. Joskus asiakkaan käyttötapausten toteuttaminen voi vaatia lisätyötä. Kukin yritys miettii itse, mikä on sopiva työmäärä räätälöidyn demon toteuttamiseen. Jos työmäärä on todella tuntuva, on mielestäni perusteltua kertoa asiakkaalle, että käyttötapaus x kyllä onnistuu, mutta se voidaan tehdä projektin aikana räätälöitynä ja sen työmäärä on n htp ja kustannus y eur.

Ööö, tämä ei tällä käyttäjällä näköjään toimikaan…

Eri käyttäjäroolien näkymien sujuva esittely

Useimmissa järjestelmissä käyttö on erilaista riippuen käyttäjäroolista ja sen oikeuksista. Henkilöstöhallinnon skenaarioissa työntekijät tekevät pyyntöjä ja ilmoituksia, jotka esimies käsittelee omassa näkymässään. Eri roolien näkymien ja toiminnallisuuksien esittämiseen kannattaa käyttää erityistä huolellisuutta. Selkeät käyttäjänimet (Tero Työntekijä, Ella Esimies) auttavat demon katsojaa pysymään kärryillä.

Raporttien demoaminen

Järjestelmiin kerääntyy aina paljon erilaista tietoa, ja toiveena tietysti on, että sitä pääsee katsomaan raporttien kautta eri näkökulmista. Hyvässä demossa on riittävästi testidataa, että raportointitoiminnallisuudet tulevat esiteltyä kattavasti ja havainnollisesti. ”Tässä olisi hieno raportti, mutta kun täällä ei ole mitään tietoa, niin eihän tämä näytä mitään.” Ei vakuuta.

Demo asiakkaan käyttöön

Jos myyjä tarjoaa demoympäristön asiakkaan tutustuttavaksi, on todella tärkeää saada sinne järkevää testidataa pohjalle. Tutustuin itse erään taloushallinnon järjestelmään, joka tarjosi geneerisen demoympäristön, joka käytännössä oli täysin käyttökelvoton. Kaikki tuotteet, henkilöt ja muut avaintiedot oli perustettu järjestelmään kaltaisteni demoilijoiden toimesta, ja lähes jokainen toiminto aiheutti virheilmoituksen.

Myyjä, kun teet demoa, muista nämä:

  • Jos myynnistä vastaava henkilö ei tunne järjestelmää riittävän hyvin, ota demoon mukaan tuotepäällikkö, projektipäällikkö tai kehittäjä.
  • Hyvä skripti eli käsikirjoitus: sopikaa demoavan tiimin kanssa, kuka hoitaa minkäkin osuuden ja mitä sen aikana tapahtuu. Hyvä skripti on erittäin yksityiskohtainen: käyttäjä Tero Työntekijä tekee vuosiloma-anomuksen ajalle 1.-9.10. (Teron tunnuksilla), Ella Esimies käsittelee anomuksen (Ellan tunnuksilla), talousjohtaja Teresa Tirkkonen tarkastelee koko organisaation vuosilomaraporttia pidetyt ja pitämättömät lomat (Teresan tunnuksilla).
  • Suunnittele ajankäyttö niin, että kysymyksille jää aikaa.
  • Kuuntele asiakasta, vastaa hänen kysymyksiinsä. On tärkeämpää rakentaa luottamusta kuuntelemalla ja keskustelemalla kuin paahtamalla demossa eteenpäin. Tarvittaessa voitte varata uuden yhteisen ajan.
  • Jos demo pohjautuu vahvasti asiakkaan vaatimuksiin, nosta rohkeasti teidän yrityksenne ehdotuksia siitä, miten asiat nyt tai tulevaisuudessa olisi järkevää hoitaa tarjoamallanne järjestelmällä.
  • Varmista, että ympäristössä on riittävästi laadukasta testidataa.
  • Jos ympäristön visuaalinen tuunaaminen on mahdollista, asiakkaan logon ja värien lisääminen ympäristöön tekee myönteisen vaikutelman.
  • Kirjaa demossa esiin tulleet avoimet kysymykset ja palaa niihin mahdollisimman pian vastausten kanssa.
  • Jos tarjoat asiakkaalle testiympäristön hänen omaan käyttöönsä, varmista että testidata ja peruskäyttötapaukset ovat kunnossa. Soita asiakkaalle perään, ja kysy miten demoaminen on onnistunut.
  • Ota demoaminen huomioon jo järjestelmän suunnitteluvaiheessa – demoaminen tulee 100% varmasti vastaan myyntivaiheessa. Hyvä demoympäristö syntyy harvoin ilmaisena sivutuotteena, sen rakentamiseen täytyy varata resursseja.

Tyhmiä kysymyksiä ei ole.

Ostaja, kun seuraat demoa, muista nämä:

  • Jos etsit ratkaisua tiettyyn tarkoitukseen, ohjeista myyjä kunnolla. Näin kummankin aika tulee käytettyä hyvin.
  • Tyhmiä kysymyksiä ei ole. On enemmän kuin todennäköistä, että sinä ja myyjä puhutte vähän erilaista kieltä. Varmista lisäkysymysten, esimerkkien ja käyttötapausten kautta, mitä myyjä tarkoittaa.
  • Kaikkea ei ole mahdollista demota, varsinkin jos järjestelmään tarvitaan räätälöintiä. Selvitä räätälöinnin työmäärä-, kustannus- ja muut vaikutukset keskustelussa tai jälkikäteen toimitettavasta materiaalista.
  • Kysy toimittajan kokemuksia hyvästä projektin läpiviennistä ja toimivasta ylläpitomallista.

Tämä blogikirjoitus pohjautuu LinkedInissä käytyyn keskusteluun, kiitos Vesa Nopanen, Teemu Uusitalo, Matti Vepsäläinen, Martti Kouhi, Mika Jordanov ja Kristiina Banda.

Miksi kirjoitin tämän blogin? Paju auttaa ostajia ostamaan ja teknologiayrityksiä myymään paremmin ja toimimaan tehokkaammin. Kun kaikki onnistuvat, mekin olemme onnistuneet.

Jenni Rissanen
puh. 0400-910300
Varaa aika skype-tapaamiseen