AI CRM si místo v průmyslovém obchodu zaslouží tím, že pořádně přečte poptávku, ne tím, že rozešle víc follow-upů

V té větě se skrývají dva různé obchody. Investiční celek kupuje komise v cyklu devíti až osmnácti měsíců; zakázkové obrábění se rozhoduje během dnů proti dodanému výkresu a problémem je počet poptávek, ne délka cyklu. Argumenty o poptávkách, kvalifikaci a dokumentaci níže platí pro obojí, ty o rozhodovacím týmu a scoringu jen pro investiční prodej. To, co AI v obou případech umí dobře, je úzké: přetváří text, který už máte.

Proč generická automatizace CRM selhává na dlouhém B2B obchodním cyklu

Standardní příručka předpokládá jednoho kupujícího, krátké hodnocení, velký trh a dost obchodů na to, aby scoring něco znamenal. Neplatí ani jedno. Investiční nákup posuzuje technolog, kterému jde o čas cyklu, technik kvality, kterému jde o způsobilost procesu, vedoucí údržby, kterému jde o náhradní díly, nákupčí, kterému jde o platební podmínky, a manažer, který má na starosti položku v capexu. Přicházejí v různých okamžicích, takže sekvence adresovaná „leadu“ nezasáhne nikoho.

Trh je navíc konečný. Oslovitelná množina je tak malá, že se stejná jména vracejí napříč roky i firmami, jak technici přecházejí mezi závody, a tak malá, že žádný behaviorální model nemá trénovací sadu hodnou toho jména. Otravná automatická zpráva tu není zaokrouhlovací chyba. Pamatuje se, i se jménem.

Zakázky se málokdy prohrávají proto, že chyběla další zpráva s dotazem, jestli jste se stihli k nabídce vrátit. Prohrávají se proto, že jste nebyli u toho s ničím užitečným ve chvíli, kdy se psal capex na příští rok, protože technická odpověď přišla pozdě, nebo protože zadání nikdo nezapsal ve tvaru, se kterým se dalo pracovat. Ani jedno není problém frekvence oslovení.

Čtení poptávky a vytažení skutečného zadání

Poptávky chodí v té podobě, v jaké se je zákazníkovi zrovna chtělo poslat: PDF, tabulka, sada výkresů, tři odstavce v e-mailu, nákupní formulář, ze kterého má smysl šest polí. Model spolehlivě vytáhne to, co je v dokumentu jako text — množství a odvolávkové schéma, termíny a dodací podmínky, seznam certifikátů, obchodní podmínky, čísla dílů zmíněná v těle zprávy — za dobu, za kterou soubor otevřete.

Co pochází z výkresu, je jiná třída údaje. Geometrické tolerování, značky svarů, soustava základen, drsnost povrchu, znaky označené jako kritické: tyhle se čtou nespolehlivě a cokoli přečteného z výkresu přichází označené jako neověřený návrh pro technika, nikdy jako hodnota, ze které se dá nacenit. Zacházet s oběma třídami stejně je nejrychlejší cesta od užitečné extrakce k chybě v nabídce.

Nejdřív vyřešte otázku vlastnictví. Sada výkresů je duševní vlastnictví zákazníka, obvykle pod NDA podepsaným dávno předtím, než poptávka dorazila, a v letectví, obraně a části automobilového průmyslu může podléhat exportní kontrole podle ITAR, EAR nebo evropského nařízení o dvojím užití. Než se výkres dostane k modelu, ověřte, co NDA dovoluje ohledně zpracování a subdodavatelů, kontrolovanou práci držte on-premise nebo v nasazení bez uchovávání dat a bez trénování, a mějte připravenou cestu k vyloučení, aby označení zákazníci a rodiny dílů do pipeline vůbec nevstoupili.

Cennější polovina výstupu je to, co chybí. Otázky, které pošlete zpátky během první hodiny, jsou nejsilnějším signálem kompetence, jaký kdy odešlete, a zabrání tomu, aby technik naceňoval proti předpokladu, který nikdo neověřil.

Užitečnou extrakci od té, kterou technik předělá ručně, dělí dvě pravidla. Každá položka uvádí svůj zdroj: list a buňku tam, kde je zdrojem tabulka, stránku a oblast na ní tam, kde jde o sken. A model raději nechá pole prázdné, než aby hádal, což je míra, kterou měříte po jednotlivých polích proti vlastní testovací sadě, ne chování, které dostanete tím, že mu to napíšete do zadání. Zdržet se odpovědi model nedokáže tam, kde je po ruce věrohodná výchozí hodnota, u tolerance nebo standardní drsnosti povrchu; pole s nízkou mírou vynechání a vysokou chybovostí proto nechte na člověku.

Návrh první technické odpovědi, aniž byste zavázali firmu

První odpověď rozhoduje, jestli jste v hodnocení. Dobrá pojmenuje aplikaci místo poděkování za projevený zájem, zopakuje zadání tak, jak mu rozumíte, položí dvě tři otázky, které mění odpověď, a zaváže se k dalšímu kroku s datem.

Model tuhle strukturu dodá za minutu a člověk ji upraví a odešle. Automatické odesílání je jiný systém, ne jiné nastavení téhož, a žádný návrh neuvádí specifikaci: každé číslo, které se může dostat do nabídky, pochází od někoho, kdo je oprávněn se jím zavázat.

Shrnutí historie zákazníka a jak udržet záznam v CRM aktuální

Obchodní případ, který běží čtrnáct měsíců, je rozprostřený do sta e-mailů, tří návštěv, dvou vzorkových dávek a jedné neúspěšné zkoušky. Historie existuje a nikdo ji nečte, takže když obchodník odejde, její praktická hodnota je nulová. Model, který vlákno přečte a shrne ho dalšímu člověku, je opravdu užitečný.

Je ale také ztrátový a to, co vypadne, je neúměrně často jednořádkový závazek zahrabaný někde uprostřed: tolerance, ve které jste ustoupili, cena držená na danou dobu, výjimka dohodnutá po telefonu. Shrnutí, které je skoro správné a mlčky vynechá ústupek, je horší než žádné. Berte ho tedy jako vstup do vlákna, každé tvrzení navažte na zprávu, ze které pochází, a závazky vytáhněte do samostatného seznamu s odkazy na zdroj.

Stejná schopnost řeší nejstarší problém CRM. Obchodníci záznamy neaktualizují, protože aktualizace je zadávání dat, které nic nevrací, a odpověď je stejná jako na dílně: navrhovat, ne vyžadovat. Po hovoru asistent sepíše poznámku a navrhne změnu fáze i další krok. Zůstávají to návrhy, protože asistent, který tiše přepisuje hodnoty nebo termíny uzavření, ničí jedinou věc, kterou CRM musí být, totiž záznam, kterému lidé věří.

Nahradí AI CRM systém, který už provozujete, nebo sedne nad něj?

Většinou sedne nad něj. Záznam o zákazníkovi, obchodním případu a zakázce zůstává tam, kde je, ať už je to Salesforce, Dynamics, HubSpot, Odoo nebo CRM modul vašeho ERP. Asistent čte z tohoto záznamu, z poštovní schránky, z archivu nabídek a z úložiště dokumentů a zapisuje zpátky tři věci: poznámku, navrženou změnu pole a úkol s vlastníkem a datem, vše dohledatelné a vratné.

Projektem je tedy integrace, ne model, a selhává obvykle identifikátor, který musí přežít cestu mezi CRM, ERP a dokumentovým systémem, protože klíč zákazníka a číslo odběratele nikdo nikdy nesladil. Pokud CRM nemáte, na prvním místě je CRM: asistent nemůže udržovat aktuální záznam, který neexistuje.

V čem je AI špatná a kde vás to bude stát peníze

Nezná vaše výrobní možnosti: že tolerance je dosažitelná, ale až na druhé operaci, že se slitina ve vašem procesu nalepuje, že uvedený roční objem je několikanásobek toho, co ten segment kdy objednal. Nemá cit pro obchodní důsledek a napíše sebejistou větu o dodací lhůtě stejně ochotně jako opatrnou, protože obojí je dobře utvořená čeština. Neví ani, co se změnilo poté, co jste jí dokumenty předali, což z aktuálnosti dokumentů dělá provozní odpovědnost, ne úkol při nasazení.

Kvalifikace poptávek, která respektuje technického kupujícího: proč scoring není kvalifikace

Scoring přiřazuje číslo podle chování: navštívené stránky, otevřené e-maily, stažené dokumenty. Na trhu s takhle málo skutečnými kupujícími to většinou měří zvědavost a profil, který odměňuje nejspolehlivěji, je technik konkurence, který si čte vaši dokumentaci.

Kvalifikace odpovídá na jiné otázky. Existuje aplikace, do které naše zařízení patří, popsaná dost konkrétně na to, aby se dala ověřit? Je rozpočet, a v jakém období? Kdo rozhoduje a kdo může vetovat? A co se stane, když neudělají nic?

Asistent pomůže jedině tím, že se ptá na otázky, na které technický kupující chce odpovídat. Technik vám ochotně dá díl, materiál, objem a čas cyklu a opustí formulář, který po něm chce velikostní pásmo firmy a rozpětí rozpočtu. Nejpodceňovanějším výstupem je rychlé ne: většina nákladů špatné poptávky je práce aplikačního technika, kterou spotřebuje dřív, než někdo zjistí, že se nikdy nehodila.

AI chatbot, který odpovídá z vaší dokumentace, místo aby si vymýšlel

Položte jazykovému modelu otázku o produktu a on odpoví z toho, na čem byl trénovaný, prózou, která zní přesně jako vaše dokumentace, přičemž mezi tím, jak sebejistě zní, a tím, jestli je to pravda, není žádný vztah. V technickém obchodě je to nejhorší možné selhání, protože špatnou odpověď si někdo vyfotí, přepošle ji dál a odcituje vám ji na poradě.

Přežitelné to dělá ukotvení v dokumentech. Otázka vytáhne pasáže z vašich vlastních dokumentů, model odpovídá jen z nich a cituje je, čímž se běžné selhání změní na „tohle jsem v dokumentaci nenašel“. Většina práce je na straně dokumentů: které jsou závazné, které jsou neplatné a musí se odstranit z indexu — v dokumentovém systému zůstanou, jak to vyžaduje vaše procedura kvality, ale pro asistenta jsou nedosažitelné — a které jsou důvěrné.

Selhání to neodstraní. Vyhledávání vrátí neplatnou revizi, protože ta se textově shoduje lépe; vrátí správný dokument a model v něm špatně přečte tabulku; nenajde nic relevantního a odpoví z trénovacích dat stejně. Citace každý z těch případů zhorší, protože špatné odpovědi s názvem dokumentu se věří víc.

Omezení proto vynuťte v systému, ne v dokumentu s pravidly: odpovídat jen z publikovaných materiálů, uvést použitý dokument a revizi, u otázek na specifikaci raději odmítnout než dovozovat, nikdy neuvádět cenu ani dodací lhůtu. A logujte každou otázku, na kterou odpovědět nedokázal, protože ten log je seznam, který vaši zákazníci napsali o tom, co jste nezveřejnili.

Data, která už máte, a co dá práce, aby se dala použít

Víc, než si myslíte, a v horším stavu, než si myslíte. Poštovní schránka drží roky poptávek a technické komunikace, historie nabídek drží, co jste nabídli a za kolik, a důvody prohraných zakázek drží nejcennější datovou sadu ve firmě, pokud je někdo vyplňoval poctivě. ERP drží vaše dodací lhůty a termíny dodání, u kterých se vyplatí prověřit, než jim začnete věřit: plán proti skutečnosti a jestli se slíbený termín pokaždé přepsal, když se posunul.

Pak jejich stav. Stejný zákazník existuje třikrát pod různým zápisem a německá dceřiná firma je samostatný záznam bez vazby na matku, takže nikdo nevidí, že skupina už dvě linky koupila. A důvod prohry je na většině záznamů „cena“, což je to, co lidé vyberou, když skutečným důvodem byla pomalá odpověď.

Ta práce je neefektní a je to většina projektu: odstranit duplicity zákazníků, namodelovat skupinové struktury, dohodnout jedno závazné místo pro dokumentaci s výslovným polem pro revizi, nahradit volný text důvodu prohry krátkým seznamem, ze kterého obchodník může vybrat po pravdě. Model postavený na těchto datech zdědí každou chybu a doručí ji sebejistě.

Předání člověku a proč špatné předání zničí celou hodnotu

Okamžik, kdy asistent končí a začíná člověk, je místo, kde zákazník soudí celý systém. Zákazník podrobně popíše svou aplikaci, obchodník za dva dny zavolá a ptá se na totéž od začátku, a všechno, co automatizace získala, se v té minutě utratí.

Fungující předání nese konverzaci připojenou k obchodnímu případu, otázku, která eskalaci vyvolala, jmenovitého vlastníka místo sdílené schránky a reakční dobu, za kterou někdo odpovídá. Buďte upřímní v tom, co asistent je, protože technický kupující na to přijde během pár výměn, a eskalujte automaticky při jakémkoli závazku ke specifikaci, jakékoli ceně, jakékoli stížnosti a vždy, když se zákazník ptá podruhé.

Poctivé měření: doba odezvy a kvalifikovaná pipeline, ne počet odeslaných zpráv

Většina reportů o těchhle systémech měří jejich vlastní aktivitu: odeslané zprávy, obsloužené konverzace, ušetřené hodiny spočítané koeficientem od dodavatele. Všechno tohle roste bez ohledu na to, jestli se něco zlepšilo. Začněte místo toho dobou od poptávky k první věcné technické odpovědi, kde věcná znamená, že se zabývala aplikací, ne potvrzením příjmu. Pak dobou od poptávky k nabídce u těch poptávek, které jste přijali jako vhodné, a podílem těch, které se k nabídce skutečně dostaly, což odhalí ty, které umírají ve frontě u technika.

Odmítnuté poptávky měřte na samostatné ose, kolik dní trvalo je odmítnout, protože právě tohle číslo má rychlé ne stlačovat dolů. Jediný podíl naceněných poptávek počítaný přes oba jmenovatele říká firmě, ať nacení poptávky, které jste jí právě přikázali odmítat. Pak kvalifikovaná pipeline proti definici kvalifikace sepsané před projektem a počet otázek, na které asistent nedokázal odpovědět, který má klesat, jak dopisujete, co chybělo.

GDPR a co očekává evropský průmyslový nákupčí

Právní základ pro B2B oslovování není v Evropě jednotný. Národní implementace pravidel ePrivacy se liší a v některých členských státech se nevyžádaný obchodní e-mail firemnímu kontaktu posuzuje mnohem přísněji, než naznačuje obvyklé shrnutí o „oprávněném zájmu“. Rozhodněte to s právníkem pro každý trh a systém postavte tak, aby se pravidla mohla lišit podle země bez přepisování.

Zbytek jsou technická rozhodnutí s dopadem do nákupu. Dotazník nákupčího se zeptá, kde se text jejich poptávky zpracovává, jestli opouští EU, jestli trénuje něčí model a jak dlouho se uchovává. Přes první síto vás dostanou čtyři krátké odpovědi: zpracování v EU, žádné trénování na zákaznickém obsahu, definovaná doba uchování, logovaný přístup. Za sítem sedí podepsaná zpracovatelská smlouva, seznam subzpracovatelů, vaše technická a organizační opatření a obvykle certifikát ISO 27001 nebo SOC 2. Připravte si je dřív, než poptávka dorazí.

Do cesty každého rozhodnutí, které poptávku odmítá, postavte člověka, což je zároveň správný návrh a konec debaty o automatizovaném rozhodování. Nad rámec práva: evropský průmyslový nákupčí čeká, že se s ním bude jednat jako s profesionálem, a vymyšlené „navazuji na náš rozhovor“ nadělá na malém technickém trhu víc škody než neposlat nic.

Kde začít: první projekt s AI v obchodě

Jeden workflow, osm až dvanáct týdnů, jeden jmenovaný vlastník na obchodě a jeden v technice a písemná definice úspěchu dřív, než se cokoli postaví. Začněte příchozí cestou poptávek: hodnota je soustředěná tam a způsob selhání uvidí nejdřív vaši vlastní lidé.

První dva týdny věnujte sesbírání padesáti skutečných poptávek z posledních dvou let, s tím, co se na ně nabídlo a jak dopadly. Tahle sada je test a bez ní hodnotíte na ukázkách, které vybral ten, kdo je postavil. Pak postavte extrakci a seznam chybějících informací a nechte je zkontrolovat aplikačním technikem proti tomu, čím zadání nakonec bylo. Asistent směrem k zákazníkovi přijde poslední, protože jako jediný mluví se zákazníky bez dozoru.

Výstupní kritéria sepište před startem: doba první odpovědi na pojmenovaném segmentu, hodiny technického oddělení na jednu poptávku a extrakce vyhodnocená proti té referenční sadě, precision po jednotlivých polích a především recall na polích, která nesou riziko v nabídce. Míra přijetí návrhů je signál adopce, ne výstupní kritérium: jakmile technici vědí, že je to hodnocené číslo, okrajové opravy skončí, a chyby, na kterých záleží, jsou vynechání, která kontrolor při zběžném pročtení úhledného seznamu nezachytí. Dopředu se rozhodněte, co odmítnete: hromadný outbound, cokoli, co odesílá bez kontroly, a provoz tam, kde je právní základ nebo situace kolem NDA otevřená.

Kam do toho zapadá Meta Smart Factory

META CRM Bot od MSF je produkt na obchodní straně této platformy; ostatní moduly na tomto webu — MES, APS, MRP, kvalita, údržba, sklad — řídí továrnu. Stavíme obě poloviny, a proto je argumentace výše o pořadí kroků a kvalitě dat, ne o funkcích.

Jednu věc je lepší pojmenovat než obejít: ten produkt je tu uvedený jako vícejazyčná komunikace běžící nepřetržitě, a v technickém obchodě to není ta část, kterou zapínat jako první. Omezení, pro která se výše argumentuje, jsou otázkou konfigurace, ne marketingu — psaní návrhů s odesíláním člověkem, eskalace u jakéhokoli závazku ke specifikaci, ceně nebo termínu dodání, žádný hromadný outbound na trh, kde se stejná jména vracejí. Vyžádejte si je do zkušebního provozu.

Za přemýšlení stojí rozhraní mezi oběma systémy. Průmyslové poptávce dominují dvě otázky, jestli udržíte tenhle znak při tomhle taktu a jestli to tu bude ve 34. týdnu, a ani na jednu by asistent odpovídat neměl. První je způsobilost procesu na konkrétním znaku, stroji a přípravku, se studií měřidla, která nespotřebuje polovinu tolerančního pole, a u nového dílu není z čeho odpovídat, protože historie neexistuje. Druhá je otázka na budoucí kapacitu proti knize zakázek, která se mění každý den. Historické dodržování termínů není kapacita a kapacita dnes není kapacita ve 34. týdnu.

Co asistent udělat může, je dohledat podklady a položit je před člověka, který odpovídá. Naměřené časy cyklu a zmetkovitost na nejbližším srovnatelném dílu řeknou vašemu technologovi, jestli poptávka ospravedlňuje studii způsobilosti; kniha zakázek v APS řekne vašemu plánovači, jestli je 34. týden reálný. Datum pořád dává plánovač. Pokud výrobní záznam není důvěryhodný, obchodní vrstva s AI postavená nad ním z něj bude naceňovat stejně.

Užitečnější první rozhovor proto není ukázka produktu. Je to průchod vašimi vlastními nedávnými poptávkami a tím, jak každá dopadla, protože to během jednoho odpoledne ukáže, kde obchod ztrácí čas — a někdy je odpovědí, že to není ta část, kterou umí spravit software.