Нейросеть для отдела продаж: как собрать ИИ-продавца

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

Ниже - разбор по шагам: что отдать модели, что написать ей в регламенте, как считать пользу от неё и где эта связка сломалась лично у меня.

Что именно отдать нейросети в отделе продаж?

Я отдаю модели одно звено конвейера - первый фильтр входящих: ответить на заявку за минуту, квалифицировать по чек-листу, закрыть типовые вопросы, записать данные в CRM, догреть холодных по сценарию. Сюда идёт всё, где выигрывают скорость и однотипность. Возражения, торг, закрытие сделки и ответственность за неё остаются на человеке.

Отдел продаж работает как конвейер: поймать заявку, понять, целевой ли клиент, ответить на вопросы, назначить следующий шаг, зафиксировать всё в CRM, догреть тех, кто не готов сейчас. Первое, что я попробовал сам, - попросить модель «вести продажи». Роль вышла размытой, и она начала импровизировать ровно там, где нужна точность: сочинила скидку за объём, которой у меня в прайсе нет. В продажах импровизация стоит денег, поэтому конвейер надо нарезать на звенья и отдать ИИ только те, где он тянет.

Звено	ИИ-продавец	Живой менеджер
Ответ на входящую заявку за минуту	да	-
Квалификация по чек-листу	да	-
Ответы на частые вопросы	да	сложные и спорные
Запись данных в CRM	да	-
Догрев холодных по сценарию	да	-
Работа с возражениями и торг	-	да
Закрытие сделки, ответственность	-	да

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

Границу между ролями я подробнее разбирал в тексте про цифрового сотрудника, а если тебе интереснее общая картина, какие вообще участки бизнеса поддаются автоматизации, - смотри карту возможностей. Продажи там один из самых благодарных участков просто потому, что первое касание однотипно почти всегда.

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

Из чего состоит участок ИИ-продавца?

Участок держится на трёх функциях: квалификация, ответы по базе знаний и карточка в CRM. Всё, что выходит за эти три, - работа человека.

1. Квалификация. Понять, целевой ли это клиент, по критериям, которые ты задал заранее. Есть ли бюджет в вилке, подходит ли ниша, кто принимает решение, насколько срочно. ИИ задаёт вопросы по одному, по-человечески, и делает вывод: горячий / тёплый / не наш.

2. Ответы. Закрыть типовые вопросы из базы знаний: что входит, сколько стоит, как проходит, чем вы отличаетесь. Строго по источнику, без фантазий.

3. CRM. Сложить разговор в карточку по полям: контакт, канал, ответы на квалифицирующие вопросы, статус, следующий шаг. Менеджер утром открывает карточку и за двадцать секунд понимает ситуацию, расшифровывать простыню переписки ему не приходится.

Три функции соблазнительно расширить: добавить туда выставление счетов, отправку договоров, перенос встреч, сбор отзывов. Каждая добавка выглядит невинно, а вместе они превращают понятного сотрудника в неуправляемый комбайн, у которого невозможно понять, где именно он ошибся. Держи участок узким хотя бы первые месяц-два. Как разрастается роль и когда её стоит делить на несколько ИИ-агентов, разобрано в материале про ИИ-агентов для бизнеса.

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

Как собрать ИИ-продавца по шагам?

Шесть шагов: описать идеального клиента, написать скрипт квалификации, собрать базу знаний, прописать передачу человеку, подключить канал и CRM, прогнать всё на старых переписках. Порядок неслучаен: сначала ты формулируешь, что вообще считаешь правильной работой, и только потом эта формулировка воплощается технически. Если стартовать с подключения интеграций, получится красивая пустота, которая быстро отвечает бессмыслицей.

Шаг 1. Опиши идеального клиента и стоп-сигналы

Пока ты сам не сформулировал, кого квалифицировать, модель не сможет. Напиши простой документ: кто твой целевой клиент (ниша, размер, бюджетная вилка, задача) и кто точно не твой. Стоп-сигналы важны не меньше портрета: студент на курсовую, агентство, которое собирает цены для тендера, человек с бюджетом вдвое ниже нижней планки.

Документ можно писать в свободной форме, но лучше сразу разбить на пункты, чтобы потом ссылаться на них из скрипта. Я держу его на одну страницу: пять абзацев про «наш» и три абзаца про «не наш». Длиннее модель начинает выбирать из противоречивых признаков и путается.

Шаг 2. Напиши скрипт квалификации

Скрипт нужен, чтобы выяснить, кто перед тобой. Дай модели 4-6 вопросов и порядок. Формулировка для системного промпта примерно такая:

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

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

Вопрос про бюджет в лоб работает плохо в любом канале. Я прошу модель предлагать вилку: «обычно такие задачи укладываются в диапазон от и до, вам ориентироваться на эти цифры комфортно?». Человек отвечает «да», «дороговато» или «нам бы попроще» - и по этому ответу квалификация проходит точнее, чем по прямому допросу.

Шаг 3. Собери базу знаний для ответов

Всё, что модель может домыслить - цены, состав пакетов, условия, отличия от конкурентов, - вынеси в отдельный документ и прикрепи как источник. Главное правило в промпте:

Отвечай на вопросы только на основе базы знаний. Если ответа в ней нет - не придумывай. Скажи, что уточнишь, и передай диалог менеджеру.

Одна строчка служит предохранителем: без неё модель охотно сочиняет скидки, которых у тебя нет, и сроки, которые ты не выдержишь. Как складывать такой документ, чтобы модель в нём не терялась, я разбирал отдельно - база знаний для нейросети.

Шаг 4. Пропиши передачу человеку

Заранее определи триггеры эскалации: клиент горячий, задаёт вопрос вне базы, торгуется, раздражён, речь о крупной сделке. На любом из них диалог уходит менеджеру вместе с контекстом, без попыток дожать самостоятельно.

Передача должна выглядеть прилично с обеих сторон. Клиенту уходит короткое «сейчас подключу коллегу, он ответит точнее», менеджеру - сводка на три строки: кто, что хотел, на чём остановились. Без сводки эскалация сводится к переброске переписки, которую человек читает пять минут и половину пропускает.

Шаг 5. Подключи к каналу и CRM

Технически это связка: канал заявок (чат на сайте, директ, форма) - конструктор ботов или CRM с встроенным ИИ - модель по API. Карточку в CRM модель заполняет по шаблону полей, который ты задаёшь. Если своя разработка не по силам, бери готовые конструкторы с интеграциями; как устроен такой чат-бот для бизнеса - отдельный разговор, но код тут не главное.

Когда каналов больше одного и нужно склеивать их в общий поток, удобнее собирать логику в визуальном оркестраторе. Начать можно с пошагового освоения n8n: там наглядно видно, куда уходит сообщение и почему оно не дошло. Модель при этом остаётся сменной деталью - её меняешь без переделки всей схемы.

Шаг 6. Прогони на реальных диалогах

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

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

Если ты только присматриваешься и не готов сам возиться с промптами, регламентами и интеграциями, начни с бесплатного курса - там по шагам показано, как собирается цифровой сотрудник и на чём такие сборки обычно ломаются: забрать бесплатное обучение по ИИ. Материалы открываются сразу, разбор идёт на живых примерах.

Зачем ИИ-продавцу регламент?

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

• Границы. Что делает, чего не делает никогда (не даёт скидок, не меняет условия, не обещает сроки от себя).
• Тон. На «ты», спокойно, без давления и капса. Один-два примера хорошего и плохого ответа.
• Правило источника. Отвечает только из базы знаний, иначе - эскалация.
• Эскалация. Список триггеров передачи человеку.
• Формат карточки. Какие поля и в каком виде пишем в CRM.

Регламент работает как рельсы: по ним модель едет одинаково в понедельник утром и в пятницу вечером, а разовый удачный ответ превращается в предсказуемого сотрудника. Через полгода ты поменяешь модель на более свежую, и рельсы останутся на месте - переписывать придётся максимум пару формулировок.

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

Отдельный пункт - представление. Пусть первое сообщение честно говорит, что отвечает ассистент, и обещает подключить человека при необходимости. Клиенты почти никогда не злятся на бота, который сразу назвался. Раздражает другое: собеседник десять реплик изображает менеджера Марину, а потом выдаёт шаблонную фразу и раскрывается.

Как собрать базу знаний, из которой он отвечает?

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

Что туда входит:

• Продукт. Что продаёшь, из чего состоит, что входит в каждый пакет, чего в нём нет.
• Цены и условия. Прайс с датой актуальности, порядок оплаты, что влияет на стоимость.
• Процесс. Как проходит работа по этапам, сколько занимает, что нужно от клиента.
• Частые вопросы. Реальные формулировки из переписок вместе с ответами, которые ты считаешь правильными.
• Отличия. Чем ты отличаешься от типичной альтернативы, без называния конкурентов по именам.
• Ограничения. С чем ты не работаешь и почему.

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

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

Актуальность базы поддерживай по календарю. Поменял прайс - в тот же день поправил документ, иначе через неделю ИИ-продавец начнёт бодро продавать по старым ценам, и вопрос «почему нам обещали дешевле» прилетит уже менеджеру.

Что писать в карточку CRM?

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

Поле	Что кладём	Пример
Контакт	Имя, канал, как связаться	Игорь, Telegram, @igor
Запрос	Одно предложение своими словами	Нужен бот на первую линию поддержки
Ниша	Из списка, который ты задал	Онлайн-школа
Бюджет	Вилка или «не назвал»	Верхняя вилка
Срок	Когда нужно	В течение месяца
ЛПР	Да / нет / неясно	Да, собственник
Статус	Горячий / тёплый / не наш	Горячий
Следующий шаг	Конкретное действие с датой	Созвон в четверг, 15:00
Цитата	Одна фраза клиента дословно	«нам вчера надо было»

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

Отдельно договорись, что делать с неполными диалогами. Человек написал «сколько стоит», получил ответ и исчез - карточка всё равно создаётся, со статусом «не квалифицирован» и пометкой, на каком вопросе оборвалось. Через месяц такие обрывы складываются в понятную картину: если половина уходит после вопроса про бюджет, стоит переписать саму формулировку про деньги. Как вытаскивать выводы из накопленных данных, есть разбор про ИИ для бизнес-аналитики.

Как догревать тех, кто не готов покупать сейчас?

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

Работающая схема выглядит так. На следующий день после разговора уходит короткое сообщение с материалом по теме запроса. Спустя неделю модель спрашивает, продвинулась ли задача. Дальше месячная пауза и напоминание с новым поводом: изменились условия, появился формат подешевле, освободилось место в графике. Перед каждым касанием модель сверяется с базой и молчит, если повода нет.

Правила, без которых догрев скатывается в спам:

• Не больше трёх касаний, если человек не отвечает.
• Каждое сообщение несёт что-то полезное само по себе, даже если его не откроют.
• Явный отказ фиксируется в CRM и останавливает всю цепочку.
• Любой ответ клиента обрывает автоматику и переводит диалог на человека.

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

Где связка ломается чаще всего?

У меня она сломалась на эскалации, и заметил я это только на следующее утро. В триггерах было записано «просит скидку». Клиент сформулировал иначе: «а если возьмём два, что-нибудь придумаете?». Модель не увидела в этом торга, ответила по базе знаний, что цены фиксированные, - вежливо и абсолютно мимо. Диалог я прочитал в логе через сутки, человек к тому моменту остыл и не ответил.

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

Остальные грабли выглядят так:

• Модель выдумывает цены и условия. Лечится правилом источника и выносом всех фактов в базу знаний.
• Отвечает как робот-скрипт. Слишком жёсткий промпт душит диалог. Дай примеры живых формулировок и разреши задавать по одному вопросу.
• Не передаёт горячих вовремя. Пропущенный триггер - и лид тихо остывает в чате с ботом. Проверяй эту ветку первой.
• CRM забита мусором. Без жёстко заданных полей модель пишет вольным текстом, и через месяц в системе копится свалка из пересказов. Дай шаблон карточки.
• Диалог рвётся при возврате клиента. Человек ответил через три дня, а модель начала квалификацию заново. Историю надо привязывать к контакту, чтобы разговор продолжился с той же точки через любое время.
• Никто не читает логи. Самая дорогая ошибка: связка работает, ошибается, и об этом узнают через квартал по упавшей конверсии.

Разборы таких связок, готовые промпты для квалификации и шаблоны ролей цифровых сотрудников я выкладываю в закрытый канал ИИмперии - там же примеры регламентов, которые можно забрать и подогнать под свой отдел продаж.

Как понять, что ИИ-продавец окупился?

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

• Время первого ответа. Засеки в минутах или часах путь от заявки до первой реплики менеджера. Разрыв тут обычно самый заметный: у модели ответ уходит за секунды в любое время суток.
• Доля обработанных заявок. Какая часть входящих вообще получила ответ. В выходные, в отпусках и в перегруз что-то неизбежно теряется.
• Доля квалифицированных. Сколько диалогов дошло до понятного статуса с заполненными полями.
• Конверсия в следующий шаг. Число заявок, превратившихся в созвон, встречу или расчёт.

Дальше две метрики появляются уже после запуска: доля эскалаций (какой процент диалогов ушёл человеку - у слишком низкой цифры причина в геройстве модели, а высокая говорит, что толку от неё мало) и доля выдумок, которую ты определяешь выборочной вычиткой десяти-двадцати диалогов в неделю.

Стоимость считается так же прямолинейно: сложи месячную оплату конструктора, счёт за API и время, которое ты сам тратишь на правку регламента, и раздели на число обработанных диалогов. Полученную цифру сравни с тем, сколько стоит час менеджера и сколько таких часов уходило на первое касание. Ответ на вопрос «строить самому или брать готовое» лучше принимать с этими числами на руках - сравнение подходов есть в тексте про ИИ-агентов под ключ.

Расчёт стоит повторить месяца через три. Регламент к тому времени устаканится, правки станут редкими, а цена диалога заметно снизится - основную работу ты уже сделал на старте.

Что отвечать на возражения команды и клиентов?

Сопротивление появляется почти всегда, и разговаривать с ним лучше заранее, а не после запуска.

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

«Менеджеры решат, что их увольняют». Разговор здесь честный и короткий: с них снимается разбор входящего мусора и ночные ответы, план и премия остаются. Сильные менеджеры обычно соглашаются первыми, потому что квалифицированный лид с заполненной карточкой для них выгоднее сырого потока. Про то, где проходит грань между помощником и заменой человека, есть отдельный материал - цифровой двойник сотрудника.

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

«У нас слишком сложный продукт». Сложность живёт в подборе решения и в переговорах, а первое касание почти всегда однотипно даже в сложных нишах: кто ты, какая задача, какие сроки, кто решает. Отдай модели только эту часть.

«Это дорого». Считай по формуле из предыдущего раздела. Если заявок в месяц десяток, вся затея действительно не окупится, и разумнее обрабатывать их руками. Порог, за которым автоматизация начинает иметь смысл, обсуждался в тексте с каких задач начинать автоматизацию рутины.

С чего начать, если отдел продаж - это ты один?

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

Порядок для одиночного старта я бы держал такой. На первой неделе модель только отвечает на типовые вопросы из базы знаний и предупреждает, что ты выйдешь на связь в рабочее время. Со второй к этому добавляется квалификация по трём вопросам и карточка в CRM или хотя бы в таблице. Догрев тех, кто не ответил, подключается третьим шагом. Каждую неделю добавляется ровно одна функция, и ты успеваешь понять, что именно сломалось, когда что-то ломается.

Инструменты на старте берутся самые простые: канал в мессенджере, готовый конструктор бота, таблица вместо CRM. Переезд на нормальную CRM делается позже, когда станет ясно, какие поля тебе на самом деле нужны. Выбор модели на этом этапе роли почти не играет; если всё же хочешь разобраться в различиях, есть сравнение - Claude или ChatGPT под задачи.

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

Что в сухом остатке?

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

Порядок действий на ближайшую неделю: описать целевого клиента и стоп-сигналы, написать пять квалифицирующих вопросов, собрать базу знаний на пару страниц, задать триггеры эскалации, прогнать двадцать старых переписок и только потом пускать живой трафик. Дальше - читать логи каждый день первые две недели и править регламент по тому, что увидел.

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

Какой участок отдашь первым?

Источники

• OpenAI - Prompt engineering guide - как формулировать системный промпт и задавать модели рамки ответа.
• Anthropic - Prompt engineering overview - приёмы, которые держат модель в границах источника и снижают выдумывание.
• Anthropic - Reducing hallucinations - разбор правила источника и способов заставить модель признавать незнание.