AI для привлечения клиента — рабочая схема. Особенно если бить сразу по нескольким болям
В первой части мы разобрали простой принцип: AI ускоряет MVP только внутри зафиксированной гипотезы и Must-have. Без границ scope он просто быстрее производит лишний объём.
Продолжение про другое: привлечение клиента через AI-ускоренный MVP — это не теория. Это рабочий коммерческий приём. И он становится заметно сильнее, когда один короткий релиз закрывает не одну, а сразу несколько болей заказчика.
Короткий ответ: клиент чаще покупает следующий этап не потому, что «AI модный», а потому что на демо он увидел решение сразу нескольких своих ежедневных проблем — в одном проходимом сценарии.
Почему «одна боль — один слайд» слабее, чем вертикаль из нескольких болей
У B2B-заказчика почти никогда нет одной изолированной проблемы. Обычно есть связка:
| Боль | Как звучит у заказчика | Что он на самом деле теряет |
|---|---|---|
| Продажи / согласование | «Нам сложно объяснить ценность внутри» | Сделка буксует на слайдах и устных обещаниях |
| Операционка | «Считаем в Excel, ошибаемся, долго» | Время специалистов и брак в спецификациях |
| Знания | «Формулы живут у одного человека в файле» | Риск потери экспертизы и сложный онбординг |
| Масштаб | «Потом ещё 1С / CAD / другие линейки» | Страх начать, потому что кажется «надо всё сразу» |
Если MVP закрывает только UI «для красоты», возражения остаются.
Если MVP показывает считающий сценарий + понятный результат + путь дальше — снимаются сразу несколько стоп-факторов.
AI здесь помогает не «добавить нейросеть в продукт», а быстрее собрать такую вертикаль: разобрать Excel/ТЗ, набросать доменные правила, поднять мастер, сделать демо-стенд.
Кейс: MVP подбора фурнитуры Blum
Разберём на реальном инженерном проекте.
Суть проекта
Нужно было сделать веб-инструмент CPQ-типа для мебельного производства: подбор и расчёт фурнитуры Blum, в первую очередь подъёмных систем AVENTOS HF top.
Не «каталог картинок», а рабочий путь:
- задать параметры проекта и фасада;
- получить расчёт (нагрузка, механизм, петли, спецификация);
- увидеть предпросмотр;
- сохранить проект и распечатать результат;
- при необходимости пройтись по справочнику номенклатуры.
Какая проблема стояла перед клиентом
До цифрового MVP процесс выглядел типично для сложного предметного домена:
- ключевой расчёт жил в Excel-калькуляторе;
- номенклатура и логика дополнительно опирались на PDF-каталог и внутренние материалы;
- специалист вручную переносил результат в документы;
- полный enterprise-контур (все линейки Blum, 1С, БАЗИС, роли, аудит) выглядел дорого и долго, если строить «с нуля и сразу всё».
То есть боль была не только техническая. Это был клубок:
| Направление боли | Конкретно в проекте Blum |
|---|---|
| Инженерия | Сложно быстро и прозрачно получить спецификацию HF top |
| Знания | Правила «заперты» в Excel и головах |
| Коммерция / внутренние стейкхолдеры | Трудно показать будущее решение без работающего демо |
| Развитие | Страх, что без 1С/полного каталога начинать бессмысленно |
Какую гипотезу мы проверяли первым релизом
Если технолог/конструктор сможет за одну сессию пройти расчёт AVENTOS HF top в вебе и получить спецификацию без ручного Excel-цикла, заказчик подтвердит ценность цифровизации и согласится на следующий этап (другие линейки, серверное хранение, интеграции).
Это и есть привлечение через MVP: не обещать платформу, а показать один достоверный кусок ценности.
Как AI помог бить сразу по нескольким болям
AI не был «фичей для пользователя» в первой версии. Он ускорял delivery-контур команды по нескольким фронтам одновременно.
| Боль заказчика | Что сделали в MVP | Где AI ускорил команду |
|---|---|---|
| Долгий/хрупкий расчёт в Excel | Веб-мастер HF top + доменный модуль формул | Черновик функций, правил механизмов, типов, edge-cases |
| Непрозрачная спецификация | Экран результата: механизм HF 25/28/31, петли, позиции, warnings | Каркас result UI, структура спецификации, тексты состояний |
| Знания только в файле | Правила вынесены в код (calculateHfTop, таблица механизмов) |
Быстрый перенос логики из описания/Excel в TypeScript-каркас |
| Нужно «потрогать», а не слушать | Демо-стенд (Docker / Node), сохранение и печать проекта | Обвязка запуска, чеклисты, сценарий демо |
| Страх «надо сразу всё» | Жёсткий Not Now: остальные линейки, 1С, auth, БД | Генерация шла только внутри Must-have, без расползания |
Итог для клиента на демо: он видит не абстрактный AI-pitch, а закрытие своих болей — быстрее считать, понятнее получать спецификацию, безопаснее начинать без enterprise-перегруза.
Что именно реализовали
Пользовательский путь
- дашборд проектов;
- мастер расчёта HF top: проект → размеры → материал → результат;
- живой предпросмотр фасада на шагах;
- сохранение проекта;
- печать;
- справочник Blum с поиском и категориями (демо-выборка).
Техническое решение
| Слой | Решение в MVP | Зачем |
|---|---|---|
| UI | Next.js 14 (App Router), React 18, Tailwind | Быстро собрать проходимый мастер |
| Domain | TypeScript-модуль расчёта HF top | Формулы отделены от экранов |
| Data | Локальный справочник + материалы в коде | Не ждать интеграций для демо |
| Storage | localStorage |
Замкнуть путь «посчитал → сохранил → напечатал» |
| Ops | Docker / npm run build, базовый CI |
Стенд воспроизводим, не «только на ноутбуке» |
| Quality | Скрипты сверки с Excel-эталоном | Демо выглядит инженерно, расхождения видны |
Ключевой инженерный ход: доменный расчёт не смешан с UI.
UI собирает input, модуль считает вес фасада, LF, выбирает механизм, собирает спецификацию. Позже это же ядро можно вынести в API и связать с 1С — не переписывая мастер с нуля.
Что сознательно не вошло в первый релиз
| Отложено | Почему Not Now |
|---|---|
| HK top, LEGRABOX, TANDEMBOX | Сначала доказать один сценарий |
| Интеграции с 1С и БАЗИС | Не нужны, чтобы проверить спрос на веб-путь |
| Auth, роли, аудит | Enterprise-горизонт, не демо-гипотеза |
| Полный PDF-каталог как онлайн-база | Демо-выборки хватает для сценария |
| Серверная БД | Для первого эксперимента избыточна |
Именно это позволило быстро получить коммерческий эффект: показать ценность рано, не утонув в «платформе на годы».
Как несколько болей усиливают продажу следующего этапа
После такого MVP разговор с клиентом меняется.
| Было до демо | Стало после демо |
|---|---|
| «Нам нужна цифровизация вообще» | «Вот рабочий HF top — давайте расширять» |
| «Без 1С начинать рано» | «Сначала подтверждаем сценарий, 1С — следующий контур» |
| «Excel нас устраивает» | «Веб быстрее показывает спецификацию и удобнее для команды» |
| «Сложно оценить объём» | Есть граница Must/Not Now и понятный roadmap |
AI ускорил сборку.
Но продал следующий этап не AI как бренд, а закрытие нескольких болей в одном коротком пути ценности.
Практическая рамка: multi-pain MVP
Если повторять подход на других проектах:
- Соберите карту болей заказчика (продажи, операция, знания, интеграции, риск старта).
- Выберите один core path, который касается сразу 2–3 болей.
- Зафиксируйте Must/Not Now до генерации.
- Используйте AI на разборе эталона, домене, UI, стенде, сценарии демо.
- Оставьте человеку приёмку формул, обещания scope и критерии успеха.
- На демо явно покажите, какие боли уже закрыты, а какие осознанно отложены.
| Хороший multi-pain MVP | Плохой «AI MVP» |
|---|---|
| Один сценарий закрывает несколько болей | Много экранов ни про одну боль до конца |
| Есть эталон и сверка | «Похоже на правду» без проверки |
| Есть стенд по ссылке | Только презентация и Figma |
| Есть честный Not Now | Promise «сделаем всё сразу» |
Итог
Использование AI для привлечения клиента — рабочая штука.
Но максимальный эффект появляется не от генерации кода как таковой, а от сборки короткого MVP, который одновременно:
- ускоряет согласование;
- снимает операционную боль;
- вытаскивает знания из Excel в управляемый контур;
- показывает безопасный путь к большому scope без необходимости строить всё вчера.
Кейс Blum это хорошо иллюстрирует: вместо бесконечного обсуждения «платформы фурнитуры» заказчик получил считающий веб-сценарий AVENTOS HF top на современном стеке — и основу для следующего этапа уже на фактах, а не на слайдах.
FAQ
Обязательно ли называть AI в продаже заказчику?
Нет. Часто достаточно показать скорость и качество демо. AI — внутренний ускоритель delivery, если только он сам не является ценностью продукта.
Почему нельзя сразу закрыть все линейки Blum?
Потому что тогда снова пропадёт MVP: дольше до первого доказательства, дороже ошибка гипотезы. Сначала один достоверный путь.
Что было самым важным техническим решением?
Отделить доменный расчёт от UI и сохранить связь с Excel-эталоном. Это дало доверие на демо и задел на интеграции.
Как понять, что multi-pain MVP сработал?
Если после демо разговор смещается с «нужно ли нам это» на «в каком порядке расширяем» — гипотеза привлечения сработала.
