В одному абзаці
Відділ продажів із 5 людей раніше збирав списки контактів для розсилок вручну – за компанією, регіоном, рівнем посади й роллю, по 30–60 хвилин на список. І добре це виходило лише в однієї людини: тільки вона вільно орієнтувалася в усіх джерелах. Тепер досить одного повідомлення в Slack-каналі команди й хвилини-трьох очікування: продавець пише людською мовою, агент сам вирішує, де шукати, робить пошук, відсіює тих, хто вже є в CRM, і відповідає в гілці готовою таблицею. Близько 1000 контактів на тиждень тепер отримує команда, яка раніше робила все це руками. На правильну форму пішло 8 місяців доопрацювань і 3 покоління агента – і дорогою ця робота довела платформу автоматизацій до справжньої межі того, що вона здатна потягнути.
Проблема мовою бізнесу
У невеликого відділу продажів пошук нових клієнтів гальмує не брак даних, а вміння їх добути. Треба пам’ятати, яка база покриває який регіон, де ще є живі імейли і як звірити результат з угодами, які команда вже веде, – а потім робити все це заново для кожного списку. Скласти сам пошук – найменша частина роботи; пів години з’їдають стрибки між інструментами й ручна звірка. А коли це вміння живе в голові однієї людини, скільки нових клієнтів команда встигне охопити, залежить від того, скільки вільної уваги лишається саме в неї.
- Продавець налаштовує пошук у базі контактів і вивантажує CSV.
- Вручну відсіює тих, хто вже є в CRM, компанію за компанією.
- Іде шукати відсутні імейли в професійній соцмережі.
- 30–60 хвилин на список; вільно почувається в усіх інструментах лише одна людина в команді.
- Кожен список – разова робота; ніде не записано, що просили і що видали.
- Продавець пише один рядок у Slack-канал, яким і так користується.
- Агенти-спеціалісти шукають, відсіюють тих, хто вже є в CRM, і доповнюють контакти за один прохід.
- Відсутній імейл з'являється там, де його можна перевірити; де не можна – клітинка лишається порожньою й позначеною.
- Хвилина-три від запиту до таблиці; спитати може кожен у каналі.
- Кожен запуск лишає таблицю і запис у журналі виконань.
Чим це відрізняється від «чат-бота, під’єднаного до кількох API»
Агент не дає одній моделі довгий список із десятка інструментів у надії, що під навантаженням вона вибере правильний. Джерела контактів розподілені між кількома операторами-спеціалістами: один відповідає за доповнення контактів і CRM, другий – за довгий збір даних із професійної соцмережі, третій – за підсумкову таблицю. А диспетчер, який читає повідомлення продавця, вирішує лише одне: якого оператора покликати. Тому інструкція для планування лишається короткою, модель ніколи не пише в таблицю посеред пошуку, а нове джерело – це новий оператор, а не ще один рядок, який доведеться перечитувати всім. І кожен із цих агентів працює на двох моделях – гострішій основній і стабільнішій запасній. Якщо найновіша модель у постачальника раптом збоїть, продавець, який чекає в чаті, отримає трохи менш кмітливу відповідь, а не глухий кут.
Друге, про що подбано в задумі, – обсяг інформації, бо агент, який шукає потенційних клієнтів, перемелює її дуже багато. Модель ніколи не складає запит до сервісу сама, рядок за рядком: запит складає сервер, а модель дає лише текст пошуку, і цілий клас збоїв через неправильно складені запити просто зникає. Сервер обмежує кожен пошук розумною кількістю результатів; агент має зупинитися після кількох спроб, а не розширювати впертий пошук до тисяч рядків. І найважливіше рішення: кожен оператор повертає диспетчерові лише фінальний, зведений список контактів, а не всю сировину, яку перебрав. У першій версії цього правила не було, і одного разу через важку для пошуку ціль оператор віддав диспетчерові 5 мегабайтів сирих збігів – і контекст моделі (усе, що вона здатна охопити за один раз) просто переповнився. Виправили це не більшою моделлю, а тим, що диспетчер почав бачити менше.
| критерій | Нагору йде вся сировина від постачальників | Лише фінальний, зведений список від кожного оператора обрано | Проміжні підсумки під час роботи |
|---|---|---|---|
| Скільки токенів диспетчер витрачає на запит | без меж | обмежено · мало | середньо |
| Вміщається в контекст моделі | ні | так | частково |
| Контакти, які бачить диспетчер | усі | усі | частково |
| Можна розібратися, коли запуск пішов не так | так | так | частково |
| Токени, витрачені на відкинуті рядки | кожен рядок | жодного | частина |
Бюджет токенів на один запит
Агент, що шукає потенційних клієнтів, перемелює багато даних. Задайте, скільки контактів просите, наскільки наполегливо агент шукає і скільки важить кожен сирий збіг, – а тоді порівняйте, що бачить диспетчер, коли нагору йде вся сировина, і коли лише зведений список. Саме через цю різницю той упертий пошук і переповнив контекст моделі.
працює у вашому браузері · 0 мережевих запитів · щоразу той самий результат
Три запити з каналу продажів
Три запити поспіль із каналу продажів, трохи причесані. Агент
розбирається, вирішує, діє і звітує в гілці: два з трьох закінчуються
рядком success, а третій – чіткою, свідомою відмовою. Вступ праворуч
лишається на місці, поки кожна сцена підхоплює наступний запит.
Перед першим запитом
Sales-intel agent живе у звичному Slack-каналі відділу продажів і за хвилину-три перетворює запит в один рядок на таблицю контактів без дублікатів, де в кожного імейла чесно вказано джерело. Ні окремої панелі, ні окремого логіна: хто є в каналі, той і має доступ, а все навчання – написати, що тобі треба.
Кожен запуск починається з двох файлів. routing-prompt.md вчить диспетчера читати запит і розуміти, який оператор за яку роботу відповідає; operators.roster – це перелік операторів-спеціалістів і вузького набору інструментів кожного. Сам диспетчер ніколи не лізе в джерела даних: він роздає роботу, а потім складає результат докупи.
Три запити нижче показують агента в тому, що важить найбільше: головна робота – знайти людей, які ухвалюють рішення у двох компаніях, і впорядкувати їх за вагою; продовження тієї самої розмови в ту саму таблицю; і запит, який агент відхиляє, бо виконати його означало б порушити умови користування платформою.
Показати цей кейс публічно дозволяє саме довіра: дані контактів не виходять за межі CRM і Google-сервісів компанії, агент працює за корпоративним VPN, а кожен запуск записується там, де виконується. Тож журнал, за яким шукають помилки, водночас служить і журналом аудиту.
Головний запит – короткий список, найважливіші зверху, без дублікатів і вигадок
Заради цього запиту агент і існує. Продавець називає дві цільові компанії й мінімальний рівень посади, а у відповідь отримує чисту таблицю лише з новими іменами, де ті, хто ухвалює рішення, стоять зверху. Команді більше не треба знати, яка база покриває який регіон і де ще є живі імейли, – тепер це турбота агента.
Тут працюють два тихі правила. Спершу агент заглядає в CRM і викидає контакти, які в команди вже є, тож у таблиці лишаються тільки люди, з якими варто працювати. А якщо імейл людини перевірити не вдається, клітинка лишається порожньою з позначкою Email Status: unavailable – вгадувати агент не стане.
На другому правилі тримається все, і цього навчилися на власній
помилці. Модель, яка бачила [email protected] у трьох колег,
залюбки вигадає таку саму адресу для четвертого, а вигаданий імейл у
списку для розсилки гірший за порожній. Тому правило записане в
інструкції для моделі й підстраховане кодом: лише імейли, які повернув
постачальник даних, а його власний статус перевірки копіюється в окрему
колонку. Порожня клітинка виглядає так, ніби агент не впорався; вгадана
– ніби впорався, аж доки лист не повернеться назад і не зіпсує
репутацію домену, з якого йдуть розсилки. Чесні порожні клітинки
цінніші, і саме це суперечить інтуїції.
Для бізнесу: поки продавець доливає собі кави, він отримує впорядкований список без дублікатів і з чесно вказаним джерелом кожного імейла – і йому не доводиться гадати, справжня адреса, що світиться зеленим, чи вигадана.
Розмова триває – у ту саму таблицю
Саме продовження показує, що це помічник, а не одноразова форма. У проханні «Add CxOs at two more accounts to that same table» немає ні посилання на таблицю, ні повтореного фільтра: агент пам’ятає таблицю, яку щойно зробив, і планку, яку щойно застосував, і дописує нові рядки знизу.
Тут добре видно, як агент береже токени. Одна з нових компаній величезна, і наївний агент розширював би пошук, доки не отримав би сотні рядків. Цей обмежується вищим керівництвом (C-suite), зупиняється після трьох пошуків і дописує дев’ять рядків, замість того щоб витратити купу грошей і повернути шум. Стриманість тут – перевага, а не обмеження.
Дописати в наявну таблицю замість створювати нову – дрібниця, але саме через неї результат відчувається як робочий документ, що росте, а не як купа разових вивантажень. Після двох повідомлень у продавця одна таблиця на чотири компанії.
Для бізнесу: саме тяглість розмови перетворює інструмент пошуку на те, по що команда тягнеться не замислюючись. Другий запит коштував лише частку першого, бо більша частина контексту вже була під рукою.
Запит, який агент відхиляє, – і чому це його сильна сторона
Найбільше заспокоює, коли автономний агент уміє чисто відмовити. На прохання витягти контакти всіх людей зі збереженого списку Sales Navigator агент каже «ні» – і пояснює, що він робитиме, а чого ні.
Він уміє розбирати результати пошуку Sales Navigator – сторінки, які видає фільтр. Збережений особистий список – зовсім інша річ: щоб його опрацювати, довелося б відкривати профілі окремих людей під обліковим записом того, хто просить, а це порушує умови користування платформою. Ця межа – свідомо проведена лінія, а не відсутня можливість, яку команда могла б собі ввімкнути.
І на цьому розмова не обривається: агент пропонує шлях за правилами – вставити посилання на пошук або назвати фільтри, і тоді він запустить пошук сам. Продавець однаково отримує потрібних людей, просто дорогою, яка нікого не виводить за межі правил.
Для бізнесу: інструмент продажів, який потай збирав би дані з особистих профілів, був би ризиком, переодягненим у зручність. Агентові, який знає, де межа, і сам її оминає, навіть коли його про це не просять, можна дозволити працювати з усією командою без нагляду.
Що вже працює
- ● 01Диспетчерчитає запит · обирає оператора · сам ніколи не лізе в джерела
- ● 02Оператор запитівдоповнення контактів · звірка з CRM · пошук у вебі
- ● 03Оператор таблицістворює таблицю з шаблону · дописує рядки · відповідає в гілці
- ● 04Оператор професійної мережіасинхронно: запустити збір і дочекатися · результати пошуку Sales Navigator
- ● 01Додавання данихсам зіставляє колонки під час дописування · службові ключі маршрутизації прибирає перед записом
- ● 02Збери й зачекайзапуск → перевірка кожні 30 с → не довше 5 хвилин → розібраний результат або зрозуміле повідомлення про збій
У таблицю пишуть два незалежні шляхи: оператор запитів, якому назви колонок задає інструкція для моделі, і збирач даних, якому їх задає звичайний код, що завжди поводиться однаково. Обидва дописують у копію того самого шаблону, і обидва треба правити одночасно щоразу, коли в шаблоні з’являється нова колонка, – інакше один із них мовчки писатиме в нікуди. Попередні покоління агента не видаляють, а лишають на платформі вимкненими, тож і через місяці видно, чим одне покоління відрізняється від іншого. А окрема тестова копія бере на себе ризиковані експерименти, перш ніж вони дістануться до робочої схеми.
- ○ 01Окремий сервіс · типізовані входи й виходи інструментівповністю прибирає збої через неправильно складені запити
- ○ 02Пам'ять про компанії й людейвласна база доповнених контактів, що постійно росте, – повторне звертання нічого не коштує
- ○ 03Обмеження вартості кожного запускужорстка межа бюджету · видно, скільки коштує кожен контакт
- ○ 04Набір еталонних перевіроктести на еталонних запитах, які ловлять погіршення, – платформа автоматизацій такого не дає
Два незалежні шляхи запису в таблицю – одним керує інструкція для моделі, другим код – доводиться правити одночасно щоразу, коли в шаблоні з’являється колонка. Ця вимушена синхронність – найчіткіший знак, що логіка переросла платформу автоматизацій. Позбутися її – половина причини, чому наступну версію пишуть звичайним типізованим кодом.
Надійність виросла зі справжніх збоїв
Сервіси, до яких звертається агент, кращими не стали; надійність з’явилася тому, що кожен справжній збій у роботі виправляли на рівні архітектури. Три запуски – три виправлення в самій будові системи:
| запуск, який… | що зламалося | як це виправили в архітектурі |
|---|---|---|
| гнався за важкою ціллю | оператор розширював пошук, поки не набрав тисячі рядків, і віддав диспетчерові ~5 МБ сирих збігів – далеко за межею контексту моделі в 1M токенів | оператори повертають лише зведені контакти, ніколи сировину; кількість результатів обмежує сервер; після трьох пошуків – зупинка |
| повірив закономірності | модель вигадала три правдоподібні імейли за зразком адреси колеги first.last@ і позначила їх як перевірені | лише імейли, які повернув постачальник, – це записано в інструкції й підстраховано кодом; статус перевірки від постачальника копіюється в окрему колонку |
| не зміг знайти контакт | агент викликав той самий інструмент доповнення контактів, доки не вперся в ліміт кроків, і весь запуск упав із помилкою | ніколи не викликати той самий інструмент двічі з тими самими даними; коли ліміт вичерпано – віддати вже знайдене, а не валити весь запуск |
Кожне виправлення зменшувало кількість місць, де один невдалий крок міг зірвати запит, – і жодне з них не було більшою моделлю. Ще на початку впровадження, за два тижні поспіль, частка помилок упала з 13% до 4%, коли запасна модель з’явилася в кожного агента. Інтеграції кращими не стали: просто той тип збоїв, що переважав у поганий тиждень, тепер гаситься там, де продавець його ніколи не побачить. Коли з’явився постачальник даних, який здавався дешевшим, його теж не взяли на віру: живий тест порівняв справжню вартість одного контакту з тим, що обіцяла реклама, чинний постачальник виграв стабільністю, а альтернативу лишили про запас – під’єднати її можна за один крок, щойно ситуація зміниться.
Агент працює на платформі автоматизацій, тож кожен запуск і так записується там, де виконується: який оператор працював, з якими параметрами, скільки часу це забрало, успіх чи збій. Той самий журнал, за яким шукають помилки, відповідає й на питання що агент робив минулого вівторка зі списком для Латинської Америки? – і окремо налаштовувати це не довелося.
Аналітик, завжди на зв’язку в каналі продажів
Цей агент довів, що в команди продажів із 5 людей може бути власний аналітик-дослідник, який завжди на зв’язку в її чат-каналі: відсіює тих, хто вже є в CRM, упорядковує людей за посадою, відмовляється вигадувати імейли й відхиляє запити, що порушили б правила платформи, – і все це без нагляду. А ще це свідомо майже максимум того, що варто доручати платформі автоматизацій: 4 агенти, 2 шляхи запису, які треба правити одночасно, і бюджети токенів, які стережуть вручну, – ознаки системи, що заслужила стати повноцінним окремим сервісом. Наступну версію вже окреслено як окремий проєкт; ця доводить, що форму знайдено правильно.
8 місяців. Одна людина. 4 агенти за одним вікном чату. ~1000 контактів на тиждень, без дублікатів і з чесно вказаними джерелами – і чітка межа там, де закінчується платформа автоматизацій і починається наступна розробка.
Цей кейс – про архітектуру й підходи. Клієнта, його відділ продажів і конкретних постачальників даних свідомо не названо; компанії, які фігурують у демо як потенційні клієнти, – публічні фірми, і їх узято лише для того, щоб приклад був живим. Тут важить устрій системи, а не те, у кого що купували.