Почему отделу продаж нужен оператор сценариев, а не AI-инженер: разбор ошибки найма с конкретными критериями и таблицей задач
Откуда взялась эта ошибка найма
В 2026 году в отделах продаж появилась устойчивая мода: открывать вакансию "AI-инженер" или "ML-разработчик для автоматизации воронки". Звучит солидно. На деле задачи в описании выглядят примерно так: настроить триггеры в HubSpot, написать промпты для квалификации входящих лидов, собрать цепочку follow-up писем через n8n или Make.
Это не инженерная работа. Здесь не нужен Python.
Но компании всё равно нанимают разработчика. Middle-уровень по рынку 2026 года стоит от 180 000 рублей в месяц. За эти деньги приходит человек, который умеет писать чистый код, проектировать архитектуру, разбираться в документации любого API. И при этом совершенно не понимает, почему лид на третий день должен получить письмо про кейс конкурента, а не про цену. Он не знал о таком требовании, потому что его никто не спросил. Его наняли как инженера, а не как человека, который разбирается в логике прогрева.
Путаница вышла из одного слова. "AI" сейчас описывает и дообучение языковых моделей на собственных данных, и банальную настройку готового инструмента через браузер. Один термин, два разных мира компетенций. Когда руководитель отдела продаж пишет в заявке "нужен AI-специалист", он чаще всего имеет в виду второе. HR слышит первое и идёт искать разработчика с резюме на GitHub.
Так и возникает ситуация: дорогой специалист есть, задача не решена, все недовольны.
Компании часто путают, кого нанимать первым: специалиста по CRM или инженера по AI, хотя это совсем разные роли с разными задачами.
Что реально нужно автоматизировать в продажах
Начну с честного ответа: большинство "автоматизаций продаж", которые я вижу у клиентов, автоматизируют не то. Настроены триггерные письма с именем из базы, CRM обновляется вручную, а менеджер всё равно тратит два часа в день на рутину, которую можно убрать за неделю.
Вот четыре задачи, где автоматизация даёт реальный возврат.
Квалификация входящих лидов. Заявка приходит в CRM, GPT-4o или Claude читает текст из формы и присваивает теги по BANT: есть ли бюджет, кто принимает решение, какой горизонт сделки. Менеджер открывает карточку и уже видит оценку. Не нужно перезванивать, чтобы выяснить, что лид ищет бесплатный тариф. Модель справляется с этим за 3-5 секунд после отправки формы.
Персонализированные follow-up. Шаблон с "Здравствуйте, {имя}" давно не работает. Сценарий в Make берёт из CRM данные: отрасль, размер компании, что обсуждали на звонке, какие страницы смотрел клиент. Промпт собирает из этого письмо с конкретной болью. Я проверял такой подход на b2b-сегменте: open rate вырастает, но главное, что reply rate растёт заметно, потому что человек читает про свою ситуацию, а не про "наше уникальное предложение".
Резюме звонков. Запись созвона идёт в Whisper, получается транскрипт. Дальше промпт вытаскивает три вещи: главные возражения, что пообещал менеджер, следующий шаг с дедлайном. Всё это пишется в карточку CRM автоматически. Менеджер не забывает, что обещал прислать кейс к пятнице. Руководитель видит паттерны возражений по всей команде без прослушивания записей.
Реактивация холодной базы. Сегмент "не отвечал 30 и более дней" запускает отдельную цепочку. Не такую же, что шла раньше, а другую, с другим углом захода. Модель может генерировать варианты под разные причины молчания: клиент пропал после демо, после КП, после первого касания. Это разные письма с разной логикой.
Всё это настраивается в Make, n8n или Zapier. Без кода. Make я бы рекомендовал для старта: визуальный редактор понятен, коннекторы к OpenAI и CRM уже готовые. n8n даёт больше гибкости, если нужна своя инфраструктура и данные не должны уходить наружу.
Ключевой принцип: автоматизируй то, что повторяется точно и часто. Не пытайся заменить переговоры. Убери всё, что происходит до и после разговора с клиентом.
Каждая точка касания в воронке продаж может быть автоматизирована по-своему, и выбор инструмента зависит от того, где теряются деньги прямо сейчас.
Кто такой оператор сценариев автоматизации
Это роль, которая оформилась как отдельная специализация примерно в 2025 году и к 2026-му уже нормально встречается в вакансиях продуктовых и b2b-компаний. Не разработчик, не маркетолог, не классический ops-специалист. Что-то своё.
Оператор автоматизации не пишет код. Его работа: построить логику поведения системы. Лид заполнил форму с бюджетом выше 500k и указал сферу "производство" - запускается сценарий А: письмо с кейсами, пинг в Slack менеджеру, задача в CRM на звонок через 4 часа. Бюджет ниже или поле пустое - сценарий Б: нагревающая цепочка на 5 касаний без участия человека. Вся эта логика строится в Make, n8n, HubSpot Workflows или Bitrix24, а LLM-шаги (персонализация письма, квалификация по тексту заявки) настраиваются через промпт-редакторы прямо внутри платформы.
Ключевая вещь, которую трудно нанять извне: оператор понимает продажи изнутри. Он знает, что письмо с фразой "хотим предложить сотрудничество" на этапе MQL убивает конверсию, а уточняющий вопрос про задачу двигает вперёд. Это не теория. Это накопленный опыт из сотен разговоров с клиентами.
Поэтому типичный бэкграунд у таких людей: бывший SDR или аккаунт-менеджер, который в какой-то момент начал автоматизировать свою же работу. Сначала простой Zapier для уведомлений, потом ветвящиеся сценарии в Make, потом подключение GPT-шагов для обработки входящих заявок. Навык рос органически, а не через курс "стань no-code разработчиком за 3 месяца". Именно поэтому менеджеры с опытом продаж часто оказываются сильнее в настройке AI-сценариев, чем технические специалисты без этого контекста.
Это и делает роль редкой. Людей, которые умеют и в Make, и в воронку продаж, пока мало.
Чем оператор отличается от AI-инженера: конкретная таблица задач
Путаница здесь дорого стоит. Компании либо нанимают инженера туда, где хватит оператора, либо пытаются решить инженерную задачу операторскими инструментами. Первое сжигает бюджет, второе сжигает время.
Разграничение простое. Оператор берёт готовые блоки: модели через API, конструкторы вроде n8n или Make, готовые промпты, готовые интеграции. Его работа: собрать из этого рабочий флоу под конкретный бизнес-процесс. AI-инженер нужен там, где готовых блоков не хватает: кастомная модель, fine-tuning, RAG-архитектура под специфичную базу знаний, нестандартная логика на уровне API.
Конкретный пример. Настроить GPT-шаг в n8n, который берёт транскрипт звонка и выдаёт саммари с ключевыми возражениями: это задача оператора, решается за день-два. Обучить собственную модель на 10 000 звонков компании, которая предсказывает вероятность закрытия сделки по паттернам речи конкретного менеджера: это уже инженер, датасет, эксперименты, инфраструктура.
Вот грубая таблица:
| Задача | Кто нужен |
|---|---|
| Автоответ на входящий лид через GPT | Оператор |
| Суммаризация звонков в CRM | Оператор |
| Скоринг сделок по транскриптам | Оператор (если через готовый промпт) или инженер (если нужна точность >90% на своих данных) |
| RAG-поиск по внутренней базе знаний компании | Инженер |
| Fine-tuning под стиль бренда | Инженер |
| Интеграция нескольких SaaS через готовые коннекторы | Оператор |
| Кастомный коннектор с нестандартной авторизацией | Инженер |
По моим наблюдениям, большинство задач автоматизации в отделе продаж попадают в зону оператора. Суммаризация, квалификация лидов, первичные ответы, напоминания, заполнение полей CRM, генерация коммерческих предложений по шаблону. Всё это собирается из готовых блоков без единой строчки обучения модели.
Нанять инженера для этих задач: примерно как позвать архитектора переставить мебель. Квалификация есть, но задача не та. Инженер будет скучать или, что хуже, усложнять решение до неузнаваемости, потому что простое кажется ему неинтересным.
Оператор работает с готовыми AI-инструментами и настраивает сценарии, а инженер строит инфраструктуру и обучает модели, это две отдельные ставки в бюджете.
Почему промпт-инженерия важнее умения писать Python
В задачах автоматизации продаж качество промпта сильно влияет на результат. Зачастую сильнее, чем выбор архитектуры, модели или то, синхронный у тебя запрос или асинхронный.
Python-разработчик за час напишет корректный API-запрос к OpenAI. Авторизация, обработка ошибок, retry-логика, всё чисто. Но если в system prompt написано "Квалифицируй лида по BANT" - на выходе будет мусор. Модель начнёт фантазировать, заполнять пустоты, уверенно писать "бюджет: средний", потому что ей нечем заполнить поле.
Хороший промпт пишет не программист. Его пишет человек, который сам прошёл сотни звонков.
Вот конкретный пример: слово "изучаем" в тексте заявки может означать, что клиент ещё не готов к быстрой сделке. Человек пишет "мы изучаем варианты" или "рассматриваем направление" - скорее всего, это стадия исследования рынка, а не активная покупка. Опытный менеджер чувствует это интуитивно. Модель без подсказки не знает. Но если зашить это наблюдение прямо в инструкцию, поведение модели меняется принципиально.
То же с тоном обращения. Заявка от IT-директора крупной компании и заявка от ИП на маркетплейсе требуют разной логики квалификации. Разных сигналов готовности. Разного порога score.
Посмотри на упрощённый вариант system prompt для квалификации:
{
"role": "system",
"content": "Ты - ассистент квалификации лидов. Получаешь текст заявки. Определи:\n1. Бюджет: явный / косвенный / не указан\n2. Срочность: до 1 мес / 1-3 мес / не определена\n3. Лицо принимающее решение: указано / не указано\nВерни JSON: { budget, urgency, decision_maker, score: 1-10 }\nНе придумывай данные. Если информации нет - пиши null."
}
Три вещи, которые здесь работают на результат. Первое: модели явно запрещено придумывать данные. Без этой строки она будет заполнять поля с уверенным видом. Второе: структура ответа жёстко фиксирована - JSON с конкретными полями, без свободного текста. Третье: шкала score от 1 до 10 даёт числовой выход, который дальше можно использовать как фильтр в CRM без дополнительного парсинга.
По поводу RAG и fine-tuning: в задачах отдела продаж они нужны реже, чем об этом пишут. В большинстве случаев хватает хорошего system prompt плюс данные из CRM, переданные в контекст запроса. Профиль компании, история обращений, сегмент - всё это идёт прямо в user message, и модель работает с актуальным контекстом без дополнительной инфраструктуры. Fine-tuning оправдан, если у тебя специфический отраслевой словарь или нестандартная логика квалификации, которую невозможно объяснить в тексте промпта. Но это редкий случай.
Так что если выбирать, что прокачивать в 2026 году, умение формулировать точные инструкции для модели окупается быстрее, чем знание asyncio.
Качество промпта влияет на результат быстрее, чем архитектура кода, поэтому в продажах часто выгоднее сначала нанять человека, умеющего писать промпты, а не разработчика.
Как выглядит команда AI в отделе продаж реально
Если у вас 10 продавцов и вы хотите нормально использовать AI в продажах, вам не нужен штатный ML-инженер. Нужен один человек на полставки, который умеет работать с no-code автоматизацией, читать логи и не бояться промптов.
Я видел достаточно команд, где пытались нанять «инженера по AI» на всё сразу. Технически всё работало. CRM подключена, транскрибация идёт, саммари генерируются. Но через два месяца продавцы жаловались, что AI присваивает высокий приоритет лидам, которые на деле никогда не покупают, а горячие клиенты с чеком 2 млн лежат в общей очереди. Потому что человек, который настраивал систему, не понимал воронку. Это та же ловушка, о которой подробно написано в разборе почему корпоративное обучение n8n не даёт результата через полгода: инструмент работает, но логика бизнеса в него не вшита.
Минимальная рабочая конфигурация для команды 5-15 человек выглядит так.
Оператор автоматизации, 0.5 ставки или фриланс. Он ведёт сценарии, тестирует промпты, смотрит на качество выходных данных каждые несколько дней. Конкретно: открывает последние 20 саммари после звонков, проверяет, не поехала ли формулировка задачи следующего шага. Меняет промпт, если поехала. Это не разработка. Это операционная работа, которая при нормально выстроенном процессе занимает несколько часов в неделю, хотя объём сильно зависит от количества сценариев и активности изменений.
AI-инженер, разово. Подключить нестандартную АТС, написать парсер под выгрузку из 1С в специфичном формате, настроить вебхуки. Это задачи на несколько дней, их решают один раз и потом не трогают месяцами. Держать такого специалиста в штате ради этого не нужно.
Руководитель отдела продаж, постоянно. Он владелец логики. Именно он говорит: хочу, чтобы лиды с чеком выше 1 млн получали другой сценарий квалификации и попадали сразу ко мне на контроль. Оператор это реализует технически. Но если РОП не формулирует такие требования регулярно, система будет работать по правилам, которые актуальны для прошлого квартала.
Разрыв между техническим и бизнесовым в этой связке убивает результат быстрее, чем плохие инструменты. Инженер, которому дали задачу «сделай AI для продаж», сделает то, что он понимает: интеграции, пайплайны, модели. Воронку он не знает и по умолчанию не будет её уточнять. Так что разделение ролей тут не про бюрократию, а про то, кто несёт ответственность за то, чтобы логика соответствовала реальному процессу.
Рабочая AI-команда для продаж обычно состоит из трёх-четырёх ролей, и попытка закрыть всё одним универсальным сотрудником ломает процесс уже через месяц.
На что смотреть при найме оператора: 6 конкретных критериев
Начну с очевидного: резюме здесь почти бесполезно. Люди пишут "автоматизация продаж" и "работа с AI" в каждую строчку, потому что это работает при скрининге. Проверить их можно только через конкретные вопросы и короткое тестовое.
1. Опыт в продажах хотя бы 1-2 года
Оператор, который никогда не сидел в CRM и не видел воронку изнутри, будет строить автоматизацию по своим представлениям о том, как "должно работать". Это дорого обходится. Попросите объяснить разницу между MQL и SQL. Если человек начинает уточнять, что вы имеете в виду, или отвечает размыто, скорее всего, он эти понятия видел только в статьях.
2. Портфолио из реальных флоу
Попросите показать конкретную схему, которую человек построил сам. Не скриншот из чужого курса, а рабочий сценарий с объяснением логики: почему именно такая ветка, что происходит при ошибке, как обрабатывается граничный случай. Хороший кандидат сразу покажет несколько решений и объяснит, почему выбрал именно это.
3. Make или n8n на уровне "могу объяснить каждый модуль"
Не "я умею пользоваться", а именно объяснить. Попросите провести вас по любому из своих флоу как будто вы не понимаете инструмент. Если человек спотыкается на вопросе "а зачем здесь этот Router?" - он строил по туториалу, не понимая сути.
4. Понимание ограничений LLM
Это критично. Оператор, который верит, что GPT-4o или Claude всегда выдаёт корректный результат, сломает продакшн-сценарий в первый же месяц. Спросите напрямую: как вы проверяете выходные данные модели перед тем, как они уйдут дальше по сценарию? Правильный ответ включает валидацию формата, иногда второй вызов модели с проверочным промптом, иногда regex, иногда условие с fallback-веткой. Если человек говорит "я доверяю модели" - это стоп.
5. Навык написания промптов
Здесь не нужны долгие разговоры. Дайте тестовое задание под реальную задачу вашего бизнеса: "напишите промпт, который квалифицирует входящий лид по трём критериям и возвращает структурированный JSON". Смотрите на то, как человек задаёт контекст модели, как формулирует ограничения, как указывает формат вывода. Плохой промпт виден сразу.
6. Коммуникация с продавцами
Это, пожалуй, самый недооценённый критерий. Продавцы будут приходить с претензиями: "бот написал клиенту не то", "автоматизация тупит", "это вообще не работает". Оператор должен спокойно разобраться, перестроить логику и объяснить команде, почему сценарий вёл себя именно так. Спросите на интервью про конкретный конфликт с командой вокруг какого-то инструмента. Как объяснял. Как договаривался. Если человек не может привести пример - скорее всего, просто не работал в такой среде.
Типичные ошибки при формировании AI-команды в продажах
Самая распространённая схема выглядит так: компания нанимает разработчика и ставит ему задачу "автоматизируй продажи". Разработчик делает именно то, что умеет: строит технически чистую систему, которая не падает, корректно обрабатывает запросы и хорошо логирует события. Только продажи не растут. Потому что разработчик не знал, что лид из рекламы в Instagram ведёт себя иначе, чем лид с сайта, что после трёх дней молчания нужен другой триггер, что звонок в среду утром конвертирует лучше, чем письмо в пятницу вечером. Это не техническая информация. Её нужно было передать, а передавать было некому.
Схожая ошибка: отдать автоматизацию маркетологу. Маркетинг работает с охватом, CTR, стоимостью клика. Продажи работают с конверсией в сделку, длиной цикла, средним чеком. Это разные метрики и разные точки принятия решений. Маркетолог выстроит красивые цепочки прогрева, которые отлично доводят человека до заявки и бросают его там, потому что дальше "уже не его зона".
Отдельная история с готовыми AI-решениями "под ключ". Их продают как конечный продукт, но по факту это точка старта. Сценарии, написанные под вашу воронку в апреле 2026-го, через два месяца начнут устаревать: изменится оффер, появится новый сегмент, перестанет работать один из каналов. Если внутри команды нет человека, который понимает логику системы и умеет её менять, вы платите за инструмент, который никто не обслуживает. Именно поэтому упаковка AI-автоматизации как разового продукта почти всегда проигрывает модели сопровождения.
Обратная крайность: взять оператора и попросить его написать интеграцию с вашей кастомной CRM на Python. Это не задача оператора. Оператор настраивает логику сценариев, работает с no-code инструментами, редактирует промпты. Писать код под нестандартный API, разбираться с авторизацией и обработкой исключений - это работа разработчика. Когда эти роли путают, оператор либо уходит, либо делает костыль, который рассыпается при первом обновлении системы.
И последнее. Оператору нужны данные о конверсии. Без них он работает вслепую: запускает сценарий, смотрит, что технически отрабатывает без ошибок, и не знает, приводит ли он к сделкам. Закрыть доступ к воронке и при этом ожидать улучшений - это как просить пилота посадить самолёт без приборной панели. Сценарий обновляется тогда, когда видно, где он ломается. Для этого нужны цифры, а не ощущения.
Самые частые ошибки при найме в AI-команду продаж повторяются из компании в компанию, и большинство из них можно избежать, если задать три конкретных вопроса на интервью.
Когда всё-таки нужен AI-инженер
Есть несколько сценариев, где