Дневник AI First трансформации. День 3: методология Spec-Driven Business для продаж и управления

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

Ответ оказался довольно простым: в бизнесе тоже нужна спецификация. В разработке это называется Spec-Driven Development, а в продажах и управлении тот же принцип можно описать как работу по единому сценарию, правилам и условиям. Если коротко, AI должен опираться не на вдохновение, а на эталон.

Почему обычных промптов уже недостаточно

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

Например:

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

Для внутренних задач это ещё терпимо. Для продаж уже опасно. Ошибка в коде ломает функцию, ошибка в продаже ломает доверие.

Что такое спецификация в продажах

Если перенести логику из разработки в бизнес, то спецификация в продажах состоит не из абстрактного ТЗ, а из вполне конкретных блоков:

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

Именно это должно стать источником правды для менеджеров, маркетинга и AI-агентов.

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

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

Рабочая схема другая. Достаточно держать в порядке два основных типа спецификаций.

1. Спецификация на продукт

На каждую программу или решение нужен один эталонный документ. Например, по Битрикс24, 1С, MyOffice или продуктам по информационной безопасности.

В нём должны быть:

• что это за продукт;
• для каких компаний он подходит;
• какие задачи решает;
• какие ограничения и условия лицензирования есть;
• какие выгоды получает клиент;
• какие типовые возражения возникают.

Это не просто описание для сайта. Это основа для писем, КП, сценариев звонков, презентаций и ответов агентов.

2. Спецификация на тип клиента

Второй кирпичик — не конкретная компания, а сегмент. Например:

• коммерческая компания малого бизнеса;
• производственная компания;
• государственное учреждение;
• компания с распределённой сетью филиалов.

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

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

Как это выглядит на практике

Допустим, у нас есть продуктовая спецификация на систему автоматизации и спецификация сегмента для производственной компании.

Тогда вместо запроса в духе «напиши письмо клиенту» мы даём AI более точную рамку:

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

В этом случае AI уже не придумывает письмо с нуля, а собирает его по спецификации. То же самое можно делать для:

• цепочки касаний;
• коммерческого предложения;
• скрипта звонка;
• презентации;
• ответов на типовые возражения.

По сути, менеджер перестаёт каждый раз писать текст руками и начинает управлять параметрами сделки.

Что меняется в управлении

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

В разработке это похоже на юнит-тесты. В бизнесе это выглядит так:

То есть AI становится не просто генератором текста, а помощником по контролю качества сделки.

Единый источник правды для людей и агентов

На второй день я писал, что мы начали строить базу знаний в Markdown с последующей индексацией в Qdrant. Теперь стало понятно, зачем это нужно на самом деле.

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

Минимально я вижу такую структуру:

• MASTER_SPEC.md — общие правила продаж, ценности компании, ключевые сообщения, стоп-фразы, обязательные акценты;
• product_spec_*.md — спецификации по продуктам;
• client_type_spec_*.md — спецификации по сегментам клиентов;
• objections.md — типовые возражения и рекомендуемая логика ответа;
• custom_terms_*.md — отдельные файлы только для особых условий по конкретным клиентам.

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

Почему это особенно важно для Битрикс24

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

Если сделать всё правильно, в CRM можно завести простые, но очень важные сущности:

1. Тип клиента.
2. Продукт или набор продуктов.
3. Этап сделки.
4. Набор обязательных проверок для перехода дальше.

Тогда AI-агент внутри Битрикс24 сможет не просто помогать менеджеру по запросу, а сопровождать сделку по правилам:

• подсказывать, какой spec подтянуть;
• собирать письмо и КП под нужный сегмент;
• напоминать, что в сделке не хватает данных;
• выявлять расхождения между обещанием клиенту и реальными условиями продукта.

Именно в этот момент AI из «чат-игрушки» превращается в рабочий слой бизнес-процесса.

Как меняется роль менеджера

Это, наверное, самый важный вывод за сегодня. При таком подходе менеджер по продажам не становится лишним. Наоборот, его роль дорожает.

Он меньше тратит времени на рутину:

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

И больше времени тратит на то, что пока плохо формализуется:

• поиск нестандартной точки входа в клиента;
• понимание реальной внутренней политики компании;
• выявление скрытого интересанта или блокера;
• переговорную стратегию.

То есть менеджер становится не оператором текста, а архитектором сделки.

Что делаем дальше у себя

После этого дня для себя фиксирую такой практический план:

1. Создать MASTER_SPEC.md с базовыми ценностями, сообщениями и ограничениями.
2. Собрать первые продуктовые спецификации по ключевым направлениям: Битрикс24, 1С, офисные решения, безопасность.
3. Описать 2-3 основных типа клиентов, с которыми работаем чаще всего.
4. Привязать эти спецификации к этапам будущей воронки в Битрикс24.
5. Настроить правило: любое изменение условий сначала вносится в базу знаний, потом распространяется на агентов и документы.

По сути, мы двигаемся не к «куче агентов», а к системе, где у всех агентов и сотрудников одна и та же опора. И это, как мне сейчас кажется, гораздо важнее, чем выбор очередной модели или красивого интерфейса.

Итоги дня

1. В продажах и управлении тоже нужен Spec-Driven подход.
2. Спецификация должна строиться не на каждого клиента, а на продукты и типы клиентов.
3. База знаний начинает работать как единый источник правды для людей, CRM и AI-агентов.
4. Битрикс24 можно использовать не просто как воронку, а как среду исполнения бизнес-спецификаций.
5. Менеджер в AI First компании — это всё больше архитектор сделки, а не ручной генератор документов.

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

Чтобы не пропускать новые статьи, подписывайтесь на Telegram-канал: https://t.me/it_po_pravde

Задавайте вопросы в комментариях — отвечаю на все!