HubSpot-käyttöönotosta puhutaan usein liian siististi. Dioissa kaikki näyttää loogiselta: prosessit määritellään, data siivotaan, automaatiot rakennetaan ja tiimit alkavat käyttää järjestelmää. Todellisuudessa käyttöönotto ei etene näin suoraviivaisesti.
Onnistunut vaiheittainen käyttöönotto tuo nopeasti näkyviä hyötyjä. Samalla se paljastaa lähes aina myös sen, missä yrityksen myynti, markkinointi ja asiakaspalvelu ovat tähän asti toimineet enemmän ihmisten muistin kuin yhteisen mallin varassa.
Siksi hyvä käyttöönotto ei ole vain tekninen projekti. Se on yhdistelmä prosessien selkeyttämistä, datan korjaamista, päätöksiä omistajuuksista ja valmennusta, joka tekee HubSpotista oikeasti käyttökelpoisen arjessa.
Tässä artikkelissa käyn läpi, mitä asiakkaan kannattaa muistaa ennen projektia, missä onnistumisia tulee yleensä nopeasti ja missä taas on lupa odottaa enemmän työtä kuin aluksi ajattelit.
Yksi yleisimmistä virheistä on ajatella, että uusi järjestelmä pakottaa prosessit kuntoon. Käytännössä käy usein päinvastoin. HubSpot tekee näkyväksi sen, mitä ei ole päätetty.
Jos esimerkiksi nämä asiat ovat vielä auki, ne eivät pysy käyttöönotossa piilossa:
HubSpot kyllä tukee hyvää mallia, mutta se ei keksi sitä puolestasi. Siksi ensimmäinen onnistuminen ei yleensä ole automaatio tai dashboard. Ensimmäinen onnistuminen on se, että yritys joutuu vihdoin sopimaan yhteiset pelisäännöt.
Jos projekti alkaa kysymyksellä “mitä kaikkea HubSpotilla voi tehdä”, lopputulos karkaa helposti liian laajaksi. Parempi aloitus on tämä:
Kun tavoite on selvä, myös toteutus pysyy kurissa. Muuten käyttöönotto paisuu helposti listaksi ominaisuuksia, joista osa jää käytännössä hyödyntämättä.
Moni organisaatio yrittää tehdä ensimmäisessä vaiheessa liian paljon: migraation, integraatiot, raportoinnin, automaatiot, sisältörakenteet, lead scoringin, käyttöoikeusmallit ja AI-toiminnot samassa projektissa.
Tämä kuulostaa tehokkaalta, mutta käytännössä se lisää riskiä. Kun liian moni asia muuttuu yhtä aikaa, kukaan ei enää erota mikä toimii, mikä ei ja miksi.
Parempi tapa on rakentaa olennaiset ominaisuudet ensin ja skaalata vähitellen. Käytännössä tämä tarkoittaa usein sitä, että ensimmäisessä vaiheessa kuntoon laitetaan:
Tämä tuntuu joskus vaatimattomalta. Todellisuudessa se on usein nopein tie tuloksiin.
HubSpotin käyttöönoton kitka ei useimmiten synny käyttöliittymästä. Se syntyy datasta.
Jos vanhassa järjestelmässä on duplikaatteja, puuttuvia kenttiä, epäselviä omistajuuksia, vanhoja vaiheita tai sekalaisia nimeämiskäytäntöjä, ongelmat siirtyvät uuteen ympäristöön hyvin nopeasti. Uusi järjestelmä ei tee huonosta datasta hyvää dataa vain sillä, että se on uusi.
Siksi yksi tärkeimmistä ennakkokysymyksistä on tämä: mitä dataa oikeasti tarvitaan päivittäiseen johtamiseen ja työn tekemiseen?
Kaikkea dataa ei tarvitse pelastaa. Usein paras päätös on jättää osa historiasta migraation ulkopuolelle, jos sen laatu on heikko eikä sille ole käytännön käyttöä.
Moni käyttöönotto hidastuu, koska projektissa ei ole selkeää omistajaa. IT voi olla mukana, johto hyväksyy hankinnan ja kumppani rakentaa toteutuksen, mutta liiketoiminnan arjen omistajuus jää epäselväksi.
Hyvässä projektissa tiedetään ainakin nämä:
Jos omistajuus puuttuu, järjestelmä kyllä valmistuu. Käyttö ei välttämättä valmistu.
Kaikki käyttöönotossa ei ole raskasta. Tietyt asiat tuovat hyötyjä usein yllättävän nopeasti, kun perusta on järkevä.
Jo melko yksinkertainen toteutus tuo nopeasti paremman näkymän siihen, mitä myynnissä tapahtuu.
Kun kontaktit, yritykset ja kaupat kirjataan yhteiseen malliin, johto näkee nopeammin esimerkiksi:
Tämä ei vielä tarkoita täydellistä raportointia. Mutta se tuo pois mutusta johtamisesta.
Yksi nopeimmista hyödyistä tulee yleensä pienistä automaatioista, ei isoista orkestroinneista.
Esimerkiksi seuraavat asiat tuovat usein nopeasti helpotusta arkeen:
Tällaiset ratkaisut eivät ehkä kuulosta näyttäviltä. Silti ne parantavat usein arkea enemmän kuin monimutkainen automaatio, jota kukaan ei lopulta uskalla muokata.
Tämä on aliarvostettu hyöty. Kun käyttöönottoprojektissa määritellään vaiheet, kentät, omistajuudet ja raportit, organisaatio saa samalla yhteisen kielen.
Yhtäkkiä “SQL”, “aktiivinen opportunity”, “hävitty kauppa” tai “markkinoinnin luovuttama liidi” eivät enää tarkoita eri ihmisille eri asioita.
Tämä näkyy nopeasti parempina keskusteluina myynnin, markkinoinnin ja johdon välillä.
Tämä kohta kannattaa sanoa suoraan: kitka ei tarkoita epäonnistumista. Se tarkoittaa yleensä sitä, että projekti koskee oikeita arjen ongelmia.
Usein vaikein osa ei ole järjestelmän rakentaminen vaan se, että ihmiset muuttavat omaa tapaansa tehdä työtä.
Jos myyjät ovat tottuneet pitämään asiat muistissaan, omissa tiedostoissaan tai sähköpostissa, uuden kirjaamiskurin omaksuminen ei tapahdu yhdellä koulutuksella. Sama koskee markkinointia, asiakaspalvelua ja johtoa.
Tässä kohtaa kannattaa varautua siihen, että valmennusta tarvitaan enemmän kuin aluksi arvioitiin. Käyttöönotto ei ole yksi kickoff ja yksi loppukoulutus. Se on toistoa, esimerkkejä, johtamisen tukea ja välillä myös vaikeita keskusteluja siitä, mitä uusi toimintamalli oikeasti vaatii.
Data näyttää paperilla usein siistimmältä kuin se on. Kenttiä on yhdistetty vuosien varrella, merkintätavat vaihtelevat, asiakkuudet ovat eri paikoissa ja historiadataa on enemmän kuin kukaan muistaa.
Siksi migraatioon liittyy lähes aina yllätyksiä:
Jos migraatio sujuu täysin ilman hankalia päätöksiä, se on poikkeus.
Integraatioita ajatellaan usein teknisenä työnä. Käytännössä ne paljastavat nopeasti, etteivät järjestelmät olekaan sopineet samoista käsitteistä.
Kun HubSpot yhdistetään ERP:hen, laskutukseen, verkkokauppaan tai asiakaspalvelutyökaluun, vastaan tulee nopeasti kysymyksiä kuten:
Tekninen yhdistäminen on usein helpompi osa. Vaikeampi osa on päättää pelisäännöt datan liikkumiselle.
Moni odottaa, että käyttöönoton lopussa raportointi on kerralla valmis. Harvoin on.
Ensimmäiset dashboardit ovat yleensä hyödyllisiä mutta epätäydellisiä. Kun tiimi alkaa käyttää järjestelmää oikeasti, huomataan nopeasti:
Tämä on normaalia. Raportointi ei ole projektin lopputuote vaan johtamisen työkalu, joka tarkentuu käytön mukana.
Tämä on hyvä sanoa ääneen nyt, kun AI kiinnostaa lähes kaikkia. HubSpotin AI-toiminnot voivat tuoda paljon hyötyä, mutta ne eivät korjaa rikkinäistä perustaa.
Jos data on sekavaa, vaiheet epäselviä, käyttöoikeudet sattumanvaraisia ja prosessi puoliksi sopimatta, AI vain kiihdyttää epäselvyyttä.
Siksi AI kannattaa ottaa käyttöön vasta silloin, kun ainakin nämä ovat kunnossa:
Toisin sanoen: AI skaalautuu vain niin hyvin kuin CRM:n perusta kestää.
Hyvä käyttöönotto ei tarkoita sitä, että kaikki on täydellistä heti. Parempi tavoite on tämä:
Jos nämä toteutuvat, käyttöönotto on jo hyvällä tasolla, vaikka kaikkea ei olisi vielä rakennettu.
Jos haluat tehdä käyttöönotosta helpomman ja hyödyllisemmän, tee nämä viisi asiaa ennen projektin käynnistystä:
Voit käyttää tätä listaa sisäisessä valmistelussa ennen projektin alkua tai kickoffin jälkeen. Jos useampaan kohtaan vastataan epäröiden, se ei ole ongelma. Se kertoo vain, mihin keskusteluun kannattaa palata ennen kuin rakentaminen etenee liian pitkälle.
Jos pystytte vastaamaan valtaosaan yllä olevista kohdista selkeästi kyllä, käyttöönoton perusta on yleensä hyvällä tasolla.
Jos taas monessa kohdassa vastaus on “ehkä”, “osittain” tai “tästä ei ole vielä sovittu”, se ei tarkoita että projekti pitäisi pysäyttää. Se tarkoittaa, että juuri nämä asiat kannattaa nostaa näkyvästi kickoffiin ja ensimmäisiin työpajoihin.
HubSpot-käyttöönotto onnistuu harvoin siksi, että projekti olisi ollut helppo. Se onnistuu silloin, kun vaikeat asiat tehdään näkyviksi riittävän aikaisin.
Parhaissa projekteissa syntyy nopeasti näkyviä voittoja: parempi näkyvyys, vähemmän manuaalista työtä ja yhteinen toimintamalli. Samalla tulee vastaan myös ne kohdat, joissa organisaation pitää tehdä oikeita päätöksiä datasta, prosesseista ja vastuista.
Se on normaalia. Ja usein juuri se tekee käyttöönotosta hyödyllisen.