Az AI CRM azzal érdemli ki a helyét egy ipari üzletben, hogy rendesen elolvassa az ajánlatkérést, nem azzal, hogy több utánkövetést küld

Ebben a mondatban két különböző üzlet rejtőzik. A gépberuházás bizottsági döntés, kilenc-tizennyolc hónapos ciklussal; a rajz szerinti megmunkálás napok alatt dől el egy rajz alapján, ahol nem a ciklushossz a gond, hanem az ajánlatkérések mennyisége. Az alábbi, ajánlatkérésről, minősítésről és dokumentációról szóló érvek mindkettőre állnak, a döntéshozói körről és a pontozásról szólók csak a beruházási eladásra. Amiben a mesterséges intelligencia jó, az mindkét esetben szűk: átformálja azt a szöveget, ami már megvan.

Miért mond csődöt az általános CRM-automatizálás egy hosszú B2B értékesítési ciklusban

A szokásos forgatókönyv egyetlen vevőt, rövid értékelést, nagy piacot és annyi üzletmennyiséget feltételez, hogy a pontozásnak legyen értelme. Egyik sem igaz. Egy beruházást a ciklusidőre figyelő gyártástechnológus ítél meg, a folyamatképességre a minőségmérnök, a pótalkatrészekre a karbantartásvezető, a fizetési feltételekre a beszerző, és ott van a vezető, akinek a beruházási keret a felelőssége. Különböző pillanatokban lépnek be, így a „lead”-nek címzett kampánysorozat senkit nem ér el.

A piac ráadásul véges. A megcélozható kör elég kicsi ahhoz, hogy ugyanazok a nevek térjenek vissza éveken és cégeken át, ahogy a mérnökök gyárat váltanak, és elég kicsi ahhoz, hogy egyetlen viselkedési modellnek se legyen említésre méltó tanítóhalmaza. Egy idegesítő automata üzenet itt nem kerekítési hiba. Megjegyzik, névvel együtt.

Az üzletek ritkán vesznek el azért, mert elmaradt még egy levél arról, hogy volt-e ideje átnézni az ajánlatot. Azért vesznek el, mert nem voltunk ott semmi használhatóval, amikor a jövő évi beruházási listát összeállították, mert a műszaki válasz túl későn érkezett vissza, vagy mert a követelmény soha nem került le papírra olyan formában, amivel bárki dolgozni tudott volna. Ezek egyike sem ütemezési kérdés.

Az ajánlatkérés elolvasása és a követelmény kibontása

Az ajánlatkérések olyan formában érkeznek, amilyenben a vevőnek éppen kedve volt elküldeni: PDF-ben, táblázatban, rajzcsomagban, három bekezdésben egy levél törzsében, beszerzési sablonban, amiből hat mező számít. Egy modell megbízhatóan kiemeli azt, ami szövegként ott van — darabszámok és lehívási ütem, dátumok és szállítási feltételek, a tanúsítványok listája, kereskedelmi feltételek, a levél törzsében megnevezett cikkszámok —, annyi idő alatt, amennyi a fájl megnyitása.

Ami a rajzon keletkezik, az másik osztály. A geometriai tűrések, a hegesztési jelek, a bázisrendszer, a felületi érdesség, a kritikusként megjelölt jellemzők: ezeket megbízhatatlanul olvassa, és bármi, ami rajzról jön, mérnöknek szóló, ellenőrizetlen javaslatként jelenik meg, soha nem olyan értékként, amiből ajánlatot lehet adni. A két osztály azonos kezelése a leggyorsabb út a hasznos kinyeréstől az elszámolt ajánlatig.

Elsőként a tulajdonjogot kell tisztázni. A vevő rajzcsomagja az ő szellemi tulajdona, rendszerint jóval az ajánlatkérés beérkezése előtt aláírt NDA alatt, a repülőgép- és védelmi iparban, valamint az autóipar egyes területein pedig exportellenőrzés alá eshet az ITAR, az EAR vagy az EU kettős felhasználású rendelete szerint. Még mielőtt egy rajz modellhez kerülne, tisztázni kell, mit enged meg az NDA a feldolgozás és az alvállalkozók tekintetében; az ellenőrzött munka maradjon on-premise vagy olyan környezetben, ahol nincs adatmegőrzés és nincs tanítás; és legyen kizárási útvonal, hogy a megjelölt vevők és alkatrészcsaládok soha ne kerüljenek be a folyamatba.

A kimenet értékesebbik fele az, ami hiányzik. Az első órában visszaküldött kérdések a legerősebb szakmai jelzés, ami egy ajánlatkérésre egyáltalán adható, és megakadályozzák, hogy a mérnök olyan feltevés alapján adjon árat, amit senki nem ellenőrzött.

Két szabály választja el a hasznos kinyerést attól, amit a mérnök úgyis újracsinál kézzel. Minden tétel megjelöli a forrását: munkalapot és cellát, ha táblázatból jön, oldalt és azon belüli tartományt, ha szkennelt dokumentumból. A modell pedig inkább üresen hagyja a mezőt, mint hogy találgasson — ez olyan arány, amit mezőnként, saját tesztkészleten kell mérni, nem pedig olyan viselkedés, amit utasítással meg lehet kapni. A kihagyás pont ott hibázik, ahol kézenfekvő alapérték kínálkozik, egy tűrésen vagy egy szabványos felületen, így az a mező, ahol kevés a kihagyás és sok a hiba, emberre marad.

Az első műszaki válasz megfogalmazása anélkül, hogy elkötelezné a céget

Az első válasz dönti el, bent vagyunk-e az értékelésben. A jó válasz megnevezi az alkalmazást ahelyett, hogy megköszönné az érdeklődést, visszamondja a követelményt úgy, ahogy megértette, felteszi azt a két-három kérdést, ami megváltoztatja a választ, és dátummal vállal következő lépést.

A modell egy perc alatt hozza ezt a szerkezetet, ember pedig szerkeszti és küldi. Az automatikus küldés más rendszer, nem ugyanannak a rendszernek egy másik beállítása, és egyetlen piszkozat sem rögzít specifikációt: minden szám, ami ajánlatba kerülhet, olyantól származik, akinek joga van elkötelezni.

Az ügyféltörténet összefoglalása és a CRM-adatok naprakészen tartása

Egy tizennégy hónapja futó lehetőség száz e-mailben, három látogatásban, két mintagyártásban és egy sikertelen próbában terül szét. Az előzmény megvan, és senki nem olvassa, így amikor az ügyfélfelelős kilép, a gyakorlati értéke nulla. Az a modell, amelyik végigolvassa a szálat és eligazítja a következő embert, valóban hasznos.

Információt is veszít, és ami kimarad, az aránytalanul gyakran a levelezés közepébe temetett, egysoros vállalás: az elengedett tűrés, a megadott ideig tartott ár, a telefonban elfogadott kivétel. Az az összefoglaló, amelyik majdnem pontos, és némán kihagyja az engedményt, rosszabb, mintha nem lenne. Kezelni tehát a szálba vezető útként kell, minden állítást ahhoz az üzenethez kötve, ahonnan származik, a vállalásokat pedig külön, hivatkozott listába emelve.

Ugyanez a képesség a CRM legrégebbi problémájára is válasz. Az értékesítők azért nem frissítik az adatokat, mert a frissítés olyan adatbevitel, ami semmit nem ad vissza, és a válasz ugyanaz, mint az üzemben: javasolj, ne követelj. Egy hívás után az asszisztens megírja a jegyzet piszkozatát, és javaslatot tesz a szakaszváltásra és a következő lépésre. Javaslatok is maradnak, mert az az asszisztens, amelyik némán átír értékeket vagy várható zárási dátumokat, tönkreteszi az egyetlen dolgot, aminek egy CRM-nek lennie kell: olyan nyilvántartásnak, amiben az emberek hisznek.

Az AI CRM leváltja a meglévő rendszert, vagy ráépül

Többnyire ráépül. Az ügyfél, a lehetőség és a rendelés nyilvántartása ott marad, ahol van, legyen az Salesforce, Dynamics, HubSpot, Odoo vagy az ERP CRM-modulja. Az asszisztens ebből a nyilvántartásból, a postafiókból, az ajánlatarchívumból és a dokumentumtárból olvas, és három dolgot ír vissza: jegyzetet, javasolt mezőváltozást, valamint feladatot felelőssel és határidővel — mindet visszakövethetően és visszavonhatóan.

A projekt tehát az integráció, nem a modell, és általában az az azonosító bukik el, amelynek végig kell mennie a CRM, az ERP és a dokumentumrendszer között, mert az ügyfélazonosítót és a vevőkódot soha nem egyeztették össze. Ha nincs CRM, akkor a CRM az első: az asszisztens nem tud naprakészen tartani olyan nyilvántartást, ami nem létezik.

Amiben a mesterséges intelligencia rossz, és ahol pénzbe kerül

Nem ismeri a gyártóképességet: azt, hogy a tűrés tartható, de csak a második műveleten, hogy egy ötvözet berágódik ebben a technológiában, hogy a megadott éves mennyiség többszöröse annak, amit az a szegmens valaha rendelt. Nincs érzéke az üzleti következményhez, és ugyanolyan könnyen ír magabiztos mondatot az átfutási időről, mint óvatosat, mert mindkettő helyes magyar mondat. Azt sem tudja, mi változott azután, hogy a dokumentumokat átadták neki, ettől a dokumentumok naprakészen tartása üzemeltetési feladat, nem bevezetési lépés.

Minősítés, ami komolyan veszi a műszaki vevőt: miért nem minősítés a pontozás

A pontozás viselkedésből ad számot: megnézett oldalak, megnyitott levelek, letöltött dokumentumok. Egy ilyen kevés valódi vevőt számláló piacon ez javarészt kíváncsiságot mér, és a profil, amit a legmegbízhatóbban jutalmaz, egy versenytárs mérnöke, aki a dokumentációt olvassa.

A minősítés más kérdésekre válaszol. Van-e olyan alkalmazás, amire a berendezés illik, elég konkrétan leírva ahhoz, hogy ellenőrizhető legyen. Van-e keret, és melyik időszakban. Ki dönt, és ki tud vétózni. És mi történik, ha nem csinálnak semmit.

Az asszisztens csak úgy segít, ha olyan kérdéseket tesz fel, amikre egy műszaki vevő szívesen válaszol. A mérnök készséggel megadja az alkatrészt, az anyagot, a darabszámot és a ciklusidőt, és otthagyja azt az űrlapot, amelyik létszámkategóriát és költségkeret-sávot követel. A leginkább alábecsült kimenet a gyors nem: egy rossz ajánlatkérés költségének nagyobbik része az az alkalmazástechnika, amit felemészt, mielőtt bárki megállapítaná, hogy sosem illett.

Olyan AI chatbot, amely a saját dokumentációból válaszol, nem pedig kitalálja

Ha egy nyelvi modellnek terméktechnikai kérdést tesznek fel, a tanulóanyagából válaszol, olyan szövegben, ami pontosan úgy olvasható, mint a saját dokumentáció, és semmilyen kapcsolat nincs aközött, mennyire hangzik magabiztosnak, és hogy igaz-e. Műszaki eladásban ez a lehető legrosszabb hiba, mert a rossz válaszról képernyőkép készül, továbbküldik, és egy tárgyaláson visszaidézik.

A saját dokumentumokra alapozás teszi elviselhetővé. A kérdés a saját dokumentumokból hoz be szövegrészeket, a modell csak azokból válaszol, és hivatkozik rájuk, ami a szokásos hibát azzá alakítja, hogy „ezt nem találtam meg a dokumentációban”. A munka nagyobbik része a dokumentumok oldalán van: melyik dokumentum a mérvadó, melyiket vonták vissza és kell kivenni az indexből — a minőségirányítási előírás szerint a dokumentumrendszerben megőrizve, de az asszisztens számára elérhetetlenül —, és melyik bizalmas.

A hibát ez nem szünteti meg. A keresés azért hozza vissza a visszavont revíziót, mert az a revízió illeszkedik jobban a szöveghez; jó dokumentumot hoz, és a modell félreolvas benne egy táblázatot; nem talál semmi relevánsat, és mégis a tanulóanyagából válaszol. A hivatkozás mindegyiket rontja, mert a dokumentumnévvel ellátott rossz választ jobban elhiszik.

A korlátokat tehát a rendszerben kell kikényszeríteni, nem egy szabályzatban: csak publikált anyagból válaszoljon, nevezze meg a használt dokumentumot és revíziót, specifikációs kérdésben inkább tagadja meg a választ, mint hogy következtessen, árat és szállítási határidőt soha ne adjon. És naplózzon minden kérdést, amire nem tudott válaszolni, mert az a napló egy lista, amit a vevők írtak arról, amit nem publikáltunk.

A meglévő adatok, és mi kell ahhoz, hogy használhatók legyenek

Több van belőlük, mint gondolnánk, és rosszabb állapotban, mint gondolnánk. A postafiókban évek ajánlatkérései és műszaki levelezései vannak, az ajánlattörténetben az, hogy mit kínáltunk és milyen áron, az elvesztési okokban pedig a cég legértékesebb adathalmaza — ha valaki őszintén kitöltötte. Az ERP-ben ott vannak az átfutási idők és a szállítási határidők, amiket érdemes ellenőrizni, mielőtt hinni kezdünk nekik: a tervezett és a tényleges összevetése, és hogy a vállalt dátumot felülírták-e minden egyes csúszáskor.

Aztán az állapotuk. Ugyanaz a vevő háromszor szerepel, más-más írásmóddal, a német leányvállalat pedig külön ügyfél, az anyacéghez fűződő kapcsolat nélkül, így senki nem látja, hogy a csoport már vett két gyártósort. Az elvesztés oka pedig a legtöbb rekordon „ár”, mert ezt választják az emberek, amikor a valódi ok a lassú válasz volt.

A munka hálátlan, és ez a projekt nagyobbik része: ügyfelek deduplikálása, csoportstruktúrák leképezése, egyetlen mérvadó dokumentumhely kijelölése kifejezett revíziómezővel, a szabad szöveges elvesztési ok kiváltása rövid listával, amiből egy értékesítő őszintén tud választani. Az ilyen adatokra épülő modell minden hibát megörököl, és magabiztosan szállítja tovább.

Átadás embernek, és miért semmisíti meg az értéket a rossz átadás

Az a pillanat, amikor az asszisztens megáll és egy ember veszi át, az, ahol a vevő az egész rendszert megítéli. A vevő részletesen elmagyarázza az alkalmazását, két nappal később felhívja egy értékesítő, és elölről felteszi ugyanazokat a kérdéseket, és minden, amit az automatizálás nyert, elmegy abban az egy percben.

A működő átadás magával viszi a lehetőséghez csatolt beszélgetést, a kérdést, ami az eszkalációt kiváltotta, egy megnevezett felelőst közös postafiók helyett, és egy válaszidőt, amiért valaki felel. Őszintén kell megmondani, mi az asszisztens, mert egy műszaki vevő néhány váltás alatt kitalálja, és automatikusan eszkalálni kell minden specifikációs vállalásnál, minden árnál, minden panasznál, és minden olyankor, amikor a vevő másodszor kérdez.

Őszinte mérés: válaszidő és minősített pipeline, nem elküldött üzenetek

Az ilyen rendszerekről szóló jelentések többsége a saját tevékenységüket méri: elküldött üzenetek, kezelt beszélgetések, a szállító által adott szorzóval számolt megtakarított órák. Mindegyik nő, akár javult valami, akár nem. Kezdjük inkább azzal, mennyi idő telik el a megkereséstől az első érdemi műszaki válaszig, ahol az érdemi azt jelenti, hogy az alkalmazásra reagált, nem a beérkezést igazolta vissza. Aztán az ajánlatkéréstől az ajánlatig eltelt idő azokon a megkereséseken, amiket befogadtunk, és hogy ezek közül hány jutott el ajánlatig — ez mutatja meg, melyek halnak el egy mérnök sorában.

Az elutasított megkereséseket külön tengelyen kell mérni, hogy hány napig tartott elutasítani őket, mert ez az a szám, aminek a leszorítására a gyors nem létezik. Egyetlen, mindkét nevezőre számolt ajánlatadási arány azt üzeni a szervezetnek, hogy adjon ajánlatot azokra a megkeresésekre, amiket épp az imént mondtunk visszautasítandónak. Aztán a minősített pipeline, a minősítés projekt előtt leírt meghatározása szerint, és azoknak a kérdéseknek a száma, amikre az asszisztens nem tudott válaszolni — ennek csökkennie kell, ahogy publikáljuk, ami hiányzott.

GDPR és amit egy európai ipari vevő elvár

A B2B megkeresés jogalapja Európában nem egységes. Az ePrivacy szabályok nemzeti átültetései eltérnek, és egyes tagállamokban a céges kapcsolattartónak küldött kéretlen kereskedelmi e-mailt sokkal szigorúbban kezelik, mint azt a szokásos „jogos érdek” összefoglaló sugallja. Piaconként, jogásszal kell eldönteni, a rendszert pedig úgy felépíteni, hogy a szabályok országonként eltérhessenek anélkül, hogy újra kellene írni.

A többi mérnöki döntés, beszerzési következményekkel. A vevő kérdőíve rá fog kérdezni, hol dolgozzák fel a megkeresésük szövegét, elhagyja-e az EU-t, tanít-e vele bárki modellt, és meddig őrzik meg. Négy rövid válasz átvisz az első szűrőn: feldolgozás az EU-ban, nincs tanítás vevői tartalmon, meghatározott megőrzési idő, naplózott hozzáférés. A szűrő mögött aláírt adatfeldolgozói szerződés, aladatfeldolgozói lista, a technikai és szervezési intézkedések és rendszerint egy ISO 27001 vagy SOC 2 tanúsítvány áll. Ezeket a megkeresés beérkezése előtt kell összeállítani.

Minden olyan döntés útjában, amelyik elutasít egy megkeresést, maradjon ember — ez egyszerre a helyes felépítés és az automatizált döntéshozatalról szóló vita vége. A jogon túl az európai ipari vevő elvárja, hogy szakemberként kezeljék, és egy kitalált „a beszélgetésünkre visszatérve” többet árt egy kis műszaki piacon, mint ha semmit nem küldenénk.

Hol kezdjük: az első AI-projekt az értékesítésben

Egy folyamat, nyolc-tizenkét hét, egy megnevezett felelős az értékesítésben és egy a műszaki területen, és a siker leírt meghatározása, még mielőtt bármi elkészülne. A beérkező ajánlatkérések útjával érdemes kezdeni: ott sűrűsödik az érték, és a hibás működést először a saját emberek látják.

Az első két hét azzal megy el, hogy összegyűlik ötven valódi ajánlatkérés az elmúlt két évből, azzal együtt, hogy mit ajánlottunk rájuk és mi lett belőlük. Ez a készlet a teszt, és nélküle olyan bemutatókon értékelünk, amiket az válogatott, aki készítette őket. Aztán jön a kinyerés és a hiányzó információk listája, amit alkalmazásmérnök néz át azzal összevetve, minek bizonyult végül a követelmény. A vevővel beszélő asszisztens jön utoljára, mert egyedül ő beszél felügyelet nélkül vevővel.

A kilépési feltételeket indulás előtt kell leírni: első válaszidő egy megnevezett szegmensen, mérnökóra ajánlatkérésenként, és a kinyerés pontszáma azon a referenciakészleten, mezőnkénti precizitás és mindenekelőtt fedés azokon a mezőkön, amelyek ajánlati kockázatot hordoznak. Az elfogadási arány bevezetettségi jelzés, nem kilépési feltétel: amint a mérnökök megtudják, hogy ez a pontszám, a határeseti javítások elmaradnak, és a lényeges hibák azok a kihagyások lesznek, amiket egy rendezett listát átfutó ellenőr nem vesz észre. Előre kell eldönteni, mit utasítunk vissza: tömeges kimenő megkeresést, bármit, ami ellenőrizetlenül küld, és a futtatást ott, ahol a jogalap vagy az NDA kérdése nyitott.

Hol illeszkedik a Meta Smart Factory

Az MSF META CRM Bot a platform értékesítési oldalán álló termék; az oldalon szereplő többi modul — MES, APS, MRP, minőség, karbantartás, raktár — a gyárat működteti. Mindkét felet mi építjük, és ezért szól a fenti érvelés a sorrendről és az adatminőségről, nem a funkciókról.

Egy dolgot nevezzünk nevén ahelyett, hogy elkennénk: ez a termék többnyelvű, éjjel-nappal futó üzenetküldésként szerepel itt, és műszaki eladásban nem ez az a rész, amit elsőként be kell kapcsolni. A fent kifejtett korlátok beállítás kérdései, nem marketingé — piszkozatírás emberi küldéssel, eszkaláció minden specifikációs, ár- vagy szállítási vállalásnál, semmi tömeges kimenő megkeresés egy olyan piacon, ahol ugyanazok a nevek térnek vissza. Egy próbában ezeket kell kérni.

Amin érdemes gondolkodni, az az illesztés. Egy ipari megkeresést két kérdés ural — tartható-e ez a jellemző ezen az ütemen, és ott lesz-e a 34. héten —, és egyikre sem asszisztensnek kell válaszolnia. Az első folyamatképesség egy konkrét jellemzőn, gépen és készüléken, olyan mérőeszköz-képességvizsgálattal, amelyik nem eszi meg a tűrésmező felét, új alkatrésznél pedig nincs előzmény, amiből válaszolni lehetne. A második előretekintő kapacitáskérdés egy naponta változó rendelésállománnyal szemben. A korábbi határidőtartás nem kapacitás, és a mai kapacitás nem a 34. heti kapacitás.

Amit az asszisztens meg tud tenni: előveszi a bizonyítékot, és odateszi annak, aki válaszol. A legközelebbi hasonló alkatrész mért ciklusidői és selejtje megmondják a mérnöknek, hogy a megkeresés indokol-e képességvizsgálatot; az APS rendelésállománya megmondja a tervezőnek, hogy a 34. hét reális-e. A dátum továbbra is a tervezőtől jön. Ha a termelési nyilvántartás nem megbízható, a rá épülő AI értékesítési réteg akkor is abból fog ajánlatot adni.

A hasznosabb első beszélgetés tehát nem bemutató. Hanem a saját, közelmúltbeli ajánlatkérések átnézése, és hogy mi lett mindegyikkel, mert ez egy délután alatt megmutatja, hol veszít időt az eladás — és néha a válasz az, hogy nem azon a részen, amit szoftver meg tud javítani.