Aurinkovoimalan tuotto kesällä ja talvella

Asensimme talomme katolle aurinkovoimalan huhtikuussa 2021. Olen tietenkin kiinnostuksella seurannut sen tuottoa siitä lähtien. Kiinnostavaa on vertailu kesä- ja talvituoton välillä. Alla olevassa kuvassa verrataan kahta päivää: viime kesän hyvin tuottava päivä ja melko aurinkoinen tammikuun päivä.

Tuossa talven kuvassa näkyy, ettei päivä ollut ihan pilvetön. Aurinkokennojen pinnat ovat tuona päivänä lumettomina. Noista kuvista näkee kiinnostavia asioita:

  1. Aurinko paistaa talvella matalalta, jolloin huipputehot ovat pienemmät kuin kesällä
  2. Samasta syystä aurinko on taivaalla paljon lyhyemmän ajan, kuin kesällä.
  3. Näiden päivien kokonaistuoton ero on noin kuusinkertainen kesän ja talven välillä.

Jos saan täydellisen aurinkoisen päivän käyrät tältä talvelta, laitan sen mukaan tänne vertailun vuoksi.

Löytyi kuva vuodelta 1988

Luulin, ettei 18-vuotiaasta minusta ole juuri kuvatodisteita. Veljeni teki minut iloiseksi näyttämällä tämän kuvan minulle: olen siinä huoneessamme, jonka yhden nurkan olen vallannut harrastuksilleni: vasemmalla on ensimmäinen radioamatööriasemani (tunnukseni oli tuolloin SM4SWF), ja edessäni on muistaakseni Osborne-merkkinen  ns. PC XT, jossa oli hurjat 640kB keskusmuistia ja 20MB kiintolevy. Modernisti kaksi näyttöä, toinen mustaoranssi (VGA eli 640x480px) ja toinen värillä (CGA 320x200px).

Facebookissa kysyttiin, mistä sain tuolloin varat tällaisten laitteiden hankintaan. Töillä: olin kesäisin töissä talotehtaalla, ja juuri edeltävänä kesänä olin ollut turvesuolla. Marjanpoiminnasta sai myös rahaa. Minulla oli valtava intohimo tällaisiin asioihin. Lisäksi alakerrassa oli tasapainon vuoksi piano.

Nörttiprojekti: Nettisivujen rankkausta iän mukaan

Töissä tuli kerran tarve järjestää lista nettisivuja sivuston teknologian vanhuuden mukaiseen järjestykseen. Koska emme löytäneet valmista palvelua/ohjelmaa, joka tämän tekisi, otin tästä itselleni pienen pähkinän purtavaksi. Tuli nimittäin tunne, ettei tuollaiseen kovin monta tuntia mene, sillä tiesin, ettei järjestelmän tarvitse olla täydellinen. Noin viiden tunnin päästä pystyin tuottamaan nettisivulistan yllättävänkin uskottavasti ikäjärjestyksessä.

Voisin näyttää, miten sen tein, jos joku innostuisi kehittämään tätä ideaa pidemmälle. Otan mielelläni vastaan kehitysehdotuksia! 🙂

Näin aloitin

Sain ajatuksen, että sivustoja voisi rankata niiden html-koodissa löytyvien tekstipätkien ja html-tägien mukaan. Web-teknologia on 1990-luvun alkuvuosien jälkeen kehittynyt kovasti, ja olen itse työskennellyt sen parissa alusta asti. Siksi ajattelin, että minulla voisi olla jonkinlainen mutu-pohjainen käsitys siitä, millä vuosikymmenellä löytyi mitäkin html-tägejä jne.

Jatkoajatuksena tuli, että tägejä voisi pisteyttää plus- ja miinuspisteillä tägien ”moderniuden” mukaan: miinuspisteitä tulee vanhoista tägeistä ja pluspisteitä uudemmista. Tein hakuammunnalla tällaisen listan tägeistä ja koitin muutaman testisivun perusteella arvioida niiden pisteytyksiä:

Rankdata.xlsx

Nyt tarvitaan vielä ohjelma, joka lukee listan nettiosoitteista ja tuon Rankdata.xlsx:n. Nettiosoitelista (tässä Yritykset.xlsx) sisältää kolme saraketta:

Y-tunnusYritys WWW-osoite
1234567-8Yritys Oyhttp://www.yritys.fi

Koska työympäristöni oli tuota tehdessä Windows ja halusin päästä nopeasti liikkelle, päätin käyttää koodauskielenä minulle hyvin tuttua Perliä. (En vielä tuolloin ollut opetellut Pythonia, joka olisi nykyisin valintani tällaiseen). Latasin läppärilleni ActivePerlin ja aloin koodata. Muistin, että 2000-luvun alussa Professional Tester-lehteen kirjoittamassani artikkelissa, on valmiita pätkiä copy-pastettavaksi, joten hyödynsin tietenkin sitä. (Kai tiesit, että kaikki koodaajat copy-pastettavat ratkaisuja, tyypillisesti googlettamalla? 🙂 )

Jouduin asentelemaan Perliin lisämoduleja, jotta sain sen kutsumaan nettisivuja. En enää muista, oliko ActivePerlissä oma lisäosien lataamisohjelma, vai hainko niitä CPANista.

Ohjelmastani ei tullut mitenkään kovin kaunis, mutta sain sen kyllä toimimaan. Tässä on koko koodi:

use LWP::UserAgent;
use Spreadsheet::ParseXLSX;
use Spreadsheet::WriteExcel;

my $parser = Spreadsheet::ParseXLSX->new;

#
# Read the input data  from rankdata.xlsx into the @data hash
#
my @data;
my $excel = $parser->parse("rankdata.xlsx");
foreach my $sheet (@{$excel -> {Worksheet}}) {
 	$sheet -> {MaxRow} ||= $sheet -> {MinRow};     
	foreach my $row (1 .. $sheet -> {MaxRow}) {
         
		$sheet -> {MaxCol} ||= $sheet -> {MinCol};         
		$data[$row]{"tag"} = lc($sheet -> {Cells}[$row][0]->{Val});
		$data[$row]{"points"} = $sheet -> {Cells}[$row][1]->{Val};
	}
}

#
# Read the company info to the @companies hash
#
my @companies;
$excel = $parser->parse("Yritykset.xlsx");
foreach my $sheet (@{$excel -> {Worksheet}}) {
 
 	$sheet -> {MaxRow} ||= $sheet -> {MinRow};
        
	foreach my $row (1 .. $sheet -> {MaxRow}) {
         
	        $sheet -> {MaxCol} ||= $sheet -> {MinCol};
        
                $companies[$row]{"businessid"} = $sheet -> {Cells}[$row][0]->{Val};
                $companies[$row]{"company"} = $sheet -> {Cells}[$row][1]->{Val}; 
		$companies[$row]{"url"} = $sheet -> {Cells}[$row][2]->{Val};
		$companies[$row]{"points"} = 0;
		
	} 
}

# Open excel file for writing and write headers
my $workbook = Spreadsheet::WriteExcel->new('Output.xls');
$worksheet = $workbook->add_worksheet();
$format = $workbook->add_format();
$format->set_bold();

$worksheet->write(0,0, "Business ID",$format);
$worksheet->write(0,1, "Company",$format);
$worksheet->write(0,2, "URL",$format);
$worksheet->write(0,3, "Points",$format);
$worksheet->write(0,4, "Size",$format);
$worksheet->write(0,5, "Other",$format);
$worksheet->write(0,6, "Tags",$format);
#
# Loop all companies, call URLs, determine points, write result to Output.xls
#
my $ua = LWP::UserAgent->new;
for my $c (1 .. $#companies) {  
 	print "Analyzing ".$companies[$c]{"url"}."...";
	my $req = HTTP::Request->new(GET => $companies[$c]{"url"});

	my $resp = $ua->request($req);
	if (!$resp->is_success) {
    	$companies[$c]{"error"} = "Error ".$resp->code.". ";
    	if (!$resp->code == 500) {
    		$companies[$c]{"points"} = -100;
    	}
	}
	else {
		$companies[$c]{"error"} = "";
	}

	# Loop the http response
	$companies[$c]{"tags"} = "";
	$page_content = lc($resp->as_string);
	$companies[$c]{"size"} = length($page_content);
	my @lines = split /\n/, $page_content;
	foreach my $line (@lines) {	
		# Check with tag data	
		for my $i (1 .. $#data) {   
			if ( index($line, $data[$i]{"tag"}) > 0 && !$data[$i]{"found"}) {
	    		$companies[$c]{"points"} += $data[$i]{"points"};
	    		$companies[$c]{"tags"} = $companies[$c]{"tags"}.", ".$data[$i]{"tag"};
	    		
	    		print $companies[$c]{"tags"}.";";
	    		$data[$i]{"found"} = 1;
			}
		}
		
	
	}
	print $companies[$c]{"error"};
	
	# Penalize small pages
	if ($companies[$c]{"size"} < 5000) {
		$companies[$c]{"points"} -= 30;
	}
	elsif ($companies[$c]{"size"} < 10000) {
		$companies[$c]{"points"} -= 15;
	}
	
	$worksheet->write($c,0, $companies[$c]{"businessid"});
	$worksheet->write($c,1, $companies[$c]{"company"});
	$worksheet->write($c,2, $companies[$c]{"url"});
	$worksheet->write($c,3, $companies[$c]{"points"});
	$worksheet->write($c,4, $companies[$c]{"size"});
	$worksheet->write($c,5, $companies[$c]{"error"});
	$worksheet->write($c,6, $companies[$c]{"tags"});
	print $companies[$c]{"points"}." points. ";
	print "Done.\n $c.";
	
	# Reset "tag found" status for the next page in loop
	for my $i (1 .. $#data) {
		$data[$i]{"found"} = 0;
	}
}
print "Analyze completed.";

Ylläoleva ohjelma tuotti noin 20 minuutissa (kävi siisläpi 1700 nettiosoitetta) Excel-tiedoston, jossa nettisivut olivat saaneet rankkauksia sen mukaan, mitä sivulta löytyi (yritystiedot poistettu ennen kuvakaappauksen ottamista…ymmärrätte varmaan).

Ei mitenkään kaunista, mutta siivoilin listan käsin ja järjestelin sen Points-sarakkeen mukaana ja muutama pistokoe todisti, että olin onnistunut hankkeessani melko hyvin.

Mitä opin?

  • Perl on vanha ohjelmointikieli ja teknologia, opin sen 1990-luvulla. Oli esim. vaikea saada SSL-modulia toimimaan; sitä tarvittiin https-suojattujen sivujen tutkimiseen. Myöhemmin tajusin, että esim. modernilla Pythonilla tuo ohjelma olisi ollut kaikin puolin kätevämpi tehdä, sillä se kommunikoi sujuvammin nykyrajapintojen kanssa.
  • Kaikki sivustot eivät päästäneet skriptiä läpi, sillä ne tunnistivat sen todennäköisesti ”robotiksi” User Agent-tiedon perusteella. Myöhemmin testasin User Agentin feikkaamista (sai nettisivut luulemaan systeemiäni Chrome-selaimeksi) ihan hyvällä menestyksellä. Tässä Perl-koodinpätkä siihen:
    $ua->agent(”Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36”);

Vielä yksi asia!

Varomaton nettisivujen tutkiminen tällaisella ”robotilla” voidaan hyvällä syyllä pitää vähän kyseenalaisena puuhana. Kannattaa olla tarkkana, ettei vahingossa kehitä vaikkapa silmukkaa, joka pommittaa jotain tiettyä nettisivua kutsuilla. Sellaista voisi kutsua jonkinlaiseksi alkeelliseksi palvelunestohyökkäykseksi. Nykyiset nettisivut eivät tällaisesta yleensä kyykähdä, mutta onhan vastuuton robottien käyttö kiusantekoa ja sotkee ainakin ”pommituskohteiden” nettisivu-kävijätilastoja.

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? 🙂

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ä.

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? 🙂