31.08.2018 / Arto Pihlaja

Tänä keväänä Bilotin ja Louhian asiantuntijat venyttivät päiväänsä ja käyttivät vapaa-aikansa BilotGo.ai hackathon-kisassa. Olin mukana yhdessä tiimissä – siinä joka lopulta onnekkaasti voitti kilpailun. Tässä blogissa kerron ajatukseni siitä, minkä seikkojen ansiosta onnistuimme. Uskon että ne pätevät muihinkin analytiikka- ja tietojärjestelmäprojekteihin.

1. Oikean kysymyksen tunnistaminen

Olemme varmaan kaikki kuulleet innostavia esimerkkejä tekoälyn ja koneoppimisen käytöstä. Usein nuo esimerkkitapaukset ovat kuitenkin vuosien määrätietoisen työn tuloksia. Tilaajalla pitää olla näkemys siitä, miten tekniikkaa hyödynnetään liiketoiminnassa, mutta tavoitetta kohti edetään pienin askelin. On paljon helpompaa päättää ensin pilotista ja sitten mahdollisista seuraavista iteraatioista kuin hakea hyväksyntää vuosia kestävälle, miljoonien eurojen investointiohjelmalle. Rajauksia joutuu tekemään toteutuksenkin aikana, mutta joka vaiheen tulosten pitää silti olla hyödyllisiä.

kuvalähde: ligonier.org

Hackathonissa käytimme työn tilaajan kanssa paljon aikaa sopivan tehtävän tunnistamiseksi ja rajaamiseksi. Meidän piti tunnistaa kysymys, jonka vastauksesta olisi selvää hyötyä liiketoiminnassa, ja joka olisi ratkaistavissa käytettävissä olevilla tiedoilla ja ajalla. Aluksi ryhdyimme selvittämään lehmien ruokinnan vaikutusta maidon määrään ja laatuun, mutta työn edetessä jouduimme määrittelemään kysymyksen uudelleen. Kisassa päädyimme ennustamaan maidon määrää lehmän iän ja poikimisten perusteella ja jätimme muut kysymykset jatkoprojekteihin.

 

2. Tiedon kerääminen

Kun kysymys on selvä, kerätään vastauksen selvittämiseen tarvittavat tiedot. Varsinkin alussa työ voi olla vuorottelua kysymyksen määrittelyn ja tiedon etsimisen välillä, sillä tiedon määrä ja laatu eivät aina vastaakaan käsityksiä.

Hackathonissa ryhdyimme tekemään ennustavaa mallia esimerkkitiedostojen perusteella. Vasta kisan puolivälin jälkeen osoittautui, että nuo tiedostot oli koottu käsin yksittäisistä lähteistä. Varsinaisen aineiston rakenne poikkesi esimerkeistä täysin ja mikä pahinta, tieto ei ollut riittävän kattavaa. Palasimme siis määrittelyyn. Sovimme myös, että kisan jälkeen teemme suunnitelman tiedon keräämiseksi ja jalostamiseksi.

 

3. Tiedon valmistelu

Yleisesti sanotaan että koneoppimisprojektissa ainakin 80 % työstä on tiedon valmistelua ja alle 20 % ennustavan mallin kehittämistä. Näin oli tässäkin projektissa – toteutusvaiheen osalta! Kun otetaan huomioon määrittely ja julkaisun valmistelu, algoritmien soveltamiseen käytetyn ajan osuus jäi vielä selvästi pienemmäksi.

Keskeisin osa datastamme oli roboteista saatuja mittaustuloksia, joten sen luulisi olevan määrämuotoista ja johdonmukaista. Käytännössä kuitenkin robotit olivat erilaisia ja tuottivat eri muotoista dataa. Sen lisäksi poikkeavien tulosten tulkinta oli vaikeaa. Esimerkiksi kun maidon rasvapitoisuus oli 30 %, kyseessä oli varmasti virhe, mutta olivatko 6 % ja 12 % välillä olevat arvot? Tiedon valmistelu edellyttää sen merkityksen syvää ymmärrystä. Siksi teimmekin sitä tiiviissä yhteistyössä tilaajan kanssa.

kuvalähde: Raisio Oyj

4. Julkaisu

Upeakin toteutus jää turhaksi, jollei kohdeyleisö omaksu sitä.

Hackathon-kisamme päättyi siihen, että toteutukset esiteltiin ulkopuolisista asiantuntijoista kootulle tuomaristolle. Niinpä tiimimme omistikin kahdeksan viikon kokonaisajasta yli viikon käyttöliittymän parantamiseen ja loppudemon valmisteluun. Mietimme esityksen kantavan tarinan ja karsimme sisältöä, jotta ratkaisu ja sen hyödyt korostuisivat. Kuten valmentajamme Antti Apunen meitä neuvoi: kohdeyleisöä ei kiinnosta, mihin algoritmiin toteutus perustuu. He luottavat siinä meidän asiantuntemukseemme ja haluavat vain nähdä tulokset ja hyödyn. Kun sisältö oli mietitty, harjoittelimme sen esittämistä toiminto toiminnolta ja jopa sanasta sanaan.

Hackathon päättyi vartin mittaisiin esityksiin, mutta muissakin projekteissa varsinainen julkaisuhetki on lyhyt ja ratkaiseva, oli sitten kyse sisäisen järjestelmän käyttöönotosta tai verkkopalvelun julkaisusta. Kuluttajat harvoin antavat toista mahdollisuutta, eikä ammattikäyttäjienkään kannata olettaa olevan pitkämielisiä. Ratkaisun hyödyn pitää nousta selkeästi esille, ja käytön pitää näyttää helpolta. Siispä projektin loppuvaiheessa täytyy malttaa lopettaa teknisten ominaisuuksien täydentäminen ja panostaa aikansa julkaisuun. Kun julkaisu onnistuu, ratkaisua voi hyvin täydentää seuraavissa iteraatioissa.

Uskon, että hackathonissa viimeistelty esityksemme lopulta ratkaisi kisan, ja palkitsi siten viikkojen uurastuksen. Samoin uskon, että projektin kuin projektin viimeistely varmistaa hyödyt.

Lisää BilotGo.ai-hackathonin ideasta täällä ja kisaamisesta täällä. Esittelemme muiden joukkueiden kanssa hackathonin tuloksia tänä torstaina tapahtumassamme – olethan tulossa?

kuvalähde: jonwilma.com

28.08.2018 / Mika Laukkanen

Tässä on kollega Ville Niemijärven kirjoitus analytiikan (nykyään tekoäly tai koneoppiminen) hyödyntämisestä vuodelta 2014. Ajattelin hieman päivittää sitä ja laittaa uudelleen jakoon, kun aihe on ajankohtaisempi kuin artikkelin ilmestymisvuonna. Kukapa muuten tietää, että millä termillä näitä ratkaisuja kutsutaan seuraavan neljän vuoden päästä?


Asiakaspoistuma-analyysi (eng. churn) tarkoittaa analytiikan prosessiketjua, jossa selvitetään mitkä asiakkaat ovat vaarassa poistua, millä todennäköisyydellä ja miksi. Poistuma tarkoittaa sitä kun asiakas lopettaa sopimuksen palveluntarjoajan kanssa tai yksinkertaisesti lopettaa asioimisen yrityksessä. Voidaan puhua myös asiakaspidosta (eng. retention). Termi liittyy läheisesti myös asiakkuuden elinkaaren arvon määrittämiseen (customer life-cycle value) ja nykypäivän yhteen muotitermiin; customer journey. Itse näkisin kuitenkin, että kyseessä on enemmänkin yksinkertaisesti paremmasta asiakashallinnasta ja huolenpidosta…

Poistuma-analyysi sopii hyvin sopimusliiketoimintaan, esimerkiksi sähköyhtiöille, puhelin- ja internet operaattoreille, kuntosaliketjuille tai lehtitaloille. Mutta poistuma-analyysiä voidaan tehdä myös vähittäiskaupassa, jos vain asiakas tunnistetaan (kanta-asiakasjärjestelmän avulla). Tällöin pitää vain päättää milloin asiakas on poistunut? Mikä on riittävän pitkä aika, että asiakas ei ole käynyt kaupassa, jotta voidaan päätellä hänen vaihtaneen vakiokauppaansa.

Tässä kirjoituksessa käydään läpi asiakaspoistuma-analyysiä ja miten se tehdään käytännössä. Lähestymme aihetta yleisestä yksityiseen. Lopussa näytämme kädestä pitäen miten homma tehdään alusta loppuun.

Asiakaspoistuma-analyysin tuotto on helppo laskea

Kaikessa analytiikkatyössä tulee laskea mitä saamme analyysistä irti, mikä on investoinnin ROI, paljonko jää viivan alle. Jollei investointi tuota moninkertaisesti enemmän kuin analyysi ja tiedon keräys maksaa, ei sitä kannata tehdä.

Asiakaspoistuman osalta tämä on erittäin helppoa tehdä. Otetaan esimerkki sähkön myynnistä.

Sähköyhtiöllä on 100 000 asiakasta. Keskimääräinen laskutus per asiakas on 1000e/vuosi. Nopea selvitys sähköyhtiön sopimuskannasta kertoo, että keskimäärin vuodessa sopimuksen lopettaa 8% asiakkaista.

Tämä tarkoittaa, että asiakkaita poistuu 8000 kpl/vuosi. Rahassa tämä on siis 8000kpl*1000e=8 miljoonaa euroa. Tuo on se potti, jota lähdemme pienentämään ja sitä kautta tekemään asiakkaallemme lisää rahaa.

Osa näistä 8000:sta poistuu luonnollisen poistuman kautta, osa vaihtaa kaupunkia. Ja sitten on se osa joka vaihtaa palveluntarjoajaa koska yrityksen tuote, palvelu tai hinta ei ole riittävän hyvä. Tai kilpailijalla on parempi. Kutsuttakoon tätä laadulliseksi poistumaksi.

Kun menemme asiakkaalle, teemme aina vastaavan laskelman ja arvioimme asiakkaan kanssa yhdessä, mikä on tuon laadullisen poistuman osuus ja kuinka paljon on realistista saada pienennettyä sitä. Sähköyhtiöiden osalta voimme katsoa julkisesta datasta, esim. THL:ltä, mikä on muuttoliike kunnasta pois päin ja paljonko poistuu jalat edellä. Näin emme joudu arvailemaan vaan meillä on faktaa laskelmien taustalla. Sanottakoon esimerkkinä, että sähköyhtiön tapauksessa 3% on luonnollista/muuttopoistumaa ja loput 5% on laadullista poistumaa. Poistumaa, johon voimme vaikuttaa. Tähän iskemme kyntemme.

Entä jos voimme pudottaa tuota 5% poistumaa vaikka vain yhden prosenttiyksikön? Tämä tarkoittaisi 1000 asiakasta ja miljoonaa euroa vuodessa lisämyyntiä. Jos analyysi maksaa 20 000 euroa, on investoinnin tuotto aika huima. Se on jotain sellaista, jota kannattaisi kaikkien tavoitella.

Mitä dataa poistuma-analyysi tarvitsee?

Ensiksi otamme historiatietoa eli tietoa jo poistuneista ja ei-poistuneista asiakkaista. Toisin sanoen sähköyhtiön tapauksessa luemme sopimustietokantaa ja sähkönkulutustietoja (yhä yleisemmin tietovarastoa tai edistyneimmissä yrityksessä erikseen toteutettua analytiikkakantaa) ja haemme sieltä mahdollisimman pitkän historian, mahdollisimman monelta asiakkaalta. Mitä enemmän sitä parempi. Historia-aineistoon otetaan mukaan asiakkaiden taustatietoja sekä käyttäytymiseen liittyvää tietoa.

Taustatietoja ovat esimerkiksi

  • alue/kaupunki/postinumero
  • demografiatiedot (tulo- ja koulutustaso)
  • sukupuoli
  • ikä
  • asiakkuuden kesto
  • talotyyppi, koko, lämmitysmuoto jne. toimialaspesifistä tietoa

Käyttäytymiseen liittyviä tietoja ovat esimerkiksi:

  • kulutus- ja laskutushistoria (esim. keskimääräinen kulutus per kk)
  • ostetut tuotteet (eli millainen sopimus)
  • reklamaatiota, asiakaspalautteet, yhteydet asiakaspalveluun
  • maksuhäiriöt
  • muut toimialaspesifit tiedot
  • Ja lopuksi se tärkein tieto: onko asiakas poistunut vai ei (K/E)

Monilta yrityksiltä ei löydy kaikkia näitä tietoja, olen nähnyt yrityksiä joilla asiakkaista tiedetään käytännössä vain numero ja osoite. Ei edes nimeä tai sitä onko kyseessä yritys- vai henkilöasiakas. Ennen kuin analytiikkaa päästään hyödyntämään täysillä, on edessä usein systemaattinen tiedon keräämisvaihe ja mahdollisesti muutokset lähdejärjestelmiin/tietovarastoon.

Ennen analyysia emme tiedä mitkä tiedot ovat relevantteja ja vaikuttavat poistumisen takana ja sen selvittäminen onkin koko homman ydin.

Miten poistuma-analyysi tehdään?

Kun tiedot on kasassa, jaamme datan kahteen eri settiin: opetusdataan ja testidataan (esimerkiksi suhteessa 60-40). Mainittakoon että data voitaisiin jakaa myös kolmeen eri settiin: opetus-, testi- ja validointidata. Joka tapauksessa, opetusdatan avulla muodostamme ennustemallin, käyttäen liiketoimintaongelmaan sopivaa analytiikka-algoritmia (esim. gradient boosting, neuroverkko, logistinen regressio, naive-bayes). Parhaan mallin löytäminen vaatii useita iteraatioita.

Työ vaatii analytiikkasoftan. Itse suosimme Pythonia ja R:ää, jotka sitten voivat pyöriä vaikkapa Azuren tai AWS:n pilvessä.

Muodostunutta ennustemallia testataan testidataa vasten. Koska testidata on historiadataa, tiedämme onko asiakas poistunut vai ei. Testin voisi ajatella siten, että peitämme tuon poistuma-tiedon ja kuvittelemme, että kyseessä olisi täysin uutta dataa. Annamme mallin tehdä ennusteen eli kertoa todennäköisyydet poistua kullekin asiakkaalle. Tämän jälkeen tarkastamme tuloksen ja arvioimme mallin tarkkuuden. Näin varmistamme toimiiko malli ja kannattaako sitä hyödyntää uutta dataa vasten vai pitääkö sitä parantaa.

Asiakaspoistuma-analyysin tulokset

Poistuma-analyysi tuottaa nipun tuloksia, esim.:

  1. Kaikki nykyiset asiakkaat listattuna poistumatodennäköisyyden mukaan
  2. Selittävät tekijät poistuman taustalla
  3. Ennustemallin hyvyyden kriteerit (AUC, Confusion matrix..)

asiakaspoistuma_tulos

Ensimmäinen tarkoittaa siis konkreettista listaa, jonka voit heittää myynti-/asiakaspalveluyksikölle tai soittokoneistolla ja käskeä kontaktoimaan heti aluksi akuuteimmat top 100 poistujaa.

Toinen tuotos eli selittävät tekijät antavat tulkinnan ilmiölle. Ne kertovat miksi asiakkaat poistuvat. Nämä tulokset on erittäin arvokasta tietoa niin asiakaspalvelulle, myynnille kuin tuotepäälliköille, liiketoiminnan kehittämiselle ylipäätään.

Analyysissä voi tulla esille, että hinta ei olekaan merkittävä tekijä poistuman taustalla vaan huono asiakaspalvelu tai tietylle asiakassegmentille sopimaton tuotepaletti (esim. sähköyhtiöltä puuttuu ekosähkö valikoimastaan). Riippuen valitusta menetelmästä, tulee eroja miten suoraviivaisesti näitä selittäviä tekijöitä voidaan tulkita. Esimerkiksi syvän neuroverkon (deep learning) tulkinta on huomattavasti monimutkaisempaa kuin logistisen regression antamisen tulosten.

Parhaimmassa tapauksessa analyysin tuotoksista voidaan generoida sääntökoneisto ja sisällyttää se esimerkiksi asiakaspalvelun työpöydälle tai CRM-järjestelmään. Säännöt voivat olla yksinkertaisuudessaan kertoimia ja IF-lauseita ja voidaan toteuttaa esimerkiksi SQL-komentoina. Analytiikan tulokset kirjoitetaankin usein takaisin joko operatiivisiin järjestelmiin tai tietovarastoon.

Kolmas tuotos kertoo, että miten tarkka ja hyvä malli on. Ei mennä tässä siihen matematiikkaan tarkemmin. Kannattaa vaan tietää, että siihen on suhteellisen objektiiviset keinot käytössä.

Analyysistä toimintaan

Analytiikan pitää johtaa toimintaan. Sen pitää tuottaa tulosta. Tämä erottaa sen perinteisemmästä raportoinnista ja business intelligencestä, jossa tuijotetaan enemmänkin raportteja ja taulukoita. Näytti käppyrät mitä tahansa, hommia jatketaan kuten ennenkin. Kunnes ollaan karilla tai kortistossa.

Poistuma-analyysissa toiminta tarkoittaa monta asiaa, esimerkiksi:

  1. kontaktoidaan poistumariskissä olevat asiakkaat
  2. pyritään pitämään heidät tai parhaimmassa tapauksessa tekemään lisämyyntiä
  3. kehitetään asiakaspalvelun laatua
  4. kehitetään tuotteita/palveluita vastaamaan paremmin kysyntää
  5. ennakoidaan liikevaihdon muutos kun tiedetään ennuste tulevasta poistumasta

Miksi yritys ei tee asiakaspoistuma-analyysiä?

Olemme tehneet vuosien varrella valtavan määrän eri analytiikan sovelluksia ja projekteja. Asiakaspoistuma-analyysi on antanut näistä todennäköisesti parhaimmat tulokset, varsinkin jos mitataan euroissa asiakkaiden saamaa hyötyä. Menetelmä on helppo ja suhteellisen nopea toteuttaa, se on helppo ymmärtää ja tulokset ovat käsin kosketeltavat.

Silti yllättävän harva yritys todella hyödyntää sitä. Syyt ovat moninaiset lähtien tietämättömyydestä aina itsepetokseen.

Surullisin on itseriittoisen sinnikäs toteamus, että ei meidän asiakkaat poistu muuta kuin manan majoille tai hinnan perässä, ne pihit penteleet.

Yrityksen tuotteessa ei ole kuulema mitään vikaa. Palvelu on priimaa ja markkinaosuus olisi 100% jos vain kilpailijat eivät myisi arvelluttavan halvalla sekundatuotteitaan. Jostain syystä liikevaihto kuitenkin mataa.

Uuden asiakkaan hankinta on aina kalliimpaa kuin vanhan pitäminen. Parhaimmassa tapauksessa tekemämme asiakaspoistuma-analyysin tuloksena kontaktoiduille asiakkaille saatiin myytyä aivan pöljänä lisää tavaraa. Asiakkaat eivät aina ole siis tyytymättömiä palveluun, he ovat vain herkkiä myynnille. Sinun kannattaa olla silloin ensimmäisenä paikalla.


 


22.08.2018 / Mika Laukkanen

Artikkelin kirjoittaja on Data Scientist Pekka Tiusanen Bilotilta, jonka kanssa Louhia yhdistyi kesäkuussa 2018.  Jatko-osa seuraa ensi viikolla.

ABOUT HIT RATE FORECASTING

Challenges in the sales process and management are common to many organizations. Improved data availability and machine learning algorithms provide means to forecast sales opportunity hit rates, which brings forth two interesting ML use cases. On the sales management level, keeping track of the sales funnel is essential and expected profit from the current sales pipeline is definitely of interest. On the contrary, individual salespersons have to be aware of critical price points in order to optimize profitability. Machine learning can answer such questions as “How much money do I currently have in the sales pipeline?” and “What price should I offer in this situation?”.

DATA ACQUISITION & MANIPULATION

The forecasting results will be only as good as your model and data. Opportunity hit rate is in the least to some extent dependent on price, lead type and margin. Hence, CRM attributes are worthwhile to consider in any hit rate engine. However, relevant information may reside in various data sources, such as ERP, IoT and social media. In large organizations, it is often most convenient to import all the forecasting attributes from an existing data warehousing architecture. Having finished the compilation stage, one may have to spend some time on joining tables and transforming data to form a comprehensive set of relevant features with good data quality.

1. The Process of Adopting a Hit Rate Engine

After the data has been cleaned, some data manipulation might still be required. For example, depending on the method and analysis platform, categorical features may have to be separately converted to dummy variables. In the modelling stage, each categorical feature forms as many binary variables as there are factor levels.

One may also want to combine classes within some of the features to achieve less specific categorizations. For instance, all the lead types that relate to marketing could be combined, leaving the rest of the lead types untouched. This type of considerations are ad hoc and they may improve or deteriorate forecasting performance depending on the chosen methodology and data.

Moreover, there is often a logical order to some of the categorical model features. Such ordinal features are converted into numeric form by applying the associated logical order. For example, a variable with values “satisfactory”, “better than satisfactory”, “good”, “very good” and “excellent” would naturally convert to a scale from 1 to 5.

For some features, it is important to find the optimal level of detail, often referred to as granularity in data warehousing jargon. This applies to, for instance, geographical location and organizational data. A good rule of thumb is that all the classes of each feature should have enough examples to justify inclusion. If only a few sales were recorded at a freshly opened sales office, including this sales office as a class in the training data probably displays an excessive level of detail. This type of a situation would allow two options: (1) either substitute “sales office” with a less specific feature, such as “sales region”, or (2) replace the values of offices having too few recorded sales with NAs.

Finally, it is often sensible or even necessary to derive new variables from the set of ML features extracted, transformed and loaded (ETL). For example, if margin is not provided, it can be calculated based on cost and price. It is also common to use some type of ratios as variables. One should also verify that the chosen statistical model is not sensitive to the number of variables or correlations between them. Truncating the number of features at some point depending on the purpose of your analysis and the chosen machine learning algorithm should be considered. It is sometimes useful to reduce dimensionality of the data by applying principle component analysis, for example.

PROPOSED METHODOLOGY

The gradient boosting algorithm is based on steepest descent and loss function minimization. The method first fits training set mean or some other rudimentary model to the target series which, in this case, consists of “won” or “lost”. A decision tree is fitted to the resulting error terms of this crude approximation. Another tree is fitted to the residuals of the first tree and iterations are continued until the chosen number of trees has been reached. Gradient boosting thus produces a forest which consists of individual trees. It makes sense to use regression tree based gradient boosting instead if your dependent variable is continuous. The process of fitting a gradient boosting model minimizes mean squared error analogous to loss function in mathematical terms.

The resulting statistical model is just an ensemble of trees generated based on your training data. The training series can be formed by taking a 70-80 % random sample of the total observations. Passing an individual opportunity to the forest-like model yields a hit rate forecast. One opportunity is just a row with the corresponding model feature values. The feature values of this particular opportunity determine the forecasting outcome of each tree. All the trees shift the resulting forecast up or down.

The forecasting model is tested against the validation set which typically comprises 20-30 % of total observations. Prediction accuracy can be determined by benchmarking the model with a confusion matrix. The matrix indicates how many lost (0) opportunities were correctly identified lost and, on the contrary, the number won (1) opportunities correctly forecasted.

Receiver operating characteristic (ROC) analysis is another way to benchmark classification models. The ROC curve displays the true positive rate (TPR) on the y-axis, whereas the false positive rate (FPR) is reflected on the x-axis. The true positive rate is the share of won opportunities correctly identified as such in the validation set. Furthermore, the false positive rate is for the proportion of lost opportunities incorrectly predicted won.

Estimated raw probabilities are used for classification scoring. The ROC curve illustrates how the TPR and FPR values behave as the classification threshold is changed. The intuition is that model performance improves in terms of detecting won opportunities along with a decline in the accuracy of catching lost opportunities as a consequence of shifting the threshold.

Possible overfitting of the model can be assessed by reviewing the ROC curves of training and validation sets. Any statistical model is overfitting if there is considerably more area under the curve in the training set compared to validation. Overfitting means that a statistical model is too specific so that it overestimates the associated predictive power. Complex statistical models are prone to overfitting. Hence, one should avoid using an excessive number of trees and tree depth as gradient boosting is employed.

2. Forecast Benchmarking

FROM FLASHCARDS TO TRULY DATA-DRIVEN SALES FUNNEL

Now that the hit rate engine is up and running, it is time to feed it some opportunity data! The model predicts the probability of acceptance for each individual opportunity fed to the algorithm, which allows better approximation of the sales funnel. The expected aggregate revenue can be estimated by multiplying predicted hit rates by the corresponding opportunity prices and summing up the results. Assuming that margin for each opportunity is known or derivable, it is possible to produce profitability estimates as well. The forecasting results can be integrated to the current BI reporting solution, which enables enhanced sales management and coordination.

3. Intelligent Sales Funnel

The gradient boosting method also allows extraction of the most relevant features predicting hit rate, which provides sales management with interesting insights. Hit rate drivers can be considered valuable from the product portfolio viewpoint too. However, some of these attributes are bound to be rather obvious — if price and margin are not listed among the most important hit rate features, your model may be misspecified.

Gradient boosting is a non-linear modeling procedure, so a direct two-way interpretation for factor contribution does not exist. Usually a combined feature importance metric is used because model attributes have three importance dimensions to them. Firstly, the “gain” metric is a volume-oriented forecast contribution statistic. On the contrary, “frequency” conveys how often features occur as tree splits within the model. Finally, the “cover” metric is for the relative number of opportunities associated with each particular feature. In case you are not satisfied with the combined metric nor individual components, it is also possible to visualize individual trees to truly understand the model dynamics.

SCENARIO-BASED PROFITABILITY MODELLING

The hit rate engine enables “what-if” analysis for individual opportunities, which allows the model to be deployed as a sales assistant. This ML implementation provides salespeople with a statistically justifiable estimate on how hit rate and profitability evolve as opportunity price is increased or decreased. More attributes for a salesperson to tinker with can be included as well.

4. Hit Rate Engine as a Sales Assistant

To fulfil the requirements set by the sales assistant use case, a range of prices has to be fed to the algorithm. The resulting impulse response is a range of hit rates. If the margin is included in the model, it has to be dynamically adjusted as price changes by using a suitable dependency function.

Hit Rate = Model(Price, Margin, Features1-N) + Ɛ

Now that we get the curve of hit rates out by dynamically changing price and margin, it is time to add profitability into the equation. This is fairly straightforward as we already have hit rate and margin calculated for each price level. The formula of expected profit includes probability of winning, corresponding price and margin at this price. This is obviously something that corporations want to maximize.

Expected Profit = Hit Rate * Opportunity Price * Margin

Forecasting accuracy increases along with the number of entered model input features assuming that the underlying statistical model has been produced according to best practices. The behaviour of hit rate and profitability with respect to price can be visualized and embedded as a sales assistant feature in a CRM or CPQ system. Of course, this requires proper usability design to ensure that the complexity of the underlying model is hidden from the salesperson. The model does not have to be trained constantly, so response time is not an issue.


20.08.2018 / Krzysztof Pieszak

Dziś częstym problemem działów marketingu i sprzedaży jest nadmiar informacji nt. klienta i jednocześnie brak dostępu do kompletnego profilu klienta. Handlowiec czy marketer, potrzebowałby widoku, gdzie oprócz podstawowych danych kontaktowych znajdzie informacje sprzedażowe, reklamacje, aktywne kampanie, interakcje pomiędzy firmą a klientem, itp. Powinien on też mieć pewność, że dane te są kompletne, co pozwoli na jak najbardziej spersonalizowaną obsługę i zrozumienie potrzeb klienta.

Dane o klientach mogą pochodzić z różnych źródeł: system ERP, CRM, sklep internetowy, Facebook/ Instagram, aplikacja do obsługi klienta, itp. Skąd marketer może wiedzieć czy dana interakcja z klientem dotyczy naszego aktualnego klienta, czy jest to nowy klient? Oczywiście mając niewielką bazę klientów jesteśmy w stanie rozpoznać nowego, bądź stałego klienta, ale wraz z rozwojem biznesu stanie się to niewykonalne. Dane zalewają nas z każdej strony. Oczywistym jest więc potrzeba narzędzia, które będzie filtrem oraz automatycznie rozpozna interakcję i przypisze ją do istniejącego klienta lub stworzy nowy profil klienta.

*Jeśli to jest dla ciebie również istotne zachęcam do zapoznania się z narzędziem SAP Marketing Cloud (https://cx.sap.com/en/products/marketing ).

W jaki sposób SAP Marketing Cloud przetwarza dane kontaktowe?

SAP Marketing Cloud otrzymując dane z różnych źródeł dąży do stworzenia tak zwanego Złotego Rekordu (ang. Golden Record) – czyli połączenia wszystkich dostępnych danych o kontakcie w jeden rekord.

 

Obraz 1 Złoty Rekord, www.SAP.com

 

Upraszczając całe technikalia, dane kontaktu zawarte są w 3 różnych połączonych tabelach.

  1. Facet -> tabela, w której trzymane są dane pochodzące z różnych źródeł ale dotyczące danego klienta, nieustrukturyzowane,
  2. Facet Data -> jw. ale dane są przypisane do określonych struktur w systemie: adres, telefon, mail, itp., uporządkowane
  3. Golden Record -> tabela, w której trzymane są dane „najbliższe ideałowi”, dane te wybierane są z tabeli Facet Data na podstawie ustawień priorytetu danych w systemie.

Łączenie tabeli zostało przedstawione na przykładzie poniżej.

 

Obraz 2 Proces powstawania kontaktu, www.SAP.com

 

W systemie zdefiniowano różne źródła danych (systemy), a łączenie danych odbywa się w tym przypadku po numerze telefonu (definiujemy bowiem, która dana kontaktowa jest nadrzędna, która unikalna, a która może być współdzielona przez wiele osób (np. telefon stacjonarny)).

System otrzymał nowy wpis z danymi -> ponieważ założono konto klienta w systemie SAP C4C (Cloud CRM), a SAP Marketing Cloud powiązał te dane z już istniejącym rekordem z systemu Commerce i następnie połączył je ze sobą. Powstał jeden pełen kontakt.

Gdy np. otrzymaliśmy pokaźną nową bazę danych o klientach od nowo przejętej spółki, ważne dla nas będzie połączenie tych danych z obecną bazą danych (zakładając, że mamy odpowiednie zgody i uregulowany proces zarządzania danymi osobowymi). Dzięki SAP Marketing Cloud możemy w łatwy sposób zaimportować dane (za pomocą narzędzi integracyjnych, czy plików CSV). System automatycznie sprawdzi w tle pozyskane dane, poszuka odpowiedników w bazie i przypisze nowe wartości. (Wzbogaci) aktualnie posiadane dane o nowe wartości, lub utworzy nowe kontakty.

 

Obraz 3 Wzbogacenie aktualnie posiadanego kontaktu, www.SAP.com

 

System łączy dane bez naszej ingerencji – robi to w sposób zautomatyzowany.

SAP Marketing Cloud dostarcza narzędzia, za pomocą których możemy te dane zweryfikować. Mianowicie dla każdego profilu klienta istnieje zakładka o nazwie „Origin Data”, gdzie widzimy zaznaczony główny profil kontaktu (w żółtej ramce – Rys. 4) oraz dane, które zostały doczytane z innego źródła. W tym miejscu widzimy, które dane wpłynęły na stworzenie głównego rekordu kontaktu w systemie.

 

Obraz 4 Zakładka Origin Data, www.SAP.com

 

W celu głębszej analizy możemy wykorzystać również aplikację „Inspect contact” wyświetlającą dane w postaci tabelarycznej oraz aplikację „Browse Contact Origin Data” prezentującą w zagregowany sposób dane o interakcjach. To pozwala na sprawdzenie poprawności importu danych oraz pomaga przeglądać i zrozumieć posiadane dane (na przykład z jakiego systemu one pochodzą).

 

Obraz 5 Inspect Contact www.SAP.com

 

Obraz 6 Inspect Contact www.SAP.com

 

Co w przypadku kiedy system nie jest w stanie poprawnie zinterpretować danych?

SAP Marketing Cloud jest przygotowany na tę okoliczność. Systemy nie są nieomylne, dlatego SAP opracował narzędzie do automatycznego sprawdzania duplikatów, a w przypadku niejasności użytkownik może sam zdecydować czy dany rekord powinien zostać połączony z innym.

  1. Zaplanowane zadanie identyfikuje duplikaty kontaktów oparte na imionach / nazwiskach, płci, urodzinach, adresach pocztowych, e-mailach i numerach telefonów. Na podobnej zasadzie identyfikowane są potencjalnie zduplikowane kontakty
  2. Użytkownik biznesowy może przejrzeć zidentyfikowane duplikaty wybierając przycisk „For review”

 

Obraz 7 Interpretacja danych przez użytkownika, www.SAP.com

 

Reasumując SAP Marketing Cloud to kompletne narzędzie pozwalające w wygodny, szybki i niezawodny sposób zarządzać danymi kontaktów z wielu źródeł. Jest to istotne szczególnie, gdy sprzedaż odbywa się wielokanałowo , czy też zbieramy dane z wielu aplikacji.

W drugiej części bloga zapoznamy się dokładniej z profilem klienta jaki oferuje SAP Marketing Cloud.


10.08.2018 / Mika Laukkanen

Tekoälyä koskevan kirjoittelun perusteella voisi kuvitella, että projektit ovat pelkkiä menestystarinoita. Pitää vaan rohkeasti kokeilla, pistää data ja tensorflow pyörimään – jossakin pilvessä.

Käytännössä tekoälyprojekteissa on kuitenkin useita haasteita, joiden vuoksi osa projekteista ei koskaan päädy tuotantokäyttöön saakka. Tässäpä siis eräitä tunnettuja ja koeponnistettuja pulmia:

Idea ei toiminutkaan

Yleensä AI-projektit aloitetaan liiketoimintaongelman määrittelyllä, jossa pitäisi verifioida sopivat ideat projektiin. Ja karsia epäkelvot pois. Tästä huolimatta virheitä sattuu, joista muutama esimerkki.

  • Valitaan projektiin sellainen ongelma, joka saadaan teknisesti ratkaistua (esim. ennustemallit toimii), mutta jolla ei ole riittävän suurta liiketoiminnallista merkistystä. Ensimmäistä AI-projektia kokeilevat yritykset kapsahtavat usein tähän kategoriaan. Halutaan tehdä “mahdollisimman varma” projekti, jolloin liiketoiminnallinen merkitsevyys jää muiden seikkojen varjoon.
  • Kukaan ei halua ratkaisua tontilleen AI-projektin jälkeen (omistajuus puuttuu). IT:n vetämät hankkeet ovat tässä riskiryhmää.
  • Etukäteen ei mietitty ovatko ihmiset valmiita ottamaan vastaan esim. algoritmien tekemiä suosituksia tai päätöksiä. Eräässä projektissa ennusteet saava osapuoli totesi aluksi… ettei halua niitä.

 AIkuvaiheessa kannattaa siis käyttää aikaa ja energiaa, että löytyy sopivat aihiot AI-projekteiksi. 

Data olikin kuraa 

Huonosta datasta voisi varmaan kirjoittaa kokonaisen kirjasarjan. Ilmiö on harmillisen tuttu myös AI-projekteissa. Itse asiassa kun mietin, niin vain muutamassa tuntemassani projektissa ei ole ollut suhteellisen olennaisia datan laatuun liittyviä haasteita. Mistä nämä ongelmat sitten johtuvat?

  • Datat on eri tietojärjestelmissä, joista niiden kerääminen voi olla hyvin hankalaa.
  • Data ei välttämättä ole yhteismitallista järjestelmien välillä.
  • Ihmiset tuottavat virheellistä dataa, esim. myyjä syöttää vahingossa väärän tarjouksen arvon.
  • Ihmiset tuottavat harhaista dataa, esim. myyjä yliarvioi liidien määrän.
  • Myös eri tavalla kalibroidut anturit yms. saattavat tuottaa keskenään vertailukelvotonta dataa.
  • Syystä tai toisesta datassa on paljon aukkoja ja puutteita. Eräässä projektissa asiakkaan CRM:ssä oli kattavat tiedot vain alle 5%:lla asiakkaista.
  • Data on summattu tasolle, jossa olennainen informaatio on hävinnyt.
  • Data ei saada yhdisteltyä, koska ei ole yhdistävää tekijää.
  • Ennustettava ilmiö muuttuu sen verran nopeasti, että historiadata ei toimi mallinnuksen pohjana hyvin.
  • AI-projektin kannalta olennaista datan historiaa ei ole tallennettu, vain nykyhetken datat tallessa.

Dataan laatuun liittyvät asiat olisi hyvä käydä tiheällä kammalla lävitse ennen projektin varsinaista aloitusta. Parhaimmillaan se voi säästää pitkän pennin, kun tunnetaan datahaasteet etukäteen tai ei lähdetä projektiin, joka ei datan vuoksi onnistuisi kuitenkaan.

Mainittakoon vielä, että projektien alussa ollaan miltei aina ylioptimismisia datan laadun suhteen.

Dataa olikin oikeasti paljon

Näin big data -ratkaisujen ja pilven aikakaudella voisi kuvitella etteivät isot datat ole mikään ongelma. Yllättävän usein näin kuitenkin näyttää olevan, koska osaamista big data- ja pilviratkaisuista on rajallisesti yrityksissä. Eräs IoT-projektimme jumahti asiakkaan päässä siihen etteivät keksineet miten hallita kustannustehokkaasti 30 Gigan päivittäisiä signaalidatoja.

Myös mallinnuksen kannalta isot datat saattavat olla haaste, kun tarvitaan järeitä GPU-myllyjä laskemaan, ja suoritusajat ovat pitkiä.

Tulosten esittäminen ja kommunikaatio yleensä

AI-projektin eri vaiheissa käydään tuloksia lävitse liiketoiminnan ja Data Scientistien kanssa. Esimerkiksi palaverissa analysoidaan seuraavaa kuvaa.

Data Scientist kertoo analyyseistä, vasteista, inputeista, ennustemalleista, keskivirheistä, ROC-käyrästä ja siitä, että pylvään 1 alempi luku on tilastollisesti merkitsevä verratuna pylvääseen kaksi… Liiketoiminnan vetäjä kuuntelee ja toteaa, että siitä ne näyttää suunnilleen yhtä suurilta. Ja että busineksen kannalta erolla ei ole merkitystä. Game over.

Data Scientistien kannattaakin hioa presentaatio-osaamistaan siten, että tulokset on selitettävissä maallikollekin. Esimerkiksi, kuinka moni ns. tavan tallaaja tietää mikä on vastemuuttuja?

Liiketoiminnan ihmisten taas kannattaisi keskittyä ymmärtämään mistä on kyse. Aina toisinaan näkee melko hätäisesti vedettyjä johtopäätöksiä tuloksista.

Tässäkin asiassa aika varmaan tekee tehtävänsä, eli kun AI-projektit yleistyvät, niin näitä esitettyjä haasteita on aiempaa helpompi taklata.

 


6.08.2018 / Michał Schneck

W dzisiejszych czasach standardem jest praca handlowców w systemach klasy CRM /SFA.

Pytanie tylko na ile taki system pełni funkcję administracyjną w sprzedaży, a na ile w sposób rzeczywisty i proaktywny wspiera handlowców w codziennej pracy. Bo to przecież jest jego wartością.

Jedną z kluczowych aktywności handlowców jest dbanie oraz umacnianie relacji z Klientami.

Nie dziwi więc, że handlowiec większość swojego czasu spędza na wizytach u Klientów.

Co system SFA może zaoferować w tym zakresie?

Przyjrzyjmy się, w jaki sposób SAP Sales Cloud (w skrócie C4Chttps://www.sap.com/poland/products/crm-sales-cloud-software.html ) wpiera Handlowców w planowaniu wizyt. Poznajmy jego kluczowe funkcjonalności oraz podstawową konfigurację.

Planista wizyt – konfiguracja

Pierwszym krokiem jest skonfigurowanie mechanizmu odpowiedzialnego za podpowiadanie wizyt.

W tym celu na Kliencie w zakładce Wizyty ustawiamy zalecaną częstotliwość wizyt dla danego Klienta.

Częstotliwość możemy ustawiać na poziomie: lat, miesięcy, dni.

Po wprowadzeniu reguły system automatycznie na podstawie Terminu ostatniej wizyty podpowie podczas tworzenia nowej wizyty termin następnej (dodając do terminu ostatniej wizyty wskazaną w konfiguracji wizyty częstotliwość).

Drugim sposobem, który wspiera bardziej zaawansowane scenariusze wizyt sprzedażowych, jest używanie parametrów z zakładek „Szczegóły wizyt” oraz „Godziny wizyt”.

W „Szczegółach wizyt” możemy ustalić częstotliwość wizyt per typ wizyty, dział sprzedaży, kanał dystrybucji oraz określić zalecany czas trwania wizyty. To oznacza że dla jednego klienta możemy ustalić różne pożądane częstotliwości wizyt zależnie np. od rodzaju wizyty (np. planowanie roczne co rok, wizyta regularna co miesiąc, itd.).

Zakładka „Godziny wizyt” służy do określenia, w jakich dniach oraz godzinach, możemy planować spotkania z Klientem.  Funkcjonalność przydaje się podczas planowania/tworzenia nowej wizyty. W przypadku, kiedy spotkanie jest planowane w terminie, w którym Klient jest niedostępny, system jeszcze przed utworzeniem rekordu informuje, że wizyta jest niemożliwa w wybranym zakresie czasu.

Konfiguracja Planów

Konfigurator planów to narzędzie, które służy do stworzenia szablonu wizyty dla Handlowców.

Operację wykonuje się przy implementacji systemu, czy też w momencie planowania nowej strategii obsługi klientów czy akcji promocyjnej.

Plan wizyt zawiera listę obowiązkowych oraz zalecanych kroków dla handlowca, które powinny zostać wykonane podczas wizyty handlowej.

Znajdziemy tam listę zadań do wykonania oraz ankiety do przeprowadzenia z Klientem.

Oczywiście to od nas zależy czy dane kroki będą obowiązkowymi czy tylko zalecanymi dla danej wizyty.

 

Przykładowy business case to zbieranie przez handlowców danych o potencjale klientów – w specjalnie zaprojektowanej ankiecie, która automatycznie będzie przypisywana do nowo tworzonych wizyt, handlowcy mogą wprowadzić odpowiednie dane zebrane podczas wywiadu.

 

Konfiguracja Reguł

Po prawidłowym skonfigurowaniu i aktywowaniu planu wizyt możemy przejść do konfiguracji reguł routingu. Są to zasady, które determinują dla jakich klientów lub wizyt nasz plan ma się podpowiedzieć.

W tym celu definiujemy warunki dla naszej reguły. W naszym przypadku polem determinującym uruchomienie naszej reguły będzie pole Branża (=handel detaliczny).

Następnie podpinamy wcześniej stworzony przez nas plan wizyty (lista zadań oraz ankiet do przeprowadzenia).

W tym miejscu możemy przypisać także grupy docelowe, czyli klientów zgrupowanych wg ustalonych wcześniej warunków. To dla nich wskazana reguła będzie działać (czyli przypisywać gotowe plany do ich wizyt).

Po przeprowadzeniu niezbędnych konfiguracji zobaczmy efekt naszych prac.

Planowanie

Planowanie wizyt u klientów może mieć wiele źródeł:

– może to być sam Planista Wizyt, gdzie handlowiec uzyska podpowiedzi do których klientów powinien się udać – z różnych względów,

– może to być wizyta utworzona zaraz po zakończeniu poprzedniej – C4C zawsze pyta nas czy chcemy już zaplanować kolejną,

– może to być również wizyta zaplanowana (a w zasadzie zaproponowana) przez narzędzie analityczne dokonujące segmentacji klientów – czyli np. warto udać się do tego klienta ponieważ odnotowaliśmy u niego spadki sprzedaży.

 

Jeśli chodzi o pierwszą opcję, czyli korzystanie z Planisty Wizyt, widzimy tu na podstawie wcześniej ustawionych kryteriów tych Klientów, z którymi powinniśmy spotkać się w pierwszej kolejności.

Na poniższym ekranie widzimy mapę z Klientami przypisanymi do mojego użytkownika, którzy nie mają zaplanowanych żadnych wizyt na przyszłość.

Producent zaopatrzył użytkownika w kilka predefiniowanych widoków, które powinny wystarczyć do codziennej pracy. Oczywiście dysponujemy też intuicyjnym narzędziem, które pozwoli nam szybko wyfiltrować i stworzyć widoki Klientów na podstawie naszych własnych kryteriów (także opartych na polach nie standardowych, które tu możemy dodać), np. Klientów z zaległymi wizytami, klientów bez opiekuna, klientów z danego obszaru.

W zależności od naszego scenariusza biznesowego. Mamy teraz dwie możliwości. Tworzymy nową wizytę poprzez użycie klawisza funkcyjnego „Nowa wizyta” lub po prostu otwieramy wizytę, którą automatycznie utworzył za nas system.

Na poniższym ekranie widać, że wizyta domyślnie otwiera się już z przypisaną listą zadań oraz ankiet do wykonania. Tymi, które wcześniej zdefiniowaliśmy.

 

Praca handlowca na tablecie

Przyjrzymy się bliżej jak wygląda realizacja naszej Wizyty przez handlowca.

Handlowiec zobaczy zaplanowaną wizytę w kalendarzu w C4C, lub na liście wizyt na dzień bieżący.

Pierwszą czynnością, którą robi handlowiec jest  „zameldowanie się u Klienta” przy użyciu przycisku „Początek”. System automatycznie na tej podstawie pobiera dane lokalizacyjne z GPS (warunek: włączona usługi geolokalizacji w urządzeniu), datę i czas zameldowania. W ten sposób można również weryfikować zbieżność lokalizacji klienta i zaplanowanego terminu z rzeczywistością.

Ekran zadań agreguje listę zadań do wykonania dla Klienta. Warto zwrócić uwagę, że do zadania można podpinać załączniki, np. do zadania „Prezentacja nowych produktów z oferty” w załączniku możemy umieścić prezentację w PowerPoint dla Klienta. Zadania mogą być opcjonalne lub obligatoryjne (bez ich wypełnienia nie zamkniemy wizyty).

Kolejnym ważnym elementem wizyt są Ankiety, czyli zestawy predefiniowanych pytań, dzięki, którym Handlowiec może zebrać kluczowe informacje. Moduł Ankiet pozwala użytkownikowi stworzyć dowolny rodzaj ankiet. W systemie można tworzyć ankiety dotyczące poziomu satysfakcji Klienta, listy kontrolne, czy też ankiety produktowe.

Poniżej widok przykładowej ankiety:

Ankiety C4C wspierają pytania otwarte, jednokrotnego i wielokrotnego wyboru, pola walutowe, procentowe, etc. Ciekawą opcją jest możliwość podpinania pod odpowiedź w ankiecie pliku –  np. do pytania dotyczącego ekspozycji towaru możemy załączyć zdjęcie z naszego urządzenia mobilnego (smartfonu, czy tabletu), które wykonamy w trakcie wizyty w momencie odpowiadania na pytanie tego dotyczące.

Drugą opcją wartą opisania jest opcja dodania produktów do ankiety bezpośrednio podczas wizyty u Klienta, np. w przypadku, kiedy pojawił się nowy produkt i osoba tworząca nie dodała go do ankiety (również przez skanowanie kodu kreskowego).

 

Warto wspomnieć, że ankiety w C4C obsługują także zdarzenia sprzedażowe. Wyobraźmy sobie sytuację, że w ankiecie pojawia się pytanie na temat ilości danego produktu na półce w sklepie. Po wybraniu odpowiedzi, że produktu brak lub stan magazynowy jest niski pojawia się dodatkowe pytanie: „Ile produktu zamówić”. Po wpisaniu wartości automatycznie w tle zostanie wygenerowane zamówienie sprzedaży lub oferta sprzedażowa (w zależności od konfiguracji naszego systemu).

 

Ewaluacja spotkania. Podsumowanie, ankiety – raporty

Na koniec warto wspomnieć o raportowaniu Wizyt oraz Ankiet w C4C. Raportować możemy same wizyty (np. ilość wizyt w okresie na handlowca), lub też ankiety (kiedy interesuje nas zagregowana informacja nt. odpowiedzi z ankiet). Również możliwe jest raportowanie wspólnie tych obiektów.

System umożliwia także eksport wyników ankiety do programu MS Excel lub wygenerowanie raportu podsumowania wizyty do PDFa, który potem można przesłać do Managera.

Poniżej przykładowy screen fragmentu raportu z wizyty przedstawiający dostępność produktów w odwiedzanym sklepie oraz działania marketingowe podjęte w ramach promocji wybranych produktów.