CRM-järjestelmä rakennus- ja teollisuusalalle – 4 vaatimusta urakkamyyntiin
Rakennus- ja teollisuusalan CRM-järjestelmältä vaaditaan eri asioita kuin tavalliselta myynnin CRM:ltä. Tarjous voi sisältää materiaalit, työtunnit, matkat, aliurakoinnin ja projektikohtaisen katteen, ja kaupasta toimitukseen voi kulua kuukausia. Jos tarjouslaskenta on Excelissä ja asiakashistoria sähköposteissa, CRM ei vielä ratkaise varsinaista ongelmaa.
Pelkkä yleiskäyttöisen CRM:n käyttöönotto ei yleensä korjaa tätä. Vakio-CRM seuraa hyvin kontakteja, aktiviteetteja ja myyntimahdollisuuksia, mutta urakkamyynnin tarjouslaskenta, projektikohtainen hinnoittelu ja toimitukseen siirtyminen vaativat usein oman prosessin.
Millainen CRM-järjestelmä sopii rakennus- ja teollisuusalalle?
Rakennusalan CRM:n ja teollisuuden CRM:n ero tavalliseen myynnin järjestelmään syntyy siitä, että myytävä asia lasketaan joka kerta erikseen ja toimitetaan kuukausia myöhemmin. Hyvä urakkamyynnin CRM yhdistää vähintään nämä neljä asiaa:
- Tarjouslaskenta — hinta syntyy järjestelmässä, ei erillisessä Excelissä.
- Yritys- ja yhteyshenkilöhistoria — asiakas tunnistetaan Y-tunnuksesta, ei sähköpostiosoitteesta.
- Automaattinen tarjousseuranta — muistuttaminen ei ole myyjän muistin varassa.
- Myynnin ja toimituksen välinen tiedonkulku — sama tapaus jatkuu kaupasta työmaalle.
Alla jokainen näistä erikseen: mitä se tarkoittaa käytännössä ja mitä sen puuttuminen maksaa.
1. Tarjouslaskenta osaksi CRM-järjestelmää
Urakkamyynnissä hinta ei ole listahinta. Se on tarvikkeet, työ, matka, kate ja alv — ja jokainen niistä muuttuu kohteen mukaan. Käytännössä lähes jokaisessa alan yrityksessä tämä lasketaan erillisessä Excelissä, joka on yhden ihmisen koneella ja jonka kaavoja kukaan muu ei uskalla koskea.
Seuraukset ovat ennustettavia: kaksi myyjää antaa samasta kohteesta eri hinnan, vanha versio tiedostosta lähtee asiakkaalle, ja kun laskija on lomalla, tarjoukset seisovat.
Vaatimus järjestelmälle: hinnan pitää syntyä samasta laskurista jokaiselle myyjälle, ja tarjouksen pitää tallentua sinne mistä se lähetettiin. Ei erillistä tiedostoa, ei rinnakkaista totuutta.
Tässä kulkee myös se raja jonka yli tekoälyä ei kannata päästää: hinta lasketaan koodilla ja säännöillä, ei kielimallilla. Siitä lisää alempana.
2. Y-tunnus yritysasiakkaan tunnisteeksi
Kuluttajamyynnissä asiakas tunnistetaan sähköpostista. Urakkamyynnissä se ei toimi: sama yritys ottaa yhteyttä kolmen eri henkilön osoitteesta, työnjohtaja vaihtuu kesken projektin, ja aliurakoitsijoilla on usein yhteinen postilaatikko.
Jos järjestelmä tunnistaa asiakkaan sähköpostista, sama yritys päätyy kantaan kolmena eri kontaktina — ja tarjoushistoria hajoaa niiden välille. Silloin kukaan ei näe että samalle yritykselle on jo tarjottu kaksi kertaa tänä vuonna.
Vaatimus: yritys tunnistetaan Y-tunnuksesta ja henkilöt kiinnittyvät siihen. Se on myös ainoa tapa saada rikastus toimimaan — toimiala, koko ja taloustiedot haetaan Y-tunnuksella, ei nimellä.
3. Automaattinen tarjousseuranta pitkään myyntisykliin
Rakennushankkeessa tarjouksesta päätökseen voi kulua kuukausia. Se on liian pitkä aika ihmisen muistille, ja juuri siksi kauppoja häviää syystä joka ei näy missään raportissa: kukaan ei soittanut perään.
Automaattisen tarjousseurannan ei tarvitse olla monimutkainen. Olennaista ei ole muistutusten määrä vaan kaksi sääntöä:
- Vastaus pysäyttää kadenssin. Jos asiakas vastaa, automaatio lopettaa välittömästi ja tapaus siirtyy ihmiselle.
- Yksi viesti per ajo. Jos putki on ollut seisahduksissa, se ei saa lähettää kuutta viestiä kerralla kiinni kuroakseen.
Jälkimmäinen kuulostaa itsestäänselvältä, mutta se on juuri se bugi joka syntyy jokaiseen ensimmäiseen versioon.
Periaate on että automaatio lämmittää ja ihminen klousaa. Kone hoitaa muistamisen, ihminen hoitaa neuvottelun. Jos rajaa siirtää, asiakas huomaa sen heti.
4. CRM:n pitää yhdistää myynti ja työmaa
Rakennus- ja teollisuusalalla kauppa ei pääty allekirjoitukseen, vaan siitä alkaa toimitus: mittaus, aikataulu, asennus, luovutus. Jos CRM päättyy siihen kun tarjous hyväksytään, tieto siirretään käsin toiseen järjestelmään tai WhatsApp-ryhmään — ja siinä siirrossa katoaa se mitä asiakkaalle luvattiin myyntivaiheessa.
Vaatimus: sama tapaus jatkuu myynnistä toimitukseen. Ei uutta tietuetta, ei uudelleensyöttöä.
Miltä rakennusalan myynnin prosessi näyttää päästä päähän
Kun neljä edellä olevaa kohtaa ovat kunnossa, rakennusalan tarjousprosessi kulkee yhtenä ketjuna eikä katkea järjestelmien väliin:

- Tarjouspyyntö saapuu sähköpostilla, lomakkeelta tai puhelimesta.
- Yrityksen tunnistus Y-tunnuksella — onko tämä jo asiakas, onko sille tarjottu aiemmin.
- Yritystietojen rikastus: toimiala, koko, taloustiedot automaattisesti.
- Tarjouslaskenta järjestelmän omalla laskurilla — materiaalit, työ, matka, kate, alv.
- Tarjous asiakkaalle ja sama tarjous tallennettuna asiakkaan historiaan.
- Automaattinen tarjousseuranta kunnes asiakas vastaa.
- Hyväksytty tarjous muuttuu työmääräimeksi ilman uudelleensyöttöä.
- Asennus ja luovutus — ja tieto siitä mitä myyntivaiheessa luvattiin kulkee mukana.
Yksikään vaihe ei vaadi uutta järjestelmää. Ne vaativat että vaiheet ovat kiinni toisissaan.
Mitä huono tarjousprosessi maksaa?
Rakennusalan (TOL 41–43) laskennallinen työn kustannus on noin 45 € tunnilta. Jos yksi työntekijä käyttää tarjoushallintaan, tietojen uudelleensyöttöön ja tarjousten perään muistamiseen viisi tuntia viikossa:
5 h × 45 € × 48 viikkoa = 10 800 € vuodessa.
Kahdella tunnilla viikossa kustannus on noin 4 300 €. Kymmenellä tunnilla se on jo yli 21 000 €. Laske oma lukusi — olennaista on että se on jonkun palkkaa, ei tehotonta työtä joka näkyisi jossain raportissa.
Menetetyt kaupat ovat vaikeampia laskea, koska ne eivät näy missään. Juuri se tekee niistä kalliita.
Esimerkki: yritystietojen automaattinen rikastus PRH:sta
Rakensimme liidien rikastuksen hakemalla yritystiedot PRH:n avoimesta rajapinnasta Y-tunnuksella. Ensimmäinen versio haki niin nopeasti kuin ehti. Testasimme sadalla Y-tunnuksella:
| Kutsuväli | Löytyneet yritykset |
|---|---|
| 0,15 s | 18 / 100 |
| 1,2 s | 99 / 100 |
Vika ei ollut datassa. PRH kuristaa nopeat kutsut palauttamalla HTTP 200:n ja tyhjän listan — ei virhettä, ei 429:ää. Automaatio luuli tehneensä työnsä ja merkitsi 82 yritystä tuntemattomaksi.
Siksi järjestelmää tai integraatiota valitessa kannattaa kysyä toimittajalta, mitä tapahtuu kun ulkoinen rajapinta ei vastaa — ei sitä, mitä tapahtuu kun kaikki toimii. Virhe joka näyttää onnistumiselta on aina kalliimpi kuin virhe joka kaatuu.
Voiko tekoäly hoitaa tarjouslaskennan ja tarjousseurannan?
Osan kyllä, osan ei — ja raja kannattaa tietää ennen kuin ostaa. Tekoäly on urakkamyynnissä hyvä kaikessa missä käsitellään kieltä ja huonoin siinä missä käsitellään rahaa.
Tekoäly hoitaa hyvin:
- saapuvan tarjouspyynnön lukemisen ja luokittelun
- viestien ja tarjouksen saatteen kirjoittamisen
- yhteenvedon siitä mitä asiakkaan kanssa on sovittu
- muistutusten ajoituksen ja sen tunnistamisen että asiakas vastasi
- yritystietojen tulkinnan rikastuksen jälkeen
Tekoäly ei saa hoitaa:
- Hinnan laskemista. Kielimalli tuottaa uskottavan näköisen luvun joka on väärä, eikä virhe näy mistään ennen kuin kate on menetetty. Hinta lasketaan koodilla ja säännöillä — samalla laskurilla joka kerta.
- Päätöstä alennuksesta tai aikataulusta. Ne ovat neuvottelua, eivät tekstintuotantoa.
Käytännössä tämä tarkoittaa AI-kerrosta olemassa olevan CRM:n päälle: tekoäly lukee, kirjoittaa ja muistaa, mutta laskenta ja säännöt pysyvät järjestelmässä. Automaatio lämmittää, ihminen klousaa — ja hinnan laskee laskuri.
Pitääkö nykyinen CRM vaihtaa?
Useimmiten ei.
Jos yrityksellä on jo Dynamics 365, HubSpot, Salesforce, Pipedrive tai muu CRM, järkevämpää on yleensä rakentaa puuttuva tarjous- ja automaatiokerros nykyisen järjestelmän päälle. Tiedot pysyvät siellä missä ne jo ovat, käyttäjien ei tarvitse opetella uutta, eikä historiaa jouduta siirtämään.
CRM kannattaa vaihtaa vasta jos nykyinen järjestelmä estää jonkin näistä:
- yritys- ja projektirakenteen mallintamisen
- tarjouslaskennan automatisoinnin
- integraatiot muihin järjestelmiin
- myynnin ja toimituksen yhteisen prosessin
Mistä rakennusalan CRM-projekti kannattaa aloittaa?
Järjestystä kannattaa noudattaa, koska jokainen vaihe tekee seuraavasta halvemman:
- Yksi paikka tarjouksille. Ennen automaatiota pitää tietää mitä on tarjottu ja kenelle.
- Y-tunnus avaimeksi. Ilman tätä rikastus ja historia eivät toimi.
- Laskuri järjestelmään. Sama hinta jokaiselta myyjältä.
- Automaattinen tarjousseuranta. Vasta kun kolme edellistä on kunnossa — muuten automaatio monistaa sekaannusta.
Lue lisää: CRM-järjestelmä ja automaatio.
Onko teillä tarjouslaskenta Excelissä?
Tai tarjousten seuranta myyjien muistin varassa?
Kerro meille mitä CRM:ää tai toiminnanohjausjärjestelmää käytätte. Katsomme, mitkä tämän sivun neljästä kohdasta voidaan rakentaa nykyisen järjestelmän päälle ilman että CRM:ää vaihdetaan.
