CRM зі штучним інтелектом виправдовує себе у промисловому продажі тим, що вміє правильно прочитати запит, а не тим, що надсилає більше нагадувань

У цьому реченні ховаються два різні бізнеси. Капітальне обладнання — це колективна закупівля з циклом від дев’яти до вісімнадцяти місяців; механічна обробка за кресленням замовника вирішується за дні під конкретне креслення, і проблема там не в довжині циклу, а в кількості RFQ. Аргументи нижче про RFQ, кваліфікацію та документацію стосуються обох; про закупівельний комітет і скоринг — лише капітального продажу. Те, що ШІ робить добре в обох випадках, вузьке: він переформатовує текст, який у вас уже є.

Чому універсальна автоматизація CRM не працює на довгому циклі B2B-продажу

Стандартний сценарій припускає одного покупця, коротке оцінювання, великий ринок і достатній потік угод, щоб скоринг щось означав. Жодна з цих умов не виконується. Капітальну закупівлю оцінює інженер-технолог, якому важливий час циклу, інженер з якості — придатність процесу, керівник служби технічного обслуговування — запчастини, закупівельник — умови, і керівник, який відповідає за рядок капітальних витрат. Вони з’являються в різні моменти, тому послідовність листів, адресована «ліду», не доходить ні до кого.

Ринок до того ж скінченний. Доступна множина настільки мала, що ті самі прізвища повторюються роками й між компаніями, бо інженери переходять із заводу на завод, — і настільки мала, що жодна поведінкова модель не має навчальної вибірки, вартої цієї назви. Прикре автоматичне повідомлення тут не похибка округлення. Його запам’ятають, поіменно.

Угоди рідко програють через брак ще одного листа з питанням, чи вдалося переглянути пропозицію. Їх програють тому, що вас не було поруч із чимось корисним, коли складали перелік капітальних витрат на наступний рік, тому що технічна відповідь повернулася запізно, або тому що вимогу так і не записали у формі, з якою хтось міг би працювати. Жодне з цього не є проблемою частоти контактів.

Як прочитати RFQ і витягнути з нього вимогу

Запити на пропозицію приходять у тому вигляді, у якому клієнту було зручно їх надіслати: PDF, таблиця, комплект креслень, три абзаци в листі, закупівельний шаблон, у якому мають значення шість полів. Модель надійно витягує те, що присутнє текстом, — кількості й графік вибірок, дати й умови постачання, перелік сертифікатів, комерційні умови, номери деталей, названі в тілі листа, — за той час, поки відкривається файл.

Те, що походить із креслення, — поле іншого класу. Допуски форми й розташування, позначення зварних швів, система баз, шорсткість поверхні, характеристики, позначені як критичні: усе це читається ненадійно, і будь-що зчитане з креслення приходить із позначкою неперевіреної підказки для інженера, а не як значення, за яким можна рахувати ціну. Ставитися до цих двох класів однаково — найшвидший шлях від корисного витягу до помилки в комерційній пропозиції.

Спершу закрийте питання власності. Комплект креслень клієнта — це його інтелектуальна власність, зазвичай під NDA, підписаним задовго до появи запиту, а в авіакосмічній галузі, обороні та частині автопрому він може підпадати під експортний контроль за ITAR, EAR чи регламентом ЄС про товари подвійного використання. Перевірте, що NDA дозволяє щодо обробки та субпідрядників, перш ніж креслення потрапить у модель; тримайте контрольовані роботи на власних серверах або в розгортанні без зберігання даних і без навчання; і залиште шлях виключення, щоб позначені клієнти й сімейства деталей узагалі не потрапляли в обробку.

Цінніша половина результату — це те, чого бракує. Питання, які ви надішлете назад у першу годину, — найсильніший сигнал компетентності, який ви взагалі можете подати, і саме вони не дають інженерові рахувати ціну під припущення, якого ніхто не перевірив.

Корисний витяг від того, який інженер перероблятиме вручну, відрізняють два правила. Кожна позиція посилається на джерело: аркуш і комірка, якщо джерело — таблиця; сторінка й ділянка на ній, якщо це скан. І модель лишає поле порожнім, а не вгадує, — а це частота, яку ви вимірюєте по кожному полю на власному тестовому наборі, а не поведінка, яку отримують вказівкою утриматися від відповіді. Утримання ламається там, де є правдоподібне значення за замовчуванням, — на допуску чи на стандартній шорсткості, — тож поле з низьким утриманням і високою помилкою ви лишаєте людині.

Як скласти першу технічну відповідь, не зобов’язавши компанію

Перша відповідь вирішує, чи ви взагалі в оцінюванні. Добра відповідь називає застосування, а не дякує клієнтові за інтерес, переказує вимогу так, як її зрозуміли, ставить два-три питання, які змінюють відповідь, і фіксує наступний крок із датою.

Модель дає цю структуру за хвилину, а людина редагує й надсилає. Автоматичне надсилання — це інша система, а не інше налаштування тієї самої, і жодна чернетка не називає технічних характеристик: будь-яке число, яке може дійти до комерційної пропозиції, походить від того, хто має повноваження ним зобов’язатися.

Узагальнення історії клієнта й підтримання актуального запису в CRM

Угода, яка триває чотирнадцять місяців, розсипана по сотні листів, трьох візитах, двох пробних партіях і невдалому випробуванні. Історія існує, і ніхто її не читає, тож коли менеджер звільняється, її практична цінність дорівнює нулю. Модель, яка прочитає листування і введе в курс наступну людину, справді корисна.

Вона ж і втрачає частину змісту, і випадає з неї непропорційно часто саме те однорядкове зобов’язання, закопане в середині: допуск, яким поступилися, ціна, зафіксована на названий строк, виняток, узгоджений по телефону. Стислий виклад, який майже правильний і мовчки опускає поступку, гірший за його відсутність. Тож ставтеся до нього як до входу в листування, прив’язуйте кожне твердження до повідомлення, з якого воно взялося, і виносьте зобов’язання в окремий перелік із посиланнями.

Та сама здатність закриває найдавнішу проблему CRM. Продавці не оновлюють записи, бо оновлення — це введення даних, яке нічого не повертає, і відповідь тут та сама, що й для цеху: пропонуй, а не вимагай. Після дзвінка асистент складає чернетку нотатки й пропонує зміну стадії та наступну дію. Вони лишаються пропозиціями, бо асистент, який мовчки править значення чи дати закриття, руйнує єдине, чим CRM зобов’язана бути, — записом, якому люди вірять.

Чи замінює AI-CRM систему, яка у вас уже працює, чи стає надбудовою над нею

Переважно надбудовою. Запис про контрагента, угоду й замовлення лишається там, де він є, — чи то Salesforce, Dynamics, HubSpot, Odoo, чи то CRM-модуль вашої ERP. Асистент читає з цього запису, з поштової скриньки, з архіву комерційних пропозицій і зі сховища документів, а записує назад три речі: нотатку, запропоновану зміну поля і завдання з відповідальним і датою, — усе з авторством і все оборотне.

Тобто проєктом є інтеграція, а не модель, і зазвичай ламається ідентифікатор, який має пережити дорогу між CRM, ERP і системою документів, бо ключ контрагента й номер клієнта ніколи не звіряли. Якщо CRM у вас немає, то спершу CRM: асистент не може тримати в актуальному стані запис, якого не існує.

У чому ШІ не сильний і де він вам коштуватиме

Він не знає ваших можливостей: що допуск досяжний, але лише на другій операції; що сплав налипає у вашому процесі; що названий річний обсяг у кілька разів перевищує все, що цей сегмент коли-небудь замовляв. У нього немає відчуття комерційних наслідків, і впевнене речення про термін постачання він напише так само охоче, як обережне, бо обидва однаково правильні граматично. Не знає він і того, що змінилося після того, як ви передали йому документи, — а це робить актуальність документів операційним обов’язком, а не разовим налаштуванням.

Кваліфікація лідів, яка поважає технічного покупця: чому скоринг — це не кваліфікація

Скоринг виводить число з поведінки: переглянуті сторінки, відкриті листи, завантажені документи. На ринку з такою малою кількістю реальних покупців це здебільшого вимірює цікавість, а профіль, який він винагороджує найнадійніше, — це інженер конкурента, який читає вашу документацію.

Кваліфікація відповідає на інші питання. Чи є застосування, під яке підходить наше обладнання, описане достатньо конкретно, щоб це перевірити. Чи є бюджет і в якому періоді. Хто вирішує і хто може накласти вето. І що станеться, якщо вони не зроблять нічого.

Асистент допомагає лише тим, що ставить питання, на які технічний покупець хоче відповідати. Інженер охоче назве деталь, матеріал, обсяг і час циклу — і покине форму, яка вимагає діапазон чисельності компанії та вилку бюджету. Найбільш недооцінений результат — швидке «ні»: більша частина вартості поганого запиту — це інженерне опрацювання застосування, з’їдене до того, як хтось установить, що воно ніколи не підходило.

Чат-бот, який відповідає з вашої документації, а не вигадує

Спитайте мовну модель про продукт — і вона відповість зі свого навчання, прозою, яка читається точно як ваша документація, без жодного зв’язку між тим, наскільки впевнено це звучить, і тим, чи це правда. У технічному продажі це найгірший можливий збій, бо неправильну відповідь скріншотять, пересилають і цитують вам у відповідь на нараді.

Виживання забезпечує прив’язка до джерел. Питання витягує фрагменти з ваших власних документів, модель відповідає тільки з них і посилається на них, — і це перетворює типовий збій на «я не знайшов цього в документації». Більшість роботи — на боці документів: які документи є чинними, які виведені з обігу й мають бути прибрані з індексу — збережені в системі документів, як того вимагає ваша процедура з якості, але недосяжні для асистента — і які є конфіденційними.

Це не усуває збій. Пошук повертає виведену з обігу ревізію, бо саме вона краще збігається текстуально; повертає правильний документ, а модель неправильно читає в ньому таблицю; не знаходить нічого доречного і все одно відповідає з навчання. Посилання робить кожен із цих випадків гіршим, бо в неправильну відповідь із прикріпленою назвою документа вірять сильніше.

Тому закладайте обмеження в систему, а не в документ політики: відповідати лише з опублікованих матеріалів, називати використаний документ і ревізію, на питання про технічні характеристики відмовляти, а не домислювати, ніколи не давати ціну й термін постачання. І журналюйте кожне питання, на яке він не зміг відповісти, бо цей журнал — написаний вашими клієнтами перелік того, чого ви не опублікували.

Дані, які у вас уже є, і що потрібно, щоб ними можна було користуватися

Їх більше, ніж ви думаєте, і в гіршому стані, ніж ви думаєте. Поштова скринька зберігає роки запитів і технічного листування, історія комерційних пропозицій — що ви пропонували і за якою ціною, а причини програшів — найцінніший набір даних у компанії, якщо їх хтось заповнював чесно. ERP зберігає ваші терміни постачання й дати відвантаження, які варто перевірити, перш ніж їм довіряти: планові проти фактичних і чи не перезаписували обіцяну дату щоразу, коли вона зривалася.

Далі — їхній стан. Той самий клієнт існує тричі в різних написаннях, а німецька дочірня компанія — окремий контрагент без зв’язку з материнською, тож ніхто не бачить, що група вже купила дві лінії. А причина програшу в більшості записів — «ціна», і саме це люди обирають, коли справжньою причиною була повільна відповідь.

Робота непоказна, і вона становить більшу частину проєкту: усунути дублікати контрагентів, змоделювати структуру груп, домовитися про одне авторитетне місце зберігання документації з явним полем ревізії, замінити вільний текст причини програшу коротким переліком, з якого продавець може вибрати чесно. Модель, побудована на цих даних, успадкує кожну помилку й видасть її впевнено.

Передача людині й чому погана передача знищує всю цінність

Момент, коли асистент зупиняється й починає людина, — це те місце, де клієнт судить про систему в цілому. Клієнт детально пояснює своє застосування, продавець телефонує за два дні і ставить ті самі питання спочатку — і все, що виграла автоматизація, витрачається за цю хвилину.

Передача, яка працює, несе з собою розмову, прикріплену до угоди, питання, яке спричинило ескалацію, названого відповідального замість спільної скриньки і час реакції, за який хтось відповідає. Будьте чесні щодо того, чим є асистент, бо технічний покупець розбереться за кілька реплік, і піднімайте на людину автоматично при будь-якому зобов’язанні щодо характеристик, будь-якій ціні, будь-якій рекламації і щоразу, коли клієнт питає вдруге.

Чесне вимірювання: час відповіді й кваліфікований пайплайн, а не кількість надісланих повідомлень

Більшість звітності за такими системами вимірює їхню власну активність: надіслані повідомлення, оброблені розмови, зекономлені години за множником, який дав постачальник. Усе це зростає незалежно від того, чи щось покращилося. Почніть натомість із часу від запиту до першої змістовної технічної відповіді, де змістовна означає, що вона говорила про застосування, а не підтверджувала отримання. Далі — час від RFQ до комерційної пропозиції по тих запитах, які ви прийняли як профільні, і частка тих, що дійшли до пропозиції: це показує ті, що вмирають у черзі в інженера.

Відхилені запити міряйте окремою віссю — за скільки днів їх відхилили, бо саме це число швидке «ні» й існує, щоб зменшувати. Єдиний показник конверсії в пропозицію по обох знаменниках каже організації рахувати ціну на ті запити, які ви щойно веліли їй відхиляти. Далі — кваліфікований пайплайн за визначенням кваліфікованості, записаним до початку проєкту, і кількість питань, на які асистент не зміг відповісти: вона має падати в міру того, як ви публікуєте те, чого бракувало.

GDPR і чого очікує європейський промисловий покупець

Правова підстава для B2B-розсилок у Європі не єдина. Національні імплементації правил ePrivacy різняться, і в частині країн-членів незапитаний комерційний лист на робочу адресу трактується набагато суворіше, ніж припускає звичний переказ про «легітимний інтерес». Вирішуйте це з юристом по кожному ринку і будуйте систему так, щоб правила могли відрізнятися по країнах без переписування.

Решта — інженерні рішення з наслідками для закупівель. Опитувальник покупця спитає, де обробляється текст його запиту, чи виходить він за межі ЄС, чи навчає він чиюсь модель і скільки зберігається. Через перший фільтр вас проводять чотири короткі відповіді: обробка в ЄС, навчання на контенті клієнтів не ведеться, визначений строк зберігання, доступ журналюється. За фільтром стоять підписаний DPA, перелік субпроцесорів, ваші технічні й організаційні заходи і зазвичай сертифікат ISO 27001 або SOC 2. Зберіть їх до того, як прийде запит.

Тримайте людину в контурі будь-якого рішення, що відхиляє запит, — це і правильна конструкція, і кінець суперечки про автоматизоване ухвалення рішень. Крім правового боку, європейський промисловий покупець очікує, що з ним поводитимуться як із фахівцем, а вигадане «повертаюся до нашої розмови» шкодить на малому технічному ринку більше, ніж якби ви не написали нічого.

З чого почати: перший проєкт із ШІ у продажах

Один процес, вісім-дванадцять тижнів, один названий відповідальний у продажах і один в інженерії, і письмове визначення успіху до того, як щось будується. Почніть із маршруту вхідних RFQ: цінність зосереджена саме там, а збої першими бачать ваші власні люди.

Перші два тижні витратьте на те, щоб зібрати п’ятдесят реальних RFQ за останні два роки — разом із тим, що по них рахували і чим усе скінчилося. Цей набір і є тестом, а без нього ви оцінюєте демонстрації, підібрані тим, хто їх будував. Далі зробіть витяг і перелік відсутньої інформації, які інженер із застосування звірить із тим, чим вимога виявилася насправді. Асистент, що спілкується з клієнтом, іде останнім, бо тільки він говорить із клієнтами без нагляду.

Критерії виходу напишіть до початку: час першої відповіді по названому сегменті, інженерні години на один RFQ і витяг, оцінений порівняно з цим еталонним набором, — точність по кожному полю і передусім повнота на полях, які несуть ризик помилки в ціні. Частка прийнятих підказок моделі — це сигнал засвоєння інструмента, а не критерій виходу: щойно інженери дізнаються, що це і є оцінка, граничні правки припиняються, а помилки, які мають значення, — це пропуски, яких не спіймає той, хто побіжно переглядає охайний список. Вирішіть заздалегідь, від чого ви відмовитеся: масові вихідні розсилки, будь-що, що надсилає без перевірки, робота там, де правова підстава чи позиція за NDA лишаються відкритими.

Де тут Meta Smart Factory

META CRM Bot від MSF — це продукт на боці продажів у цій платформі; решта модулів на цьому сайті — MES, APS, MRP, якість, технічне обслуговування, склад — керують заводом. Ми будуємо обидві половини, і саме тому наведений вище аргумент про послідовність і якість даних, а не про функції.

Одну річ варто назвати, а не обійти: цей продукт описаний тут як багатомовне листування в режимі 24/7, і в технічному продажі це не та частина, яку вмикають першою. Обмеження, про які йшлося вище, — це конфігурація, а не маркетинг: чернетка від моделі й надсилання людиною, ескалація на будь-якому зобов’язанні щодо характеристик, ціни чи термінів, жодних масових вихідних розсилок на ринок, де ті самі прізвища повторюються. Вимагайте їх у пілоті.

Думати варто про стик. У промисловому запиті домінують два питання — чи втримаєте ви цю характеристику при такій продуктивності і чи буде воно тут на 34-му тижні, — і на жодне з них асистент відповідати не повинен. Перше — це придатність процесу за конкретною характеристикою, верстатом і пристосуванням, з дослідженням вимірювальної системи, яке не з’їдає половину поля допуску, а на новій деталі історії, з якої можна відповісти, просто немає. Друге — питання майбутньої потужності проти портфеля замовлень, який змінюється щодня. Історична своєчасність постачання — це не потужність, а сьогоднішня потужність — не потужність на 34-му тижні.

Що асистент може — це дістати докази й покласти їх перед людиною, яка відповідає. Виміряні часи циклу й брак на найближчій порівнянній деталі скажуть вашому інженерові, чи виправдовує запит дослідження придатності; портфель замовлень в APS скаже вашому планувальникові, чи 34-й тиждень узагалі правдоподібний. Дату все одно називає планувальник. Якщо виробничому запису не можна довіряти, надбудований над ним шар ШІ у продажах усе одно рахуватиме ціну з нього.

Тому кориснішою першою розмовою є не демонстрація. Це розбір ваших власних недавніх RFQ і того, що сталося з кожним, бо це за один вечір показує, де продаж втрачає час, — і іноді відповідь у тому, що це не та частина, яку може виправити програмне забезпечення.