Yli sadassa HubSpot-projektissa toistuu sama havainto.
Yritys ottaa HubSpotin käyttöön, rakentaa pipelinen, lisää automaatioita ja alkaa kerätä dataa. Aluksi kaikki näyttää toimivan. Sitten tulee lisää myyjiä, lisää palveluita, lisää automaatioita. Ja tietenkin AI.
Muutaman vuoden päästä kukaan ei enää täysin luota raportointiin.
Syy ei useinkaan ole HubSpot. Syy on se, miten CRM on rakennettu.
Huono rakenne → huono data → huonot päätökset → menetetty kasvu.
Tämä ketju ei ole teoreettinen. Se on käytännön todellisuus, jonka näemme toistuvasti HubSpot-auditoinneissa. Ja AI tekee siitä entistä kriittisemmän: HubSpotin Breeze-agentit, lead scoring, personointi ja myyntiautomatiikka toimivat vain niin hyvin kuin niiden alla oleva tietomalli.
Tässä artikkelissa käymme läpi sen, mitä hyvä HubSpot-arkkitehtuuri tarkoittaa käytännössä ja miksi se on AI-ajan kasvun edellytys, ei vain tekninen yksityiskohta.
Miksi tietomalli ratkaisee AI-ajan kasvun
Puhutaan paljon AI:sta, agenteista ja automaatioista. Harvemmin puhutaan siitä, mikä tekee niistä toimivia tai toimimattomia.
HubSpotin Smart CRM -malli lähtee siitä, että liiketoimintadata elää yhdessä rakenteessa. Kun kontaktit, yritykset, liidit, kaupat ja asiakkuudet on mallinnettu oikein, AI pystyy tekemään niillä jotain hyödyllistä. Kun rakenne on rikki, AI vain nopeuttaa virhettä.
Kun se ei ole kunnossa, AI monistaa ongelman.
Kolme yleisintä tietomallin hajoamispistettä:
- Lifecycle stages sekaisin: Kontakteilla on väärät tai puuttuvat elinkaarivaiheen tiedot, jolloin segmentointi, nurturing ja raportointi eivät toimi.
- Dealit syntyvät liian aikaisin: Pipeline täyttyy mahdollisuuksista, jotka eivät ole oikeita myyntimahdollisuuksia, ja forecast menettää merkityksensä.
- Asiakasdata katkeaa Closed Woniin: CRM toimii myyntiputkena, mutta asiakkuuden hoito, onboarding ja uudelleenmyynti jäävät sen ulkopuolelle.
Nämä kolme ongelmaa eivät korjaannu ottamalla käyttöön lisää AI-ominaisuuksia. Ne korjaantuvat rakentamalla tietomalli oikein alusta alkaen.
Neljä objektia, jotka kannattaa rakentaa ensin
HubSpotin tietomalli koostuu objekteista: Contact, Company, Lead, Deal, Ticket ja Custom Objects. Kaikilla on oma roolinsa, mutta useimmissa B2B-yrityksissä kannattaa aloittaa neljästä ja rakentaa ne oikein ennen kuin lisätään monimutkaisuutta.
1. Contact Object: suhde, ei tehtävälista
Contact on CRM:n tunnetuin objekti ja samalla yksi väärinymmärretyimmistä.
Contactin tehtävä ei ole kertoa myyjälle, mikä hänen seuraava tehtävänsä on. Sen pitää kuvata kontaktin suhdetta yritykseesi koko asiakkuuden elinkaaren läpi.
Tämä tarkoittaa lifecycle stage -rakenteen rakentamista tarkoituksenmukaisesti:
| Elinkaaren vaihe | Mitä se tarkoittaa |
|---|---|
| Lead | Kiinnostusta on osoitettu, mutta ei vielä kvalifioitu |
| MQL | Markkinoinnin kvalifioima, valmis myynnin arviointiin |
| SQL | Myynti on vahvistanut kaupallisen potentiaalin |
| Opportunity | Aktiivinen myyntiprosessi käynnissä |
| Customer | Kauppa voitettu, asiakkuus alkanut |
| Evangelist | Aktiivinen suosittelija tai referenssi |
Miksi tämä erottelu on tärkeä?
Lifecycle stage ei ole sama asia kuin myyntiputken vaihe. Se kuvaa, kuinka pitkälle ihminen on edennyt kaupallisessa suhteessa yritykseesi. Kun rakenne on kunnossa, CRM alkaa vastata kysymyksiin, jotka oikeasti kiinnostavat: kuinka moni MQL muuttuu SQL:ksi, mistä parhaat asiakkaat tulevat ja missä vaiheessa menetämme potentiaaliset ostajat.
Ilman tätä rakennetta AI-pohjainen segmentointi ja personointi toimivat arvailun varassa.
2. Lead Object: pre-deal-kerros, joka puuttuu useimmista CRM:istä
Tässä moni HubSpot-ympäristö menee pieleen.
Deal luodaan liian aikaisin.
Joku lataa oppaan. Deal. Joku pyytää lisätietoja. Deal. Joku vastaa myyjän sähköpostiin. Deal.
Lopputulos: pipeline näyttää suurelta, mutta merkittävä osa siitä ei ole oikeita myyntimahdollisuuksia. Forecastista tulee toiveiden lista, ei johtamisen työkalu.
Lead Object kannattaa ajatella pre-deal-kerroksena: paikka, jossa myynti käsittelee kiinnostuksen ennen kuin on riittävästi näyttöä aidosta kaupallisesta mahdollisuudesta.
Jos volyymi on riittävä, lead-prosessia kannattaa jäsentää "motionin" mukaan:
- Inbound – he löysivät meidät
- Outbound – me löysimme heidät
- Product-led – he kokeilivat tuotetta
- Partners – joku esitteli meidät
- Events – tapasimme tapahtumassa
Tällä erottelulla on iso käytännön merkitys. Inbound-liidi ja outbound-prospekti eivät ole sama asia. Niillä on erilainen konteksti, erilainen intentio ja usein myös erilainen myyntiprosessi. Kun tämä data on CRM:ssä oikein, AI-pohjainen lead scoring ja hot lead -automatiikka voivat toimia tarkoituksenmukaisesti.
Kaikki kiinnostus ei ole pipelinea. Tämä on yksi tärkeimmistä asioista, jonka CRM-arkkitehtuurissa voi ymmärtää.
3. Deal Object: vain oikeille kaupallisille mahdollisuuksille
Deal kuuluu tilanteeseen, jossa pöydällä on oikeasti mahdollinen kauppa. Ei silloin, kun joku näyttää kiinnostuneelta.
Tällä erolla on valtava vaikutus raportointiin. Jos CRM:ssä on 500 000 euroa pipelinea, johdon pitäisi pystyä luottamaan siihen, että kyse on määriteltyjen kriteerien täyttävistä mahdollisuuksista.
Deal-pipelineja voidaan erotella liiketoiminnan mukaan:
- New Business vs. Upsell vs. Renewal (eri myyntimotiivit ja prosessit)
- Enterprise vs. SMB (eri päätöksentekosyklit ja vastuut)
Mutta tässä kannattaa vastustaa yhtä HubSpotin suurimmista houkutuksista: älä rakenna uutta pipelinea vain siksi, että voit. Jos kahdella kauppatyypillä on käytännössä sama prosessi, niitä voidaan erotella propertyillä ja raportoinnilla.
Pipeline kannattaa erottaa silloin, kun prosessi oikeasti muuttuu.
Yksinkertainen testi:
Muuttuvatko vaiheet, vastuut tai kaupallinen logiikka niin paljon, että prosessia pitää johtaa eri tavalla? Jos eivät, et välttämättä tarvitse uutta pipelinea.
4. Ticket Object: CRM:n aliarvostetuin objekti
Monessa yrityksessä HubSpot rakennetaan markkinoinnille ja myynnille. Sitten kauppa voitetaan ja CRM:n näkyvyys loppuu siihen.
Se on virhe.
Asiakkaan elinkaari ei pääty Closed Woniin. Monessa liiketoiminnassa juuri sen jälkeen alkaa kaikkein tärkein vaihe. Ticket Object mahdollistaa asiakassuhteen jatkuvuuden CRM:ssä:
- Onboarding: Uuden asiakkaan käynnistyminen strukturoituna prosessina
- Support: Palvelupyyntöjen hallinta ja vastausaikojen seuranta
- At-risk: Asiakkuuden riskisignaalien tunnistaminen ennen kuin on liian myöhäistä
Kun Ticket Object on käytössä, voidaan kysyä paljon kiinnostavampia kysymyksiä: millaiset asiakkaat tarvitsevat eniten tukea, mitkä asiakkaat ovat vaarassa lähteä, mitä myynnissä luvattiin ja kuinka nopeasti onboarding valmistuu.
CRM ei ole enää vain paikka, jossa säilytetään kontakteja. Siitä tulee kaupallisen organisaation käyttöjärjestelmä.
Custom Objects: milloin ne oikeasti kannattaa?
Custom Object kuulostaa helposti ratkaisulta kaikkiin erityistapauksiin. Usein se ei ole.
Ennen Custom Objectin käyttöönottoa kannattaa kysyä: pystymmekö mallintamaan tämän Contact-, Company-, Lead-, Deal- tai Ticket-rakenteella? Jos vastaus on kyllä, pitäisin rakenteen yksinkertaisena.
Custom Object kannattaa ottaa käyttöön silloin, kun liiketoiminnassa on aidosti oma entiteetti, jolla on:
- Oma data ja propertyt, joita ei voi järkevästi liittää vakio-objekteihin
- Omat suhteet muihin objekteihin (esim. tuote liittyy useaan dealiin eri tavoin)
- Oma prosessi, jota pitää johtaa itsenäisesti
Tyypillisiä perusteltuja käyttötapauksia:
- Tilaukset tai sopimukset, joilla on oma elinkaarensa kaupan jälkeen
- Projektit tai toimitukset, joita seurataan erillään asiakkuudesta
- Tuotteet tai laitteet, joilla on oma huolto- tai uusintaostohistoriansa
Tekninen hienous ei ole hyvän CRM:n mittari. Hyvä CRM on sellainen, jonka ihmiset ymmärtävät ja jota he oikeasti käyttävät. Custom Objects lisäävät ylläpidon monimutkaisuutta ja voivat tehdä portaalista vaikeaselkoisen uusille käyttäjille, jos niitä lisätään ilman selkeää liiketoimintalogiikkaa.
AI ei korjaa huonoa CRM-arkkitehtuuria, se vahvistaa sen
Tämä on ehkä tärkein muutos juuri nyt, ja silti vähiten puhuttu.
Yritykset haluavat käyttää AI:ta segmentointiin, personointiin, leadien priorisointiin ja myynnin automatisointiin. HubSpotin Breeze-agenttien lupaukset ovat realistisia, mutta niillä on yksi ehdoton edellytys: puhdas, yhdistetty ja tarkoituksenmukaisesti organisoitu data.
Mitä AI tarvitsee toimiakseen
Breeze Prospecting Agent priorisoi liidejä käyttäytymisdatan ja intent-signaalien perusteella. Se toimii vain, jos lifecycle stages ovat oikein ja Lead Object erottelee inboundin ja outboundin toisistaan.
Breeze Customer Agent vastaa asiakaskyselyihin ja ohjaa oikeisiin resursseihin. Se toimii vain, jos Ticket Object on rakennettu niin, että asiakkuuden historia on saatavilla.
Personointi ja segmentointi skaalautuvat vain, jos Contact Object kertoo, missä vaiheessa asiakkuutta ihminen on, ei vain sen, kuka hän on.
Garbage in, AI-powered garbage out.
Miksi tämä on eri asia kuin aiemmat CRM-ongelmat
Aikaisemmin huono CRM-arkkitehtuuri tarkoitti lähinnä, että raportointi oli epäluotettavaa. Se oli ongelma, mutta se ei estänyt myyntiä tekemästä kauppaa.
AI muuttaa tämän. Kun AI-agentit alkavat tehdä päätöksiä, kuten lähettää viestejä, priorisoida liidejä tai käynnistää prosesseja, huono tietomalli ei enää vain vaikuta raportointiin. Se vaikuttaa siihen, mitä asiakkaat kokevat ja miten myynti toimii.
Siksi ennen Breezea, agenteja ja hienoja automaatioita kannattaa kysyä paljon tylsempi kysymys:
Onko CRM:n perusta oikeasti kunnossa?
Cocon RevOps-mallissa tämä on lähtöpiste. Ennen kuin rakennetaan AI-kerroksia, varmistetaan, että tietomalli tukee niitä.
Älä kopioi tätä rakennetta suoraan omaan CRM:ään
Tämä on tärkeä varoitus, joka kannattaa sanoa suoraan.
Neljän objektin malli on hyvä ajattelurunko. Se ei ole valmis HubSpot-template jokaiselle yritykselle.
SaaS-yrityksen CRM-arkkitehtuuri voi näyttää täysin erilaiselta kuin 150 hengen teollisuusyrityksen. Projektibisnes toimii eri tavalla kuin jatkuva palvelu. Enterprise-myynti toimii eri tavalla kuin transaktionaalinen myynti.
CRM pitää rakentaa sen ympärille, miten yritys oikeasti toimii, ei pakottaa yritystä toimimaan CRM:n ympärillä.
Siksi hyvä HubSpot-arkkitehtuuri alkaa yleensä vähemmän teknologiasta ja enemmän kysymyksistä:
- Miten liidi syntyy ja kuka ottaa vastuun?
- Milloin syntyy oikea kaupallinen mahdollisuus?
- Mitä pitää tapahtua ennen tarjousta?
- Mitä tapahtuu Closed Wonin jälkeen?
- Mitä johdon pitää pystyä mittaamaan?
Vasta näiden kysymysten jälkeen rakennetaan objektit, propertyt, pipelinet ja automaatiot.
Yksi sääntö kannattaa muistaa
Pidä CRM niin yksinkertaisena kuin mahdollista, mutta niin rakenteisena kuin liiketoiminta vaatii.
Ensin Contact. Sitten Lead. Sitten Deal. Sitten Ticket. Ja vasta kun nämä eivät enää riitä, Custom Objects.
Koska lopulta HubSpot-arkkitehtuurin tarkoitus ei ole näyttää hienolta HubSpotissa. Sen tarkoitus on auttaa ihmisiä tekemään parempia päätöksiä.
Parempi rakenne → parempi data → paremmat päätökset → parempi kasvu.
Haluatko tietää, onko teidän HubSpot rakennettu kasvua varten?
Coco maksuton HubSpot-portaalin check selvittää HubSpot-portaalinne tietomallit: objektit, lifecycle staget, pipelinet, datan laadun ja automaatiot. Lopputuloksena on selkeä kuva siitä, mikä toimii, mikä ei ja mitä kannattaa korjata ennen seuraavan AI-kerroksen rakentamista. Puhumme kitkakartasta, jonka teemme 48 tunnissa.
Tämä sopii suoraan Cocon Audit → Sprint → Active -malliin: tunnistetaan ensin kasvun esteet, sitten toteutetaan korjaus 90 päivässä, sitten optimoidaan jatkuvasti.
Tutustu Coco Auditiin tai varaa maksuton 30 minuutin sparraus Jounin kanssa, jos haluat ensin katsoa yhdessä, missä teidän CRM-arkkitehtuuri tällä hetkellä on.
Jouni Koistinen on Coco Investin digistrategi, joka auttaa B2B-yrityksiä rakentamaan AI-aikakauden kasvujärjestelmän. Hän on yhdistänyt yli 100 HubSpot-portaalin toteutuskokemuksen ja AI-näkyvyyden strategian yhdeksi käytännön kasvumalliksi - Coco Growth Framework™.
Jounin teesit: kasvua ei rakenneta irrallisilla teknologiaprojekteilla, vaan yhdistämällä näkyvyys, data, prosessi ja AI-agentit yhdeksi mitattavaksi järjestelmäksi.