Julkaistu

Eräs tarina Salesforcen käyttöönotosta

Syksyllä 2019 olin mukana projektissa, jossa otimme yrityksessämme käyttöön Salesforcen. Toteutin itse teknisen operaation: sain/otin tehtäväkseni siirtää tiedot vanhasta järjestelmästä uuteen. Suoraan sanoen tämä oli työurani ehkä suurin haaste, mutta se meni lopulta ihan hyvin. Salesforce on sen jälkeen ollut vahvasti data-ohjautuvan yrityksemme prosessien keskipisteessä. Kerron tässä, millaisia teknisiä ratkaisuja teimme käyttöönoton ja integraatioiden osalta.

Näin sen teimme

Meillä oli kaikilla yhteinen tahto aloittaa uudessa järjestelmässä mahdollisimman puhtaalla datalla. Datan siivousoperaatiosta tuli lopulta aika työllistävä, mukana oli monta osapuolta. Onneksi projektissa oli virallinen projektipäällikkö, joka piti lankoja käsissä; minä vastasin lähinnä teknisestä siirto-operaatiosta. Samalla, kun dataa siivoiltiin, harjoittelin kymmenillä toistoilla siirtoa Salesforcen testiympäristöön. Siirtopäivänä prosessin kulku oli selvä ja tosi hyvin harjoiteltu. Siinä kävi sitten niin, että kaikki tiedot meni tuotantoympäristössä saman tien paikoilleen! Projekti valmistui siis täsmälleen sinä päivänä kuin pitikin. Oli juhlallista kulkea käytävillä käyttöönottoa seuraavana päivänä ja katsoa, kun myyjät jatkoivat töitään ja toimintojaan uudessa ympäristössään täsmälleen siitä kohdasta, kuin mihin olivat ne jättäneet vanhassa järjestelmässä. En koskaan unohda viskipulloa, jonka löysin pöydältäni sitä seuraavana päivänä 🙂

  • Vanhasta järjestelmästä oli tehty vuorokausittain päivittyvä integraatio Google BigQueryyn. Päätin käyttää sitä migraatiodatan lähteenä. Koska tiesin, missä muodossa Salesforcessa kaipasi datan, aloin heti projektin alussa muotoilemaan dataa SQL-näkymissä oikeaan muotoon.
  • Koska Salesforce on tosiaan hyvin ranttu datan laadun osalta, ainakin valitsemillamme asetuksilla, oli tärkeää päästä jo aikaisessa vaiheessa testaamaan siirtoja; tuli toistuvasti virheilmoituksia, jotka johtivat yhä uusiin datanpuhdistukierroksiin. Ellei tätä vaihetta olisi aloitettu ajoissa, olisi ollut käytännössä mahdotonta pysyä sovitussa aikataulussa; datan puhdistus vaati monen osapuolen osallistumista, ja sellaiseen liittyy aina viiveitä.
  • Meillä oli Salesforce- ja migraatio-osaamista talon sisällä. Tämä mahdollisti todennäköisesti paljon sujuvamman operaation, kuin mitä se olisi ollut ulkopuolisen konsultin ohjauksessa.

Kun saimme Salesforcen käyttöön, olimme innoissamme: miten hieno systeemi ja upea datarakenne! Mikään ei näytä estävän meitä tekemästä täsmälleen haluamaamme dataratkaisua.

Mitä siis halusimme? Sujuvia integrointeja muihin bisnesjärjestelmiimme tietenkin, ja mahdollisimman helposti ja edullisesti 🙂 Totesimme, että Salesforcessa on kattava API eli ohjelmistorajapinta, teimme tärkeän strategisen päätöksen: vältämme Salesforcen tarjoamia APEX-pohjaisia integrointiratkaisuja ja suuntaamme Python-pohjaisiin Rest API-ratkaisuihin. Päätöstämme tuki se, että meillä oli jo Google Cloud Platform monipuolisesti hallinnassa.

Miksei APEX kelvannut? 

APEX on sinänsä hieno Salesforcen ohjelmointikieli todella monipuolisia integrointeja ja automaatioita varten, mutta se vaatii erikoisosaamista, jota joutuisimme ostamaan konsulttitalolta. Python&API-ratkaisut voimme tehdä vaikka ns. kesäteekkareiden kanssa, ellei omat kädet riitä. Muutenkin tuntuu, että se on teknologisesti enemmän nykyaikaan sopiva ratkaisu, nimenomaan kun puhutaan integraatioista.

Tilanne nyt

Muutaman vuoden kokemuksella voimme todeta, että tuo päätöksemme oli oikea. Mitä olemme kehittäneet Salesforcen ympärille?

  • Airflown (Googlessa: Cloud Composer) avulla tehty automaattinen tietojen ajastettu synkronointi Salesforcen ja muiden järjestelmien välillä. Rest API on onneksi vallitseva rajapinta moderneissa tuotteissa.
  • Koska meillä on Google BigQueryssä (Sanomme sitä “data lakeksi”) kaikkien yritysjärjestelmiemme data, voimme jalostaa niistä tietoa, jotka siirtyvät automaattisesti Salesforceen Rest APIn kautta. Näin voimme seurata Salesforcessa olevissa asiakkuuksissa olennaisia avaintietoja, kuten esim. laskutusta ja ja tehdä sen perusteella luokituksia.
  • Laukaisemme Salesforcen Outbound Message-toiminnan kautta erinäisiä tapahtumia Google Cloud Function-palveluiden kautta. Esimerkiksi uusista kaupoista tulee Slackkiin ilmoitukset koko yrityksen ihasteltavaksi; juhlinta-emojit kaupan koon mukaan!
  • SAAS-tuotteidemme kokeilut (“trialit”) tuottavat automaattisesti ns. liidit Salesforceen.
  • Irtisanomislomake on tehty Salesforcen päälle; mahdollistaa kätevästi suoran kytkennän asiakasdataan.
Julkaistu

Koodaaminen ja merkitys

Kun olin nuori, kaikenlainen hakkerointi ja koodaaminen oli itseisarvoisesti kiinnostavaa ja innostavaa.

Kuvassa olen kotonamme Taalainmaan Mockfjärdissä (Ruotsi) joskus vuonna 1987-1988. Kuvassa näkyy ensimmäinen PC:ni, jossa oli kymmenen kertaa enemmän RAM-muistia, kuin Commorodessa, ja huimat 20MB kiintolevy. Nurkassa näkyy radioamatööriasemanikin (tunnukseni oli SM4SWF). Kuvan otti veljeni…tutkin siinä kai jotain ohjelmointiopusta.

Opettelin uusia asioita puhtaasta innosta, ja hyvä niin: siinähän oppi kaikenlaista helpolla tavalla. Työurani alussa oppiminen jatkui iltaisin kotona, omalla ajalla. Nykyään energiani ei ole aivan nuoruuden tasolla. Huomaan myös iän myötä kaipaavani mahdollisimman merkityksellistä tekemistä, ja nykyään se tarkoittaa sitä, että teen työkseni ”työ-merkityksellisiä” asioita ja vapaa-ajalla minulla on muita merkityksellisiä asioita, kuten liikuntaa, lukemista, hapanjuurileivän leipoimista, kasvimaan hoitoa ja pianonsoittoa.

Mitä tulee töihin, olen erinäisten onnekkaiden sattumien johdosta päässyt työssäni tietynlaiselle näköalapaikalle, jossa ei merkityksellinen työ lopu. Olen koko työurani ollut IT-alan yritysmaailmassa ja oppinut paljon sen lainalaisuuksista. Tunnustan aluksi, että lähdin todella nollasta:

Ensimmäisessä työpaikassani en tullut aluksi ajatelleeksi, mistä rahat tulivat yritykseen. Oletin vain saavani sovitun palkan tekemieni työtuntien perusteella. Työtuntien raportointi oli vähän hankalaa, kun niitä piti kohdistaa eri projekteihin. Purnasin siitä kokeneemmalle työkaverilleni. Hän sitten sanoi minulle asian, joka hätkähdytti:
– Ellei tunteja raportoida näin, asiakkaamme eivät maksa yrityksellemme tehdystä työstä. Sinunkin palkkasi tulee meidän asiakkailtamme…ei se mistään muualta tule, joten raportoi ihan kiltisti ja mahdollisimman tarkasti.

Aika pian tajusin jo hymyillä tuolle typeryydelleni. Tosiaan, yrityksen tehtävä on tuottaa asiakkaille arvoa, josta ne sitten maksavat.

Nykyään tunnen erityisen syvää tyydytystä ja merkitystä siitä, kun pääsen käyttämään taitojani siihen, että asiakkaille tuotetaan arvoa:

  • Kun asiakas saa mahdollisimman hyvän tuotteen, hänen oma toimintansa paranee ja hän pysyy tyytyväisenä asiakkaana. Ja se johtaa siihen, että työpaikallani on varaa kehittää toimintaansa ja maksaa palkoja.
  • Tuotteet voidaan tehdä mahdollisimman laadukkaasti ja tehokkaasti; optimoidaan yrityksen toimintaa ja sitä kautta tuotettua arvoa
  • Kun yritystoiminta on tarpeeksi laadukasta, työntekijät eivät koe turhautuneisuutta.
  • Kun työntekijöillä on tarpeeksi hyvä näkyvyys yrityksen toimintaan, se tuottaa merkityksellisyyttä ja motivaatiota.

Mitä siis minä voin tehdä näiden asioiden eteen koodarin taidoillani? Vaikka mitä! Kun minuun luotetaan ja minulle annetaan mahdollisuuksia ja vapauksia ratkoa asioita, haluan tehdä sitä työtä mahdollisimman hyvin. Listaan tähän joitain esimerkkejä asioista, joita olen saanut olla ideoimassa ja kehittelemässä viimeisten vuosien aikana:

  • Yritysjärjestelmien yhdistäminen integroinneilla
  • Monenlaisten bisnesprosessien automaatioiden kehittäminen
  • Datan kerääminen, analysoiminen ja hyödyntäminen

Millä tavalla nämä tekniseltä kuulostavat asiat tuovat merkitystä minulle?

  • Kun tiedämme datan perusteella paremmin, mitä asiakkaat tarvitsevat, voimme tarjota heille laadukkaampaa palvelua
  • Kun prosessit toimivat automaattisesti, ne toimivat yleensä todella paljon nopeammin, kuin vastaavat manuaaliset prosessit. Lisäksi vähentyy inhimillisten virheiden määrä.
  • Kun meillä on mahdollisimman paljon jäsenneltyä tietoa eli dataa yritystoiminnastamme ja asiakkaistamme, johdossa voidaan tehdä oikeaan suuntaan vieviä päätöksiä. Ellei ole tarpeeksi dataa, joutuu tekemään päätöksiä tuntumalla, ja sellaiset päätökset eivät välttämättä mene oikein.

Eräs yksittäinen ratkaisu on tuottanut minulle erityisen paljon merkitystä, vaikka se oli sinänsä teknisesti aika simppeli projekti: Pari vuotta sitten teimme järjestelmän, joka lähettää myyjien kaupoista automaattisesti ilmoitukset eräälle yrityksemme Slack-kanavalle. Ilmoituksiin määriteltiin juhlinta-emojit kaupan koon mukaan. Miten siinä kävikään: ihmiset alkoivat reagoimaan ilmoituksiin ylistävin emojein ja kannustavin kommentein! Aivan upeaa on ollut seurata tämä asian inhimillisiä mittasuhteita: yrityksen muut työntekijät arvostavat myyjiä, ja myyjät tuntevat sen. Siiloutumista purkavaa tiimiyttämistä siis, eli ei mikään pikkujuttu! Lisäksi yrityksessä pysyy kaikille selvänä, mistä se raha palkkoihin tulee; motivoi toivottavasti omaan osuutensa satsaamiseen.

Julkaistu

Käyttöliittymä – käyttäjän kunnioittamista vai kyykyttämistä?

Vaimoani huvittaa, miten nopeasti turhaudun huonojen käyttöliittymien äärellä. Pahimmillaan tulee sellainen kapinamieli, etten suostu ymmärtämään, miten homman pitäisi toimia ja menee sukset ristiin koko universumin kanssa. Olen kai jotenkin malttamaton luonne.

Hyvät käyttöliittymät saavat minut taas helposti fiiliksiin: olipa kätevää, ei mennyt yhtään elämää hukkaan asian hoitamisen yhteydessä! Myös insinöörinä ja ohjelmistoammattilaisena huomaan saavani parhaan tyydytyksen työstäni, kun saan asiat rullaamaan sujuvasti. Prosessien automatisointi on ollut johtotähtenäni urani alkuajoista lähtien: nuorena koodarina Ericssonilla 90-luvulla turhautti, kun vikaraportointiprosessi toimi huonosti, ja tein osastollemme web-pohjaisen raportointilomakkeen. (Tämä tapahtui silloin, kun suurin osa ns. tavallisista ihmisisistä ei vielä tiennyt, mitä nettiselain tarkoittaa 🙂 )

2000-luvun alkupuolella päädyin ns. mobiilibisnekseen ja opin nettipalveluiden lisäksi mobiilipalveluiden tekemisen. Kun kehitin omaa yritysideaa tuli vastaan kiinnostavat haasteet: miten tehdä mahdollisimman käyttäjää kunnioittava palvelu silloisilla hyvinkin rajallisilla kännykän mahdollisuuksilla. Syntyi Movenium, jota pidetään vieläkin helppokäyttöisenä tuotteena.

Hyppäys tähän päivään. Visma on ostanut perustamani yrityksen muutama vuosi sitten. Alla on pari kuvaa Visma Entry-tuotteesta, selaimessa ja matkapuhelimessa. Kuvat on itse asiassa omasta työajanseurannastani viime viikolta. Käytän tätä tuotetta siis omassa työssäni päivittäin, ja koen joka kerta hienoista ylpeyttä, sillä tämä tuote on kehitetty Moveniumista, ja siinä on vieläkin juuri sama idea, kuin mistä homma lähti: viimeisen päälle sujuva käyttöliittymä kaikille käyttäjille. En toki ole itse enää tuotekehityksessä mukana, joten en ole varsinaisesti vastuussa näistä nykypäivän tuotoksista 🙂

Visma Entry selaimella
Visma Entry mobiilisovelluksena

Julkaistu

Moveniumin tarina jatkuu

Meidän markkinointitiimissä näytettiin uusinta Visma Movenium-mainosta, joka komeilee tänään mm. Iltalehden etusivulla:

Myönnän auliisti, että jossain vähän läikähti, kun näin tuon mainoksen. Jotain ylpeyttä kai, kaikesta siitä, mitä ja ketä tähän hommaan liittyi ja liittyy. Koodasin tuon tuotteen eka version kesällä 2005, ja nyt ollaan tässä pisteessä. Pitkä tarina on takana, ja kaikesta päätellen myös edessä.

Visma (Visma Software Oy) on tuonut koko tuon homman ympärille käsittämättömän paljon lisävoimaa ja rakennetta: tuote on kasvanut kaikilla osa-alueilla aivan uusiin mittasuhteisiin. Sanoisin joulukuussa 2016 tapahtunutta yrityskauppaa todella onnistuneeksi!

Moveniumin teknisestä alustasta on poikinut myös yleinen työajanseurantatuote: Visma Entry.

Täällä kerroin aiemmin työhistoriastani.

P.S. Tämä tuote elää myös Ruotsissa, tuotteen nimi on siellä Visma Construction Suite.

Julkaistu

Asiakaskokemus, data ja tosielämä, osa 2: asiakkaan tunnistaminen

Aloitin tämän sarjan tällä artikkelilla, jossa koitan kuvata tilannetta, jossa yritykset saattavat olla siinä vaiheessa, kun haluavat saada datansa hallintaan.

Unohdetaan hienot sanat ja korkealentoiset ajatukset tässä vaiheessa; yritysdatan järjestely on perustaltaan puhdasta maalaisjärkeä. Ensiksi meidän on saatava kuntoon se tärkein asia:

Meidän on tiedettävä asiakkaamme. Kaikilla sidosryhmillä tulee olla pääsy varmaan ja luotettavaan tietoon siitä, ketkä ovat juuri tällä hetkellä asiakkaitamme. Lisäksi on oltava yksiselitteinen paikka, mistä tieto löytyy.

Kaikki siitä eteenpäin rakennetaan tuolle pohjalle, joten tuon perustan on oltava mahdollisimman vankka; on tärkeää, että tieto eli data pysyy aina oikeana; sillä siihen tulee voida luottaa. Järjestelmällä ei ole väliä, data voi olla vaikka Google Sheetissä, kunhan siihen voi aina luottaa päätöksentekotilanteissa.

Aluksi tarvitsemme perustiedon, jonka varaan kaikki rakentuu: nykyasiakkaamme, eli ne, jotka ovat juuri nyt asiakkaitamme. Sitä varten tarvitsemme prosessit asiakkuuden alkuvaiheeseen ja loppuvaiheeseen.

Niin, ohimennen, ketkä ovat nykyasiakkaitamme? Laskuttaja tarjoaa siihen luonnollisesti listaa viimeksi laskutetuista asiakkaista. Mutta voimmeko olla varmoja, että kaikkia asiakkaita on laskutettu (ja oikein)? Voimme, jos voimme seurata tehtyjä kauppoja aukottomasti laskutukseen asti.

Mistä siis aloitetaan?

Yrityksillä on tyypillisesti eri ohjelmistot toiminnoissaan: myyjillä on oma järjestelmänsä ja laskutuksella omansa jne. Ei tehdä vielä tässä vaiheessa ongelmaa mahdollisista ohjelmistojen yhteensopivuusongelmista, vaan aloitetaan:

  • Varmistetaan viimeistään kaupanteon yhteydessä, ettei asiakashallinnasta löydy kyseistä yritystä tuplana. Jotku meistä pitävät kauniista sanoista, joten he puhuvat duplikaateista.
  • Määritellään asiakkuuden tila asiakashallinnassa yksiselitteisesti, eli tiedämme, ketkä ovat asiakkaita, ja ketkä eivät vielä…tai enää.
  • Huolehditaan siitä, että kaikki sidosryhmät näkevät asiakastiedot. Mikäli kaikilla ei ole pääsyä master-tietoon esimerkiksi puuttellisten käyttöoikeuksien vuoksi (joidenkin asiakashallintajärjestelmien käyttäjäkohtaiset maksut voivat tuntua kalliilta), voi löytyä käteviä tapoja ylläpitää reaaliaikaista asiakaslistaa automaattisesti jossain muualla.

Tuohon viimeksi mainittuun voisin tarjota kuuman ja halvimmillaan jopa ilmaisen vinkin: Tutustukaapa Zapieriin ja siihen, miten se yhdistyy järjestelmiin, kuten Google Sheet. Pääset vauhtiin ilman kovin suuria nörttäilytaitoja.

Tarvitsemme asiakashallintaan myös sen numeron, jolla asiakas tunnistetaan laskutusjärjestelmässä; asiakkuuden tunnistenumeron. Se tiedetään tosin yleensä vasta siinä vaiheessa, kun asiakasta on laskutettu ensimmäisen kerran. Tämän numeron avulla voimme jatkossa seurata kyseisen asiakkaan laskutuksen kehitystä. Laskutustietojen ei useinkaan tarvitse olla yhtä reaaliaikaisia, kuin monet muut tiedot: esim. käsipelillä hoidettava siirtotiedoston käsittely on oikein kelvollinen tapa yhdistää laskutustiedot asiakastietoihin.

Kas, kirjoitin jo kaksi artikkelia tästä aiheesta, enkä ole vielä päässyt käytäntöön. Toivottavasti tilanne paranee seuraavassa artikkelissa. Sanoinko jo, että olen käytännön mies? 🙂

Julkaistu

Asiakaskokemus, data ja tosielämä, osa 1: tosiasioiden tunnustaminen

Oletko haveillut täydellisestä näkymästä yrityksenne toimintaan? Dashboardista, josta näkee yhdellä silmäyksellä, missä asiakkuuksien kanssa mennään, miten asiakkaat käyttävät tuotteita, miten tyytyväisiä ovat, miten maksavat jne? Hyödyt toiminnan laatuun olisivat parhaimmillaan mittavia, vaikka ei edes puhuttaisi niin hienoista asioista, kuin vaikkapa AI-pohjainen ennustaminen. Ajattelin aloittaa tässä artikkelisarjan siitä, mitä opin, kun tein ns. 360-näkymän toimintaamme.

Ensin vähän taustaa minusta: olen toiminut IT-ammattilaisena 90-luvun alkuvuosista lähtien. Tulin lisäksi viime vuosikymmenenä perustaneeksi menestyneeksi osoittautuneen pilvipalveluyrityksen, joka myy palveluja toisille yrityksille. (Täällä lisää siitä) Tämä kirjoitussarja liittyy täten vahvasti B2B/SAAS-toimintaan, mutta osin sitä voi ehkä soveltaa muuhunkin yritystoimintaan?

Olen pistänyt merkille, että lähes kaikilla yritysaiheisilla foorumeilla puhutaan datapohjaisesta päätöksenteosta ja dataan perustuvasta liiketoiminnan johtamisesta, asiakaskokemuksen optimoinnista, jne.

Käytännön ihmisenä (lue: en taida olla tarpeeksi älykäs abstraktiin ajatteluun 🙂 ) minua kiinnostaa purkaa tuollaiset lauseet pienempiin osiin. Eikö niin, että laadukas asiakaskokemus koostuu ainakin näistä asioista:

  • Tunnemme asiakkaamme:
    • Onko jo/vielä asiakas? Milloin alkoi/päättyi?
    • Tarpeet ja toiveet
    • Tyytyväisyys
  • Viestintä on tehokasta:
    • Tiedämme tämänhetkiset yhteyshenkilöt
    • Kohdistamme viestit hyvin
  • Tiedämme, mitä olemme keskustelleet asiakkaidemme kanssa:
    • Myyjät
    • Asiakaspalvelu
    • Muut yhteydenotot
  • Kaikilla asiakkuuksiin liittyvillä sidosryhmillä on läpinäkyvyys laskutustietoihin. (Otin tämänkin mukaan tähän, tuoreiden kokemuksieni perusteella.)
  • Tiedämme, miten asiakas käyttää tuotettamme
    • Etenkin pilvipalveluissa se on helppo järjestää

Kun siis nämä ovat hallinnassa, on mahdollisuus reagoida nopeasti ja laadukkaasti tilanteisiin. Parhaimmillaan voidaan päästä jopa asioiden ennakointiin, vaikkei koneoppimisen hyödyntämistä ole vielä edes harkittu! Tästähän datapohjaisessa päätöksenteossa ja asiakaskokemuksen parantamisessa on kyse, eikö niin?

Yllämainittujen asioiden kunnossa pitäminen ei vaadi mitään kovin ihmeellisiä temppuja, eikä varsinkaan monimutkaisia koneoppimishankkeita. Väitteeni on, että se mahdollistaa silti vahvasti datapohjaisen yritysjohtamisen.

Mutta onko se data hallinnassa?

Miten tämä meneekään tosielämässä?

Kokemukseni on, että yllä mainittuihin asioihin herätään yleensä vasta siinä vaiheessa, kun tilanne on jo vähintään jonkin verran kaoottinen. Siihen on hyvin ymmärrettävät syyt:

  • Yrityksen alkuvaiheessa pääfokus on liikevaihdon kasvattamisessa, ”pinnalle pääsemisessä”. On siis harvoin aikaa ja intressejä miettiä dataprosesseja.
  • Edellä mainituista syistä johtuen yrityksessä on kohta puutteellisia prosesseja ja joskus myös toisiinsa huonosti sopivia järjestelmiä. Tällöin asiakkuuksiin liittyvät tiedot eivät ole yhdenmukaisia. Kun toiminta kasvaa, ollaan kohta tilanteessa, ettei asiakkuuksien perustietoja tunneta oman toimialueen ulkopuolella, saati sitten niihin liittyviä tärkeitä lisätietoja.

Homma rokkaa siis melko pitkäänkin, ilman, että noihin asioihin puututaan. Jossain vaiheessa yrityksen elinkaarta alkaa kuitenkin nousta kysymyksiä, kuten:

  • Kumpi näistä kahdesta tiedosta on oikea: onko tämä vielä tai enää meidän asiakas?
  • Milloin heitä on laskutettu viimeksi? Mitä laskussa luki?
  • Mitä asiakkaan kanssa on keskusteltu viimeksi?
  • Ovatko he tyytyväisiä meihin, vai onko jotain vialla?
  • Tiedämmekö, mitä ja miten he käyttävät tuotteitamme?
  • Mitkä asiakkaat ovat erityisen tärkeitä, ja millä mittarilla?
  • Saammeko palveltua asiakkaitamme laadukkaasti, onko asiakaskokemus hyvä?
  • Miksi asiakkaat eivät viihdy meillä pidempään?
  • Vaikka yritysoimintamme olisi parhaimmillaan kannattavaa, voisiko toiminnassamme silti olla tehottomuutta?

Näihin asioihin kannattaa tarttua mahdollisimman nopeasti, sillä jos yritystoiminta kasvaa näillä pelimerkeillä, kaaoskin kasvaa, ja sitä kautta tehottomuus.

Millaista dataa meillä on?

Yritysten tietojärjestelmät tallentavat tietoja, joten dataa on, se on lähtökohta. Tutkitaanpa, miltä se voisi näyttää…vakuutan, että tämä on täysin fiktiivinen skenaario, eikä yhtään ihmistä ole loukattu sitä luodessa! 🙂

  • Hienoa, että on tehokkaita myyjiä, mutta tiedot voivat joskus olla heidän jäljiltään puutteellisia. Jos tämän pitäisi olla valmis kauppa, niin missä on sopimus? Miksi tämä asiakas löytyy tuplana, kumpi näistä tietueista on oikea?
  • Minne joidenkin asiakkaiden tiedot viime vuodelta ovat hävinneet? Ai niin, meidän järjestelmä X vaihtui Y:hyn alkuvuodesta, meniköhän osa tiedoista siinä? Vai löytyisikö vielä jostain varmuuskopiot?
  • Miksen löydä tätä asiakasta laskutusjärjestelmästä? Pakkohan sen on olla siellä, kaupat tehtiin jo pari vuotta sitten. Onko nimi muuttunut, vai onko se kirjoitettu väärin? Entä Y-tunnus, miksen löydä sitä silläkään?
  • Kuukausikirjeistä tulee paljon bounceja (=virheellinen tai toimimaton sähköposti). Ja maililistoja on hankala pitää ajan tasalla.
  • Pomo kysyy, montako asiakasta meillä on juuri nyt. Apua, miten se saadaan selville, tarkasti? Laskutuksesta löytyy paras tieto, eikö niin…mutta onko kaikki asiakkaat aivan varmasti laskutuksen piirissä?
  • Ketkä asiakkaamme käyttävät oikeasti tuotteitamme? Jos laskutamme heitä käytön mukaan, onko laskutus oikealla tasolla?
  • Pitäisi ottaa käyttöön kallis markkinoinnin automaatio-järjestelmä, mutta tuntuu, ettemme saa siitä tarpeeksi hyötyä nykytilanteessa, kun data on vähän levällään. Mikä neuvoksi?

Niin, mikä neuvoksi?

Tämän artikkelisarjan toisessa osassa kerron, miten näitä haasteita mielestäni kannattaa lähteä taklaamaan käytännössä.

Julkaistu

Koodarin vuosi markkinointitiimissä

Siitä on runsas vuosi, kun siirryin Visma Software Oy:ssä markkinointitiimiin. Mitä olen oppinut?

Taustaa

Runsaan kymmenen vuoden aikana näin ohjelmistoyrityksen alkuvaiheen ja kasvun ohjelmistosuunnittelijan eli koodarin näkökulmasta. Aluksi tuotekehityksessä koodarina ja tuotekehitysjohtajana, sittemmin myös asiakaspalvelussa ja markkinointihommissa. Yrityksen myynnin aikoihin 2016-2017 kehittelin Moveniumin ns. webbiliidi-prosesseja. Siinä tulin luontevasti ottaneeksi vastuun myös asiakashallintajärjestelmän kehityksestä ja ylläpidosta. Tein töitä välillä markkinointipäällikön alaisena kahden hengen tiiminä, välillä itsekseni, toimitusjohtajan alaisena.

Siirtyminen markkinointitiimiin

Siirryin vuoden 2018 alussa Visma Softwaren markkinointitiimiin, sen kahdeksanneksi jäseneksi. Aluksi mietin, mitä annettavaa minulla on tuollaiseen ammattimaiseen markkinointitoimintaan. Siinä kävi kuitenkin niin, että rakentamani markkinointi- ja myyntiprosessien automaattiset tukitoiminnot herättivät kiinnostusta, ja aloin tuntea, että teen tärkeää markkinointiin liittyvää työtä.

Siinä hommaillessani jatkoin kuitenkin miettimistä: mikä tämä roolini oikeasti on, jota tässä toteutan? Olenko markkinointimies…en kai, tällainen introvertti!?

Markkinointi -> Asiakaskokemus

Kollegani Pasi ”Pörni” Örn opasti, että oikeastihan tässä on kyse vähän laajemmasta asiasta, kuin perinteisestä markkinoinnista: järjestelemme yritysdataa parantaaksemme käyttäjä/asiakaskokemusta. No niin, siinähän se puuttuva linkki olikin! Kansainvälisin termein puhutaan User Experiencestä, UX. Korkealentoistako? No ei:

  • Kun asiakkuuksien perustiedot ovat yksiselitteisesti yhdessä paikassa, vältetään sekaannukset ja väärinkäsitykset.
  • Kun asiakastiedot pysyvät ajantasalla, niitä pidetään luotettavina. Se on omiaan sujuvoittamaan asiakastyötä. Vaikkapa vain tieto siitä, onko asiakkuus enää/vielä voimassa.
  • Kun asiakastyössä olevat henkilöt näkevät, mitä muut ovat keskustelleet asiakkaiden kanssa, kommunikoinnin laatu paranee.
  • Kun asiakkaiden kontaktihenkilöiden lista pysyy ajan tasalla, maksimoidaan asiakasviestien läpimeno.
  • Kun yhden uniikin asiakkaaseen viittaavan tunnuksen kautta pääsee käsiksi kaikkeen asiakkuuteen liittyvään dataan, toiminnan laatu paranee kokonaisvaltaisesti.
Tämän ”häkkyrän” rakensin syksyllä 2018

Perusasioita? Itsestäänselvyyksiä jopa? Tunnustanko jotain noloa kertoessani, että ainakin itse opin nämä vasta vuosien viiveellä? Kiireessä ei ehtinyt, ja ehkä sen kuuluikin mennä näin: kun fokus on kasvussa, sen kääntöpuoli on, ettei muissa toiminnoissa voi olla yhtä vahvaa panostusta.

Vai selittelenkö vain? Olisihan voinut panostaa aikaisemminkin, siitä olisi oikeasti ollut hyötyä, jos olisi ymmärtänyt. Mutta tehty mikä tehty, eikä tässä ihan huonosti ole käynyt. Isomman yrityksen markkinointitiimissä on vihdoin resursseja ja näkemystä kokonaisvaltaisen asiakaskokemuksen rakentamiseen.

Nörttäilyllä asiakaskokemusta

Yllämainitsemani ”bulletit” toteutuvat parhaiten, jos ne hoituvat mahdollisimman automaattisesti, ja tässä onkin koko tämän jutun juoni: ainakin ensimmäisen vuoteni perusteella se on tarkoittanut nörttäilyhommia! Eikä hommat ole heti loppumassa: nyt työskentelemme mm. näiden asioiden kanssa:

  • Koko asiakasviestintä haltuun, mukaan ns. in-app-viestintä
  • Ennakoiva analyysi koneoppimista hyödyntäen, tavoitteena esim. lisämyynnin ja asiakaspoistuman ennakointi.

Asiakaskokemus ja palveluntarjojan bisneksen kehitys kulkevat käsi kädessä, ja kaikki voittavat…no shit sherlock? 🙂

Julkaistu

Sain palautetta työkavereilta

Meillä oli tiiminkehityspäivä. Jossain vaiheessa saimme tehtäväksi kirjoitella palautteita toisillemme. Silkkaa vaatimattomuuttani näytän, mitä minusta kirjoitettiin:

Onhan se kivaa, kun joskus pakotetaan sanomaan jotain positiivista työkavereista 🙂