Уяви звичайний понеділок. У пошті лежить лист від клієнта: він просить перенести зустріч і додати ще одну людину. У CRM - програмі, де команда веде клієнтів і продажі, - досі стоїть старий час. У таблиці менеджер уже написав «узгоджено». Ти показуєш AI-асистенту всі три джерела, а він упевнено пропонує четвертий варіант: надіслати підтвердження вільного слота.
Виглядає так, ніби помилився AI. Насправді він отримав суперечливі вказівки й не знає, яке з них має останнє слово. Якщо дати йому право діяти, він може не просто сформулювати невдалий текст, а змінити стан угоди, створити задачу не тій людині або залишити команду з двома різними домовленостями.
Саме тому перед розробкою варто провести process audit - коротко розібрати, як робота насправді переходить від однієї людини та системи до іншої. Це не перевірка, чи «достатньо сучасна» твоя CRM. Це спосіб не доручати новому інструменту процес, правила якого досі живуть у головах команди.
1. Модель бачить дані, але не завжди бачить їхню вагу
AI добре вміє читати листи, знаходити в них запит, стисло пояснювати зміст і пропонувати наступну дію. Але між «прочитати» та «змінити робочий запис» лежить важливий кордон.
Schnittstelle - німецьке слово для інтеграції, тобто місця, де дві системи обмінюються даними. Саме тут найчастіше губиться контекст. Один сервіс передає ім’я клієнта без номера угоди. Інший не повідомляє, що запис уже закритий. Третій приймає будь-яке оновлення, хоча його мав робити лише відповідальний менеджер. AI не може чесно вгадати правило, якого ніхто не записав.
Проблема часто не в самому обміні даними, а в його сенсі. Наприклад, у CRM поле «етап» може означати, що менеджер підготував пропозицію. У таблиці таке саме слово може означати, що клієнт уже погодив її. Технічно обидва записи можна передати між системами. Але автоматизація не відрізнить робочу позначку від рішення, якщо ти цього не визначиш.
Стара система - не вирок
Це не проблема лише старих програм. Опитування Zapier серед великих компаній називає перешкодами для впровадження AI складні інтеграції зі старими системами, вартість, залежність від постачальника та нестачу потрібних навичок. Висновок для малого B2B-бізнесу простіший: не треба оголошувати наявну систему непридатною. Треба перевірити конкретний перехід - що входить, що змінюється, хто це підтверджує і що виходить.
Наприклад, у компанії з Gebäudereinigung - професійного прибирання будівель - заявка може прийти через форму на сайті, лист або дзвінок. Якщо всі три канали зрештою потрапляють у CRM, AI може лише читати нові заявки, витягати адресу та тип об’єкта і готувати чернетку картки. Але якщо менеджер ще звіряє район обслуговування у власній таблиці, агент не має самостійно створювати обіцянку клієнту. Він може показати невідповідність і попросити рішення.
Інший приклад: якщо в листі клієнт погодив ціну, а в CRM досі інша сума, автоматичне надсилання договору - поганий перший крок. Натомість корисний перший запуск може зібрати такі розбіжності в один список для менеджера. Ти не втрачаєш контроль, зате бачиш, де саме процес розходиться: у листуванні, у внесенні даних чи в правилі, за яким команда вважає суму остаточною.
2. Шість питань, які варто пройти до будь-якої розробки
Process audit не потребує технічної лекції. Візьми один повторюваний процес: обробку нової заявки, погодження комерційної пропозиції, розбір пошти або передачу проєкту у роботу.
Корисно розбирати не уявний ідеальний процес, а один недавній випадок. Відкрий лист, картку в CRM і той документ, у якому команда щось уточнювала. Тоді швидко видно не лише офіційний маршрут, а й обхідні ходи: повідомлення в месенджері, ручне копіювання номера, домовленість «я потім оновлю». Не намагайся одразу описати всю компанію або готувати довгу презентацію. Обери момент, де команда регулярно копіює, перепитує або шукає останню версію.
Далі пройди шість питань у порядку реальної роботи.
- Звідки стартує запит? Запиши не «з ліда», а конкретно: з форми, листа, дзвінка, месенджера чи вручну створеної картки. Це допоможе не забути канал, який існує лише тому, що «так зручніше».
- Яке джерело є Quelle der Wahrheit - записом, якому довіряють, коли дані суперечать одне одному? Для ціни це може бути затверджена пропозиція, для статусу угоди - CRM, для дати виїзду - календар. Якщо відповіді немає, не давай AI змінювати цей стан.
- Які переходи стану існують? Назви їх просто: «нова заявка», «потрібне уточнення», «пропозицію надіслано», «погоджено», «закрито». Біля кожного переходу запиши, що має статися, аби перейти далі. Не «коли все готово», а «клієнт письмово погодив суму».
- Хто володіє кожним переходом? Власник - не людина, яка іноді допомагає, а та, хто має право сказати: «так, тепер статус змінився». Якщо власника немає, AI доведеться вгадувати відповідального або орієнтуватися на останню випадкову дію.
- Де AI може читати, а де записувати? Leserecht - право лише переглядати дані; Schreibrecht - право їх змінювати. На старті корисніше дати AI Leserecht ширше, а Schreibrecht - вузько або взагалі не давати. Так ти перевіряєш правило на реальних винятках, не ставлячи під удар важливі записи.
- Які випадки не вкладаються в нормальний шлях і чим завершується робота? Запиши хоча б ті винятки, що згадує команда: дубль заявки, клієнт змінив умови, даних бракує, контракт уже є, доступ заборонений. Окремо назви доказ завершення: лист відправлено й збережено, задача має виконавця, запис оновлено в джерелі правди, людина підтвердила рішення.
Не треба малювати складну схему. Достатньо одного аркуша або спільного документа, де для кожного кроку видно: вхід, джерело правди, відповідальний, дозволена дія, виняток і доказ завершення. Така карта цінніша за красивий demo, бо показує, що саме треба будувати, а що спершу слід узгодити без жодної розробки. Якщо на запитання «хто може змінити статус?» двоє людей відповідають по-різному, це вже результат. Не сперечайся з AI про точність відповіді. Спочатку узгодь правило вручну, внеси його в робочий опис і лише потім передавай автоматизації.
3. Першим запуском має бути безпечна перевірка, а не заміна команди
Canary - невеликий контрольований запуск, який перевіряє ідею на вузькій ділянці, не віддаючи їй увесь процес. Для AI він особливо корисний там, де результат можна прочитати, перевірити та скасувати.
Хороший canary має три ознаки. Він бере один тип вхідних даних, не змінює критичний запис без людини й залишає слід, за яким можна зрозуміти, чому з’явився результат. Наприклад, AI читає листи з темою «запит», витягає факти лише з самого листа та готує чернетку відповіді разом із посиланням на джерело. Менеджер затверджує або відхиляє її вручну. Так працює приклад розбору пошти Klar: у ньому важливі не лише підказки AI, а й прив’язка до доказів і людський контроль.
Перед таким запуском домовся, що саме вважатимете помилкою. Не абстрактне «погано написав», а зрозумілі випадки: не знайшов обов’язкову деталь у листі, переплутав клієнта, запропонував дію без джерела або відправив у чергу те, що не належить до її теми. Тоді людина, яка перевіряє результати, не просто виправляє все мовчки, а повертає процес до конкретного правила.
Межа безпечного запуску
Поганий canary виглядає інакше: «нехай агент сам веде всі ліди». У ньому занадто багато різних правил, каналів і наслідків. Коли щось піде не так, ти не зрозумієш, чи помилилося розпізнавання листа, інтеграція, правило маршрутизації або право запису. Такий запуск схожий на ремонт проводки у всій будівлі одним вимикачем: світло може з’явитися, але шукати причину потім буде невесело.
Якщо тобі все ж потрібна дія в системі, обери зворотну. Наприклад, AI не змінює бюджет угоди, а ставить тег «потрібна перевірка»; не надсилає рахунок, а створює чернетку; не закриває задачу, а додає її до черги на підтвердження. Перед запуском визнач, хто переглядає цю чергу і як скасовує хибну дію. Без цього «автоматично» інколи означає лише «помилка встигла побігти раніше за тебе».
Розділення ролей теж важливе. У хорошому робочому процесі ти лишаєш за людиною рішення й відповідальність, асистенту доручаєш підготовку, а агенту - обмежену дію за заданим правилом. Саме таке розділення між людським лідерством, підтримкою асистента й автоматизацією агентом пропонують у підходах до дизайну робочих процесів і правил керування ними.
4. Що має залишитися після розбору процесу
Результат не повинен бути звітом, який зручно покласти в папку й забути. Він має стати коротким робочим описом, за яким ти й команда можете прийняти рішення.
Залиш собі карту одного процесу з шістьма полями: джерело запиту, джерело правди, стани, власник, права AI, винятки та доказ завершення. Додай до неї межу першого запуску: що саме AI читає, що пропонує, чого не змінює і хто перевіряє результат. Окремо познач, де потрібне рішення людини, а де достатньо заздалегідь погодженого правила.
Цей опис корисний не тільки розробнику. Новий менеджер за ним розуміє, куди дивитися за актуальною ціною. Власник процесу бачить, які рішення зависають між ролями. Людина, що відповідає за доступи, може дати інструменту рівно ті права, які потрібні для першої задачі. А ти можеш порівняти пропозиції виконавців не за обіцянкою «все інтегруємо», а за тим, чи вони бачать реальні межі процесу.
Після цього може виявитися, що автоматизацію поки не варто будувати. Наприклад, якщо комерційні умови затверджують у чаті без єдиного запису, а менеджери по-різному називають статус «готово», спочатку домовся про ручне правило. Це не поразка й не відмова від AI. Це спосіб прибрати зламану передачу, перш ніж додавати до неї ще один сервіс. Зламаний процес і без AI достатньо винахідливий: він здатен загубити відповідального навіть у трьох вкладках.
Контрольований workflow уже може бути доказом, що команда вміє будувати процес із перевірками. Але він не доводить, що будь-яку наступну задачу можна безпечно віддати агенту. Тому контрольовані AI-системи варто оцінювати не за видовищністю першого екрана, а за тим, чи зрозуміло, де агент зупиняється, хто бачить його дію і що підтверджує результат.
5. Почни з одного місця, де команда шукає правду
Не починай із питання «якого AI нам купити?». Відкрий один реальний процес, у якому люди часто звіряють пошту, CRM і таблицю. Візьми останній приклад, на якому хтось перепитував «який статус правильний», і запиши поруч, де мала бути одна правда, хто міг її змінити та чого бракувало для завершення.
Не потрібно одразу вирішувати, яку систему замінювати або як з’єднати все між собою. Твоє перше завдання - назвати межу проблеми так, щоб її впізнала команда. Коли для одного випадку є джерело правди, власник і доказ завершення, з’являється безпечне місце для малого запуску.
Це і є перший крок. Коли він зроблений, AI перестає бути вгадувачем між трьома версіями реальності й може стати корисним помічником у чітко окресленій роботі.