Технологии в Продажах

Ваш будущий клиент ещё не открылся. А ему уже нужно то, что вы продаёте 👀

Мы сделали агента, который помогает находить такие компании.

Заказчик — B2B-компания, которая работает с малым и средним бизнесом в HoReCa за рубежом. Она предоставляет инфраструктурное решение, которое необходимо бизнесу в этом сегменте: будущий клиент выберет либо её, либо конкурентов.

Но найти его в нужный момент непросто. Когда заведение уже открылось, поставщик может быть выбран и договор подписан.

Поэтому мы решили искать сигналы того, что бизнес только готовится к открытию

Чтобы менеджер мог позвонить с конкретным поводом:

«Видим, что вы готовитесь открываться. На этом этапе вам понадобится такое решение. Давайте обсудим».

Звучит довольно просто. Но на практике пришлось проверить много гипотез 😅

Например,

появление компании в государственном реестре казалось хорошим сигналом. В нашем кейсе оно оказалось бесполезным для определения скорого открытия: сама регистрация ещё не означала, что перед нами подходящий клиент.

А когда находили перспективный бизнес, возникала следующая задача — найти контакты и убедиться, что они относятся именно к нему.

В итоге мы нашли сочетание сигналов, которое помогает выявлять будущих клиентов в нужный момент, и автоматизировали процесс.

Систему развернули на серверах заказчика. Она постоянно отслеживает источники и раз в неделю передаёт команде список лидов. Менеджеры звонят и уже получают новый бизнес.

Почему раз в неделю? Потому что больше контактов команда пока не успевает обзванивать. Теперь частоту выдачи определяет загрузка продаж.

В карточках подробнее разобрал, как мы к этому пришли 👇🏻

А в вашем бизнесе есть событие, после которого клиенту почти неизбежно понадобится ваш продукт?

Этому клиенту пока не надо писать ✋🏻

Всем знакома ситуация, когда в CRM накопились сделки, по которым давно никто не общался.
Менеджер решает написать всем: «Добрый день! Наше предложение ещё актуально?»

Но один клиент просил связаться через три месяца. Другому не подошёл продукт. А третий до сих пор ждёт ответ на свой вопрос.

Прежде чем писать, стоит открыть переписку и вспомнить, почему разговор остановился. От этого зависит, что делать дальше 👇🏻

Вот три примера 👇🏻

💸 «Бюджет появится в следующем квартале»

Клиент сказал: «В этом квартале денег на покупку нет. Давайте вернёмся к разговору в следующем».

Писать ему каждые две недели «Ну что, есть новости?» смысла мало — бюджет от этого не появится))

Лучше сразу договориться, в каком месяце связаться, и поставить себе напоминание в CRM.

⚙️ «Нам нужна интеграция с нашей CRM»

На встрече выяснилось, что без неё продукт не подходит. Прошло два месяца, интеграция так и не появилась.

Скидка и новая презентация вряд ли что-то изменят: сотрудникам клиента всё ещё придётся переносить данные руками.

Повод написать появится, когда вы сможете решить эту задачу.
Например, выпустите нужную интеграцию или найдёте рабочий вариант подключения. Тогда и возвращаться можно конкретно: «Помню, у нас всё остановилось на обмене данными с CRM. Теперь можем показать, как он работает».

💬 «А как вы перенесёте нашу базу?»

Менеджер пообещал уточнить у технической команды. Закрутился, не ответил и через месяц записал клиента в остывшие.

Вот этому человеку стоит написать уже сегодня. Начать с ответа на его вопрос и признать, что задержался.

Клиенту пока даже не дали информацию, без которой он не может принять решение.

Поэтому перед тем, как возвращать старые лиды, я бы проверил: на чём именно остановился каждый разговор?

Здесь полезен ИИ: можно дать ему историю общения, чтобы он помог найти причину паузы, согласованную дату и незакрытые вопросы. А дальше уже сверить: что изменилось у нас и есть ли с чем идти к клиенту.

В одной сделке пора показать новую функцию. В другой — выполнить своё обещание. В третьей — поставить задачу на следующий месяц и пока оставить человека в покое.

У вас в CRM записано, почему клиент взял паузу, или только то, что он «думает»?🫠

С полутора недель до двух часов. Но сначала агент съел все лимиты 🫠

Лена — юрист по банкротству и участница нашего буткемпа. Она собрала инструмент для подготовки документов: работа, которая на одном сложном деле заняла около полутора недель, теперь, по её оценке, укладывается примерно в два часа вместе с проверкой.

Сам кейс разобрал в карточках 👆🏻 А здесь расскажу, что пришлось исправить, прежде чем всё заработало.

Потому что на старте агент и ошибался, и тратил кучу ресурсов))

➖ Сотни PDF съедали лимиты

Лена пыталась обрабатывать большой объём документов через модель. Та читала файлы, тратила токены, а до результата ещё нужно было добраться.

Подсказал ей вынести разбор PDF в отдельный обработчик: сначала собрать данные в реестр, затем работать уже с ним. Заодно Лена ограничила чтение ненужных изображений и убрала лишние повторные проверки.

➖ После ошибки всё начиналось заново

Агент доходил до проблемы и снова запускал обработку с начала. Ещё один круг по документам, ещё расход лимитов.

Лена добавила сохранение промежуточных результатов и кнопку «возобновить». Теперь после сбоя можно продолжить с того места, где остановились.

➖ Отдельно разобрались с чувствительными данными

В документах — персональные данные клиентов. Поэтому обработку файлов вынесли в скрипты, которые работают на компьютере Лены.

На созвоне отдельно обсудили важный момент: «запускается на моём компьютере» ещё не означает, что данные не попадают в облачную модель. Нужно понимать, какие операции выполняет локальный обработчик и что именно получает LLM. Одной просьбы «никуда не отправляй» здесь мало.

➖ Одну большую задачу разделили на две

Лена сделала двух субагентов: один отвечает за обработку постановлений, другой — за кредиторов. По её словам, после разделения работа пошла быстрее.

Мне в этом кейсе нравится, как Лена разбиралась с конкретными сбоями: почему снова закончились лимиты, зачем агент перечитывает файлы, где теряет результат. Постепенно из этого получился инструмент, которым она может пользоваться в своей работе.

Есть задача, которую давно хочется автоматизировать, но непонятно, с какой стороны подойти?

Напишите «+» и коротко опишите её в комментариях. Свяжемся с вами, разберём запрос и расскажем, как с ним можно поработать на буткемпе 👇🏻

Созвон на полчаса, а работы вокруг него — на полдня 🫠

Знакомая картина: встреча закончилась, надо отправить клиенту договорённости, занести всё в CRM и назначить следующий шаг. А через две минуты уже следующий созвон — и на письмо с CRM остаётся всё меньше времени.

После форума я обещал разобрать базовые ИИ-инструменты. Начну с самого бытового: три места вокруг звонка, где ИИ забирает работу 👇🏻

1. До встречи. Просите собрать справку о компании и набросать вопросы. Одно условие: пусть подтверждённые факты идут отдельным списком, а предположения — отдельным. Иначе вы придёте на встречу с красивыми, но выдуманными деталями.

2. После встречи. Отдаёте заметки или расшифровку и просите вытащить четыре вещи: потребности, возражения, договорённости, открытые вопросы. Не пересказ разговора, а именно эти четыре списка.

3. Следующий шаг. Из того же разбора — черновик письма клиенту и 2–3 задачи для CRM. Ответственные и сроки берутся только из исходника. Чего в заметках не было — помечается «уточнить», а не додумывается.

Как это выглядит на практике. Пример учебный, вымышленный:

Заметки менеджера: «Логистика, 40 машин. Диспетчеры вручную сводят заявки в таблице, теряются заявки. Возражение: боятся, что внедрение встанет колом на месяц. Договорились: присылаю кейс похожего клиента и демо в четверг».
Что получается на выходе. Письмо на пять строк: спасибо за разговор, зафиксированная проблема (ручное сведение заявок и потери), ответ на возражение через кейс, фраза про демо в четверг. И задачи: «Отправить кейс», «Подтвердить время демо в четверг», «Уточнить, кто со стороны клиента участвует в демо».

Обратите внимание: в письме нет ни скидок, ни сроков внедрения, о которых на встрече не говорили.

💡 Инструкция, которую можно скопировать:

Ты ассистент менеджера по продажам. Вот мои заметки со встречи: [текст]. Сделай три вещи: 1) четыре списка — потребности, возражения, договорённости, открытые вопросы; 2) черновик письма клиенту, деловой тон, только факты из заметок; 3) 2–3 задачи для CRM с формулировкой действия. Имена, сроки и обещания бери только из заметок. Чего в заметках нет — пиши «уточнить», не придумывай

👉Начинать проще не со всего процесса, а с одного повторяющегося действия. Например, после каждого звонка готовить с ИИ черновик письма — и проверять его перед отправкой. Финальное решение, что уходит клиенту, всё равно остаётся за вами.

Что у вас чаще откладывается после звонка: письмо клиенту или заполнение CRM?))

Ни одна защита не идеальна. Поэтому их девять

Дарио Амодеи в интервью CBS 13 сентября: «Это не значит, что надо паниковать сегодня. И не значит, что надо всё выключить. Это предупреждающий знак, что надо замедлиться». Дальше он объясняет, как именно, и вот это интереснее громких заголовков 👇🏻

Представьте ломтик швейцарского сыра. Он что-то задерживает, но в нём дырки.
Возьмите пять ломтиков - и дырки окажутся в разных местах. Ни одна защитане идеальна. Но если быть аккуратным на каждом уровне, всё может кончиться хорошо.

За ту же неделю Anthropic предложила обязать крупные компании публиковать регламент безопасной разработки и назначать ответственного за него человека. OpenAI выложила фреймворк раскрытия сбоев и сразу шесть отчётов о своих инцидентах. А Anthropic в тот же день сняла ограничения для проверенных биологов, заменив блокировку проверкой и разбором логов.
Так что это не «все ударили по тормозам». Это слои.

В отчёте OpenAI меня зацепила узнаваемость. Модель воспользовалась утёкшим ключом и дофантазировала данные. Заливала файлы на публичные хостинги, чтобы потом на них сослаться. Подсовывала себе инструкции в сводки контекста. Те же грабли, на которые наступают за вечер вайбкодинга.

Я два года на каждом потоке буткемпа останавливаюсь и говорю про безопасность. И каждый раз выясняется, что кто-то уже отправил ключ API прямо в чат с моделью. Не потому что не знал, а потому что так было быстрее.

Собрал в карточки 9 правил, которые повторяю участникам. Это и есть ваши девять ломтиков:

1. Ключи в .env, а .env в .gitignore
2. Ключ никогда не проходит через модель
3. В Supabase включаем RLS с первой таблицы
4. Права агенту выдаём ступенями
5. Опасные команды блокируем хуком
6. Персональные данные обезличиваем скриптом
7. Только официальные MCP и проверенные скиллы
8. Разбиваем опасную тройку
9. Аудит перед публикацией - в новой сессии

Ни одно из них не спасает само. Вместе
закрывают почти всё 🔥

Самое простое, с чего начать: в начале каждой задачи пишите Claude «сделай это безопасно».

А какое из девяти вы уже нарушали?👇🏻