Система, которая отказывается писать КП

Кейс OfferDesk — CRM отдела продаж, которая ведёт сделку от звонка до отправленного коммерческого предложения. Не чат-бот, а рабочее место менеджера.

Об авторе

Прежде чем разбирать систему, стоит понять, кто и зачем её построил. OfferDesk не рождён в вакууме абстрактного «AI-стартапа». Его автор, Павел Кариков, — практикующий маркетолог. Не теоретик и не обозреватель трендов, а человек, который четыре года работал в нише ИЖС и вёл там бизнес-блок «Маркетинг-продажи». Тот самый блок, который заканчивается не отчётом, а деньгами: от входящего звонка до подписанного договора. Каждая боль, описанная дальше, — не выдумка для кейса, а боль из практики: ручная сборка КП, потерянные сделки, невидимая воронка, черновики, ушедшие клиенту без утверждения.

Отсюда доверие к продукту. OfferDesk строился не сверху, от технологий, а снизу, от процесса, который автор знает изнутри и который ему надоело чинить руками. Эталон протокола, порог 80%, ворота утверждения, напоминания по зависшим сделкам — решения человека, который сам принимал эти звонки и сам собирал эти сметы. Поэтому система лечит настоящие болезни отдела продаж, а не те, что эффектно смотрятся в демо.

К практическому опыту добавилась инженерная часть. Автор применил знания по промпт-инжинирингу и вайбкодингу, полученные в университете Zerockder. Промпт-инжиниринг виден в работе с моделью: система заставляет её отдавать связный текст коммерческих условий, а не JSON-словарь, и рендерит только то, что прошло эталон. Вайбкодинг — в устройстве всего продукта: рабочее место менеджера, HTTP-API на Flask и на Go по одному контракту, Docker, тесты, прод на VPS. Практика продаж встретилась с инженерной культурой, и на пересечении получился не скрипт, а эксплуатируемая система.

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

Звонок, который длится два часа

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

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

Контур, ради которого всё затевалось, стоит определённых денег. Тёплый дом от «Дом-Мастер» считается по простой формуле: площадь умножается на 75 000 ₽ за квадратный метр. Цифры в документах ориентировочные, финал всегда после выезда и спецификации, но ошибка на этапе КП значит, что клиенту называют сумму, с которой потом придётся объясняться. Для домов из клееного бруса, отдельной линейки «Дом Форест», смета вообще считается по этапам, а не по ставке за метр. Чем сложнее продукт, тем дороже ручная ошибка.

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

Ответ — OfferDesk. Веб-CRM отдела продаж, которая начинается там, где кладут трубку, и заканчивается утверждённым PDF в почте клиента. Но прежде чем разбирать, как она устроена, нужно понять главное: это не чат-бот. Это рабочее место.

Не чат-бот, а CRM отдела продаж

Первое, что приходится объяснять про OfferDesk, — это то, чем он не является. Telegram-бот здесь не продукт. Он не принимает заявки, не ведёт диалог с клиентом, не продаёт дома в чате. Telegram в этой архитектуре выполняет одну роль: канал доставки готового предложения, и то опциональный, если клиент сам привязал чат по персональной ссылке из карточки сделки. Основной канал — обычный email. Вся настоящая работа происходит в браузере, в полноценном рабочем месте менеджера.

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

Карта продукта читается как одна прямая линия. Звонок — менеджер создаёт сделку и вставляет протокол: текстом или файлом .txt, .docx, .pdf. Эталон — локальный парсер вытягивает структурированные поля (телефон, email, участок, площадь, материал, сроки, финансирование, бюджет, Telegram клиента) и считает процент заполнения. КП — если данных достаточно, система генерирует PDF через OpenAI, Jinja2 и WeasyPrint. Утверждение — менеджер смотрит черновик с водяным знаком «ЧЕРНОВИК», правит, нажимает «утвердить», получает «УТВЕРЖДЕНО». Отправка — готовый документ уходит клиенту по email или в Telegram. Пять шагов, каждый со своим контролем.

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

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

Эталон — главный герой

Если в OfferDesk и есть сердце, то это не нейросеть. Нейросеть здесь работает на последних метрах: превращает структурированные данные в связный текст коммерческих условий. Сердце — это etalon_protocol.md, эталон протокола: список полей, которые обязаны быть в разговоре, чтобы предложение вообще имело смысл. Телефон, email, участок, площадь, материал стен, сроки, финансирование — обязательные. Бюджет и Telegram клиента — опциональны. Для домов из клееного бруса добавляется ещё одно обязательное поле: проект из каталога «Дом Форест», потому что без него смета по этапам не собирается.

Механика проверки бесхитростна и оттого жестка. Regex-парсер проходит по транскрибации, сопоставляет найденное с эталоном и считает процент заполнения. Дальше срабатывает порог — и порог этот, в отличие от настроения менеджера, не торгуется. Настраивается через ETALON_KP_THRESHOLD, по умолчанию 80. Три сценария, три разных следующих шага.

Между этими тремя ветками и живёт вся польза. Обычная CRM отдела продаж фиксирует факт: «звонок был, сделка создана». OfferDesk фиксирует качество звонка — и превращает его в число, с которым можно работать. Процент заполнения эталона — это измеритель того, насколько хорошо менеджер провёл разговор, в той же метрике, что и готовность сделки к КП. Это не оценка продавца, это оценка данных. Но именно потому, что она не субъективна, с ней нельзя поспорить и нельзя проигнорировать.

Внутри команды это решает вторую боль: отсутствие единого стандарта. У одного менеджера после звонка — полный протокол, у другого — три слова и впечатление. Без эталона эти два звонка выглядят одинаково: «работаем». С эталоном они выглядят как 96% и 31%, и руководитель видит разницу не наощупь, а на дашборде. Учебные протоколы в knowledge_base/ (demo_protocol_1.md на сто процентов и demo_protocol_2.md на сорок три) сделаны, чтобы эту разницу можно было потрогать на тренировке, а не на живом клиенте.

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

Два шаблона, одна логика

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

Первый шаблон — тёплый контур «Дом-Мастер». Он включается для газобетона и стандартной комплектации. Расчёт прозрачен: площадь умножается на 75 000 ₽ за квадратный метр. Никаких скрытых коэффициентов, никакой многоэтажной сметы — клиенту предлагается понятная ставка и понятный контур дома. Второй шаблон — клееный брус «Дом Форест», отдельная линейка с собственной логикой. Здесь ставка за метр не работает: смета собирается по этапам, к ней прибавляются 5% накладных, а в шаблон вшиты логотип и соцсети. Это другой продукт, и ему нужен другой документ, не просто другая цифра.

То, что выбор делает система, а не менеджер, — не косметика. Менеджер, которому дают выбирать шаблон вручную, рано или поздно выберет тот, что проще, или тот, что привычнее. Машина смотрит на поле «материал» в распарсенном протоколе и решает безошибочно и без настроения. Это снимает с человека ещё одно решение — из тех десятков мелких, что в сумме и съедают два часа.

Но самый важный узел здесь — не генерация, а ворота утверждения. Система не отправляет КП клиенту сразу после генерации. Сначала появляется черновик с водяным знаком «ЧЕРНОВИК» набег через всю страницу. Менеджер читает его, правит коммерческие условия (связным текстом, а не JSON-словарём, который модель иногда пытается выдать и который система отклоняет), и только после явного нажатия «утвердить» водяной знак меняется на «УТВЕРЖДЕНО». Черновик клиенту не уходит по определению. Это закрывает третью боль: риск, что сырые, непроверенные цифры окажутся у клиента раньше, чем у руководителя.

К воротам пристроена ещё одна незаметная, но дорогая деталь — устойчивость к обрыву. Если в момент генерации рвётся сеть или OpenAI отдаёт таймаут, система не падает и не заставляет начинать сначала. Она повторяет генерацию без LLM, по уже собранным данным, и доводит документ до состояния, в котором его можно править. Нейросеть здесь — желательный, но не единственный путь. Это редкое для AI-продуктов отношение к собственной зависимости: машина спроектирована так, чтобы продолжать работать, когда главная магия недоступна.

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

Скучный стек, который не стыдно в прод

Когда доходишь до того, на чём OfferDesk написан, возникает странное чувство: разочарование от отсутствия хайпа. Никакого модного фреймворка, никакой распределённой архитектуры ради архитектуры, никакой векторной базы. Python 3.11, Flask под Waitress, SQLite, Bootstrap 5 на фронте. OpenAI как текстовая модель. Jinja2 рендерит HTML, WeasyPrint превращает HTML в PDF с кириллицей через зашитые в репозиторий шрифты DejaVu. Отправка — обычный SMTP и Telegram Bot API. Это стек, который любой знакомый с веб-разработкой человек прочтёт за вечер.

И именно это в нём ценно. Учебно-продуктовый прототип, по описанию автора, должен работать на боевом VPS, а не производить впечатление на конференции. Поэтому рядом с Flask-приложением лежит go_server/ — реализация того же HTTP-контракта на Go. Контракт описан в OpenAPI 3.1: три эндпоинта — /health, /api/report, /api/kp. На Flask или на Go снаружи неразличимо. Это не «переписали на Go, потому что модно». Это возможность выбрать runtime под нагрузку, не меняя потребителей.

Эксплуатационная часть выдаёт отношение к продукту как к системе, а не как к скрипту. Production живёт на VPS под systemd, с logrotate, health-checkом каждые пять минут и алертом, если что-то отъехало. База deals.db бэкапится при каждом деплое и перед загрузкой демо — потому что кнопка «Загрузить демо» на боевой CRM по-честному удаляет существующие сделки, и откат должен быть. OpenAI на российском VPS ходит через NL-прокси (OPENAI_PROXY), потому что без него внешнего API просто нет. Сессии Flask защищены сменным SECRET_KEY, HTTP-API — токеном FLASK_API_TOKEN, Telegram — allowlistом разрешённых идентификаторов. Всё это не маркетинг, а ремесло.

Качество подтверждается тестами, и это слово здесь не для красоты. В репозитории — unit- и e2e-проверки эталона, пайплайна CRM, аналитики, напоминаний по зависшим сделкам, генерации КП для газобетона и для бруса, smoke-тесты самой CRM. Есть скрипты деплоя, проверки эндпоинтов, load-тест, reset и загрузка демо. Есть AUDIT.md — аудит кода, лежащий рядом с кодом, а не спрятанный. Прод — 194.67.103.144:5001, health — GET /health. Ничего из этого не звучит как «инновационная AI-платформа». Всё звучит как система, которую не стыдно отдать в чужие руки.

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

Поворот

Теперь, когда четыре подглавы разложены, видно то, что по отдельности было неочевидно. Четыре линии — «не чат-бот», «эталон», «ворота утверждения», «скучный стек» — сходятся в одну точку, и эта точка переворачивает привычное представление об AI в продажах.

Ждёшь от нейросети одного: чтобы она писала. Загрузил разговор — получил документ, готовый к отправке. В этой картине LLM — автор, а человек — курьер, который относит результат клиенту. Чем умнее модель, тем лучше текст, тем меньше работы. Логика простая и поэтому ошибочная.

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

В этом свете вся архитектура читается иначе. Страница «Недостающие данные» — не ошибка, а зеркало. Дашборд с процентом заполнения — не отчёт, а рентген качества звонков. Ворота «ЧЕРНОВИК → УТВЕРЖДЕНО» — не бюрократия, а линия обороны от собственной скорости. Система не даёт менеджеру ответ. Она показывает ему, чего он не спросил, и заставляет спросить. Зеркало, а не волшебная палочка.

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

Катарсис: цифры, которые честно остаются оценкой

Теперь можно честно поговорить о цифрах — и эта честность важнее самих цифр.

Оценка бизнес-эффекта OfferDesk построена на прозрачной модели, и её надо держать в голове как оговорку, а не как мелкий шрифт. Допущения: зарплата менеджера отдела продаж в стройке и инженерных сетях — около 140 000 ₽ в месяц, что с социальными взносами даёт стоимость часа примерно 1 100 ₽ при 164 рабочих часах в месяц. Время обработки одной заявки вручную — два часа; с OfferDesk — полчаса. Из этих допущений и рождается всё остальное.

Здесь обязательно остановиться и назвать источники, потому что без них те же цифры превращаются в голое утверждение. Зарплатные ориентиры — рынок труда hh.ru. Методология «время → деньги» и бенчмарки конверсии — материалы McKinsey и HubSpot за 2022–2024. Кейсы по автоматизации КП в строительстве и инженерных сетях — публикации PapAI Soft и rocai.ru за 2024–2026. Расчёт сознательно консервативный: отдельные кейсы показывают до минус 95% по времени подготовки КП, но в модель заложены скромные 75%. Все эти числа подлежат подтверждению на пилоте и в презентации прямо помечены как оценка, а не факт продукта.

Но если остановиться на цифрах, легко пропустить главное. Минус 75% — эффект, который видит менеджер. ×3–4 заявок — эффект, который видит отдел. ~790 тыс ₽ — эффект, который видит бухгалтер. А есть ещё один, который не выражается в одном числе, но меняет роль руководителя. Воронка «звонок → КП → отправка → закрытие» наконец видна целиком: средний чек, сделки в работе, график за две недели, разбивка по статусам, напоминания по зависшим больше трёх дней сделкам. Руководитель перестаёт собирать картину по обрывкам и начинает ею управлять.

В этом катарсис. Ценность OfferDesk — не в том, что он пишет КП быстрее. И даже не в том, что экономит 790 тысяч. Ценность — в новой рамке: продажа становится дисциплинированной воронкой, измеримой от первого поля протокола до статуса «проиграна» или «выиграна». Документ — побочный продукт. Дисциплина и прозрачность — основной. Когда воронку видно, её можно улучшать. Когда не видно, можно только надеяться на талант отдельных менеджеров и гореть на их ошибках.

Послесловие: какой у вас эталон?

OfferDesk сделан для одной компании, но его логика не привязана к стройке. Воронка «входящий лид → обработка → протокол → квалификация → КП → отправка» — скелет любого процесса «Маркетинг-продажи», будь то B2C или B2B. Замените «материал стен» на «тип лицензии», «площадь участка» на «объём закупки», «смету по этапам» на «тарифный план» — и тот же эталон, тот же порог, те же ворота утверждения заработают в любом отделе продаж. Боль ручной сборки КП одинакова везде: менеджер заканчивает разговор и садится переписывать его в документ. Инструмент, который вместо этого говорит «дособери по скрипту», нужен не только домостроителю.

Развитие системы лежит в стороне, логичной для продуктового прототипа, — в интеграции с учётной системой компании. Первая точка — 1С: актуальные прайс-листы вместо ориентировочных 75 000 ₽ за метр, живые цены в КП, а не «цифры подлежат уточнению». Дальше по той же линии — создание договора на основе утверждённого КП и выставление счёта на оплату. Сейчас OfferDesk доводит сделку до отправленного предложения; следующая итерация доводит её до документа, с которого начинается платёж. А за ней маячит выгрузка во внешние CRM — Битрикс24, amoCRM — для тех, кто не готов менять привычную систему, но хочет забрать отсюда дисциплину эталона.

Но прежде чем обсуждать интеграции и пилоты, каждому, кто дочитал до этого места, стоит задать себе один вопрос. Не «какую CRM купить» и не «какую нейросеть подключить». Вопрос другой: какой у вас эталон? Какой список обязательных полей должен содержать каждый звонок вашего отдела продаж, чтобы предложение по нему можно было сформировать без догадок? Если вы не можете выписать этот список прямо сейчас, на одном листе, — значит, у вас нет стандарта. Значит, каждый менеджер продаёт по своему, и качество сделки зависит от того, кто взял трубку, а не от того, как устроен процесс. OfferDesk начинается не с кода и не с OpenAI. Он начинается с этого листа.

А пока — закройте этот текст и попробуйте выписать свой эталон. Это бесплатно и ни к чему не обязывает. Зато быстро покажет, нужна ли вам CRM, которая отказывается писать КП, или вы и так спрашиваете всё, что нужно.

#CRM #AIвПродажах #АвтоматизацияПродаж #КоммерческоеПредложение #Вайбкодинг