Mikä on myyntikonfiguraattori? (Ja miksi se ei ole pelkästään tarjoustyökalu)

Jokaisessa monimutkaisia laitteita myyvässä yrityksessä on oma sankarinsa. Hän tuntee tuotteen läpikotaisin. Hän osaa kääntää sekavan asiakastarpeen selkeäksi, valmistettavaksi ratkaisuksi, kun muut vielä availevat Excel-taulukoita. Hän on sankari, mutta hän on myös yksikaistainen silta ruuhkaisella moottoritiellä.

Muistan erään globaalin projektin, jossa jokainen iso tarjous jonotti yhden asiantuntijan tarkastukseen. Kaupat seisoivat. Hyväksynnät kasautuivat. Tuotehallinta aneli myyntiä lopettamaan poikkeustapausten myymisen. Työkaluissa ei ollut vikaa, mutta liikenteenohjaus petti.

Kun kasvu on yhden ihmisen aivojen varassa, teillä ei ole myyntiprosessia. Teillä on nimetty pullonkaula.

Emme tarvitse isompaa laskinta, vaan tulkin.

Useimmat tiimit olettavat, että ratkaisu on massiivinen CPQ-projekti, johon koodataan jokainen sääntö. Se kuulostaa turvalliselta. Yleensä siitä tulee hidas, kallis ja hauras. Sääntöjen poikkeuksia mallinnetaan kuukausia, ja sitten huomataan, että kentällä on jo keksitty uusia.

Todellinen ongelma ei ole tarjouksen matematiikka, vaan asiakkaan tilanteen kääntäminen toimivaksi kokonaisuudeksi. Asiantuntija ei "laske" itselleen oikeaa lopputulosta. Hän kuuntelee, jäsentää ongelman, esittää kaksi olennaista kysymystä ja karsii huonot vaihtoehdot pois heti alkuun. Hän tulkkaa tarpeen rakenteeksi.

Olemme rakentaneet parempia laskimia, kun olisimme tarvinneet älykkäämpiä tulkkeja.

CPQ:ssa ei ole kyse automaatiosta, vaan oikeellisuudesta.

Oikeellisuus tarkoittaa, että myyty tuote voidaan joka kerta valmistaa, hinnoitella ja toimittaa. Nopein tapa menettää uskottavuus on automatisoida sekaannus. Nopein tapa voittaa se takaisin on tehdä monimutkaisesta ymmärrettävää.

Mitä moderni myynnin konfiguraattori oikeasti tekee

Myynnin konfiguraattori on ohjattu myyntijärjestelmä. Se muuttaa keskustelun asiakkaan ongelmasta valmistettavaksi ratkaisuksi, jonka voi hinnoitella ja toimittaa. Se piilottaa monimutkaisuuden ja tekee tuotevalikoimasta selattavan myös muille kuin syväosaajille. Ajattele sitä navigaattorina, ei karttakirjana. Kerrot, minne asiakas haluaa, ja se opastaa sinut perille toimivia reittejä pitkin umpikujia välttäen.

Tässä on se muutos. Sääntöjen syöttämisestä merkityksen luomiseen. Lomakkeista dialogiin. Riippuvuudesta yhdestä asiantuntijasta järjestelmään, joka auttaa kaikkia ajattelemaan kuin asiantuntija.

Jos järjestelmä ei osaa selittää toimintaansa, siihen ei luoteta.

Myyjät tarvitsevat muutakin kuin vastauksia. He tarvitsevat varmuutta. Konfiguraattorin tulee näyttää, miksi jokin valinta on sallittu, mitkä rajoitteet siihen vaikuttavat ja mitä vaihtoehtoja on olemassa. Selitettävyys ei ole ominaisuus. Se on tapa ansaita käyttäjien luottamus.

Suunnitteluperiaatteet, jotka oikeasti toimivat

1. Keskustelu edellä. Aloita siitä, miten asiakkaat kuvailevat ongelmaansa. Järjestelmän tulee esittää tarkentavia kysymyksiä asiantuntijan tavoin. Ei 80 kentän lomakkeita. Kysy vähemmän, tarkoita enemmän.

2. Varmista oikeellisuus rakenteella. Lopputuloksen on oltava aina kelvollinen. Ei joskus. Ei suunnittelun tarkastuksen jälkeen. Aina. Jos järjestelmä ei voi taata tätä, se on demo, ei tuotantojärjestelmä.

3. Selitä miksi. Jokaisen suosituksen ja rajoituksen perustelun on oltava näkyvillä ja ytimekäs. Jos sääntöä ei voi selittää selkeästi, sääntö on ongelma.

4. Tee ylläpidosta ykkösvaatimus. Uudet variantit, uudet markkinat, uudet säädökset. Jos mallin päivittäminen vaatii projektisuunnitelman, kenttäväki kiertää sen.

Tulkki-arkkitehtuuri

Mekanismi on hybridi. Se yhdistää kaksi vahvuutta, jotka yksinään ovat riittämättömiä:

• Keskusteleva tekoäly, joka ymmärtää tarkoituksen, esittää seuraavaksi parhaan kysymyksen ja selittää kompromissit selkokielellä.
• Deterministinen sääntömoottori, joka validoi ja kokoaa konfiguraation niin, että lopputulos on aina oikea ja valmistettavissa.

Tekoäly ilman rajoja tuottaa sujuvia arvauksia. Sääntömoottori ilman keskustelua hukuttaa käyttäjän kenttiin. Yhdessä saadaan joustavuutta alkuun ja luotettavuutta loppuun.

Tekoäly ei korvaa logiikkaa. Se on riippuvainen siitä.

Käytännössä prosessi etenee näin:

• Myyjä aloittaa asiakkaan tilanteesta, ei osanumeroista. "Tarvitsemme kuljettimen, joka siirtää 80 kilon laatikoita 24 metrin matkan matalassa tilassa."
• Järjestelmä esittää seuraavaksi tärkeimmän kysymyksen. "Jaksottaiseen vai jatkuvaan käyttöön? Onko pesuvaatimuksia?" Se rajaa vaihtoehtoja asiantuntijan tavoin.
• Taustalla sääntömoottori karsii mahdottomat polut. Kuorma suhteessa moottoriin, ympäristö materiaaleihin, standardit alueeseen. Vain toimivat vaihtoehdot jäävät jäljelle.
• Käyttöliittymä mukautuu. Jotkut pitävät chat-maisesta etenemisestä. Toiset haluavat ohjatun lomakkeen, joka ilmestyy tarpeen mukaan. Osa taas haluaa tuotekatalogin, jossa on turvakaiteet. Kaikki tiet vievät validiin konfiguraatioon.
• Kun ratkaisu on valmis, hinnoittelu, dokumentaatio ja hyväksynnät syntyvät samasta mallista. Tietoja ei tarvitse syöttää uudelleen. Mitään ei tarvitse "tarkistaa suunnittelusta".

Tarkoitus ei ole repiä vanhaa pois ja korvata sitä uudella. Monissa vetämissäni hankkeissa "tulkki" toimii ohjaavana kerroksena varsinaisen CPQ-järjestelmän edessä. Se syöttää tietoa hinnoittelumoottorille tai olemassa olevalle CPQ-järjestelmälle, samalla kun tuotteen oikeellisuus varmistetaan jo aiemmin. ERP-järjestelmät, kuten SAP, voivat edelleen hoitaa tuotannon osaluettelot. Tulkki omistaa myynnin kerroksen.

Käyttöönoton on oltava nopea. Kaikkea ei tarvitse koodata vuoden projektina. Aloita modulaarisella rakenteella, joka vastaa sitä, miten tuotetta valmistetaan ja myydään. Tekoäly voi auttaa rakenteiden ja sääntöjen luonnostelussa. Ihminen hyväksyy ja testaa ne. Ajan myötä mallia laajennetaan sitä mukaa, kun oikeat kaupat opettavat, mihin tarvitaan lisää yksityiskohtia. Edistyminen on tärkeämpää kuin täydellisyys.

Ylläpidon osalta vastuu kuuluu substanssiosaajille, ei vain devaajille. Pidä säännöt modulaarisina ja testattavina. Jos logiikkasi on lankakerä, tämän päivän nopeus on huomisen vero.

Eikö tämä ole vain CPQ, jonka päälle on liimattu chat?

Se on reilu kysymys. Chatbotin liimaaminen hauraan sääntöviidakon päälle ei muuta mitään. Ero on arkkitehtuurissa. Keskustelu ei ole vain pintaa, vaan ensisijainen tapa ymmärtää tarve. Logiikka ei ole piilossa, vaan se on selkeää, determinististä ja selitettävissä. Siksi järjestelmä opettaa myyjiä ajattelemaan, ei vain klikkailemaan.

Tämä lähestymistapa myös pienentää riskiä. Voit aloittaa "tulkilta", joka toimii CPQ-järjestelmän edessä. Tai se voi toimia itsenäisenä konfigurointimoottorina, jos hinnoittelu on yksinkertaista. Esimerkiksi Sailsrepin kaltaiset työkalut yhdistävät suuria kielimalleja ja symbolisia sääntöjä tämän hybridimallin toteuttamiseksi. Tärkeintä ei ole työkalu, vaan sen arkkitehtuuri.

Mitä voit tehdä jo seuraavalla neljänneksellä

Kartoita keskustelun kulku. Istu asiantuntijoidesi kanssa alas. Kirjaa ylös kymmenen ensimmäistä kysymystä, jotka he kysyvät asiakaskartoituksessa, ja miksi. Siinä on ohjatun myyntiprosessisi alku.

Piirrä tuote moduuleina ja valintoina. Yhdelle sivulle. Laatikkoja ja nuolia. Jos et pysty hahmottelemaan sitä, et pysty ylläpitämään sitä.

Tunnista ehdottomat säännöt. Kaksikymmentä tärkeintä rajoitetta, jotka turvaavat valmistettavuuden ja turvallisuuden. Vie ne ensin deterministiseen sääntömoottoriin. Älä kiistele hinnoittelusta, ennen kuin konfiguraatiot ovat aina virheettömiä.

Aloita yhdestä tuoteperheestä. Julkaise viikoissa, älä kvartaaleissa. Hio järjestelmää oikeiden kauppojen avulla. Lisää syvyyttä sinne, missä syntyy eniten epäselvyyksiä.

Vaadi selitettävyyttä. Jokainen suositus tarvitsee yhden lauseen perustelun. Jos järjestelmä ei osaa selittää toimintaansa, siihen ei luoteta.

Määrittele omistajuus ja muutosprosessi. Kuka hyväksyy uudet variantit? Miten säännöt testataan? Kuinka nopeasti päivityksen saa julki rikkomatta mitään?

Päätä järjestelmän paikka. CPQ:n edessä toimiva ohjattu myynti, itsenäinen konfigurointimoottori vai ERP:tä täydentävä työkalu. Pidä integraatiot kevyinä. Nouda vain ne tiedot, joita myynti tarvitsee.

Käyttöaste on ainoa todellinen mittari.

Mittaa päivittäistä käyttöä oikeissa myyntitapauksissa. Jos myyjät käyttävät järjestelmää vapaaehtoisesti puhelun aikana, koska se auttaa heitä ajattelemaan ja perustelemaan, olet voitolla. Jos he vievät tiedot Exceliin, et ole.

Loppusanat

Myynnin konfiguraattori on tulkki, joka muuttaa tarpeet valmistettaviksi vastauksiksi. Se jakaa asiantuntemusta laimentamatta sitä. Se tekee monimutkaisesta yksinkertaisen tuntuista ja yksinkertaisesta turvallisen tuntuista.

Myynnin konfiguraattori ei ainoastaan rakenna tarjouksia. Se rakentaa luottamusta – myyjissä, kumppaneissa ja asiakkaissa.