Как создать CRM с помощью вайбкодинга и не автоматизировать хаос

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

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

Только после этого собирают минимальную CRM, тестируют её на обезличенных данных и решают, готова ли система к реальной клиентской базе.

Иначе всё происходит быстро, красиво и бессмысленно.

Светлана Козырина
стратег-маркетолог, 23 года · основатель Бюро «УМ»

CRM за два дня: что можно собрать быстро, а что нельзя

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

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

CRM не определит сама:

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

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

Что такое вайбкодинг CRM простыми словами

Вайбкодинг в этой задаче не означает «написал одну фразу и получил идеальную CRM». Это итерационная работа с AI-разработчиком.

Человек описывает задачу и критерии правильности. AI предлагает структуру, интерфейс или код. Человек проверяет, задаёт уточнения, принимает или отклоняет решение. Затем цикл повторяется.

Роль собственника здесь особенно важна. Ему не обязательно писать код, но именно он должен дать бизнес-контекст:

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

Технический специалист всё равно нужен там, где начинаются архитектура, права доступа, интеграции, безопасность, нагрузка и боевой контур. Вайбкодинг снижает порог прототипирования. Он не отменяет ответственность за production.

Что сделать до настройки CRM

1. Определить цель системы

«Хранить клиентов» не цель. Электронная записная книжка тоже хранит клиентов.

Цель должна быть управленческой. Например:

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

Если у системы нет ясной задачи, в неё начинают добавлять всё подряд.

2. Выделить сегменты клиентов

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

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

3. Пересобрать путь клиента

Нарисуйте путь от первого касания до покупки, повторной продажи, удержания и возврата.

Для каждого участка ответьте:

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

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

4. Описать этапы продаж

Хороший этап отвечает на вопрос «что уже произошло?».

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

Для каждого этапа зафиксируйте:

1. Условие входа.
2. Обязательное действие.
3. Ожидаемый результат.
4. Условие выхода.
5. Ответственного.

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

5. Решить, что контролировать

Обычно руководителю нужны не пятьдесят полей, а несколько опорных данных:

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

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

Какой должна быть минимальная CRM

В первой версии не нужна вся будущая империя.

Минимальный набор сущностей:

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

Минимальный набор рабочих представлений:

• воронка;
• просроченные действия;
• сделки без следующего шага;
• зависшие сделки;
• причины паузы и потери;
• клиенты на удержание и возврат.

Каждая кнопка, роль и поле должны отвечать на рабочий вопрос. Всё, что «когда-нибудь пригодится», оставьте на потом.

Пошаговый план создания CRM с помощью вайбкодинга

Шаг 1. Провести аудит текущих продаж

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

Для проектирования не нужны персональные данные. Имена, телефоны и переписки можно заменить тестовыми значениями.

Шаг 2. Нарисовать процесс вне CRM

Соберите простую цепочку:

событие → действие → результат → следующий этап

Если процесс нельзя объяснить на схеме, код не сделает его понятнее.

Шаг 3. Составить короткое ТЗ для AI

Опишите:

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

Сначала попросите AI показать модель данных, пользовательские сценарии и риски. Код начинайте после проверки этой логики.

Шаг 4. Собрать прототип на тестовых данных

Начните с одного сквозного маршрута: новая заявка, квалификация, встреча, предложение, решение.

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

Шаг 5. Проверить сценарии, а не красоту

Протестируйте обычные неудобные ситуации:

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

Красивое демо проходит идеальный сценарий. Рабочая CRM выдерживает неидеальный.

Шаг 6. Провести техническую проверку

До загрузки реальной базы проверьте:

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

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

Логи тоже требуют дисциплины: в них не должны попадать пароли, токены, ключи, строки подключения и лишние персональные данные.

Для CRM с данными граждан России отдельно согласуйте контур хранения и обработки. Действующая редакция 152-ФЗ ограничивает использование зарубежных баз при сборе и хранении персональных данных граждан РФ. Это не раздел, который стоит закрывать фразой «потом разберёмся».

Шаг 7. Запустить пилот

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

Не переносите весь бизнес одним движением. Сначала докажите, что один процесс проходит от начала до конца.

Шаг 8. Обучить команду и назначить владельца CRM

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

Иначе каждый сотрудник начнёт собирать свою версию правды внутри общей CRM.

Шаг 9. Дорабатывать по данным

Сначала устраните самый дорогой разрыв. Например, сделки без следующего шага или клиенты, которых никто не возвращает.

Потом добавляйте автоматизацию. Не наоборот.

Шаблон первого промпта для AI-разработчика

Мы строим CRM для [тип бизнеса].

Ею пользуются [роли].

Цель первой версии: [одна управленческая задача].

Путь сделки: [этапы]. Для каждого этапа заданы условие входа,
обязательное действие, ожидаемый результат и условие выхода.

Основные сущности: клиент, контакт, сделка, действие и задача.

Обязательные поля: [список]. Рядом с каждым полем объясни,
какое решение от него зависит.

Система должна показывать [3-5 управленческих срезов].

Пока не добавляй [интеграции и функции вне MVP].

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

Главная сила этого промпта не в формулировке. Он заставляет сначала договориться о модели, а уже потом рисовать экран.

Как проверить, что CRM управляет продажами

Перед пилотом пройдите чек-лист:

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

Если половина пунктов не выполняется, вам пока нужна не новая автоматизация, а пересборка логики.

Частые ошибки

Начать с канбана

Карточки, которые двигаются по колонкам, выглядят как CRM. Но пока колонки не связаны с правилами, это просто дорогая доска.

Скопировать чужую воронку

Чужие этапы описывают чужой бизнес. Возьмите механику, но проверьте каждый переход на своём пути клиента.

Сделать двадцать статусов

Если статус не меняет действие, срок, ответственность или решение, он не помогает управлять продажами.

Загрузить реальные данные в непротестированный контур

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

Смешать клиента, контакт и сделку

Один клиент может иметь несколько контактов и несколько сделок. Если всё хранится в одной карточке, история быстро ломается.

Не предусмотреть экспорт и резервное копирование

Своя CRM без выхода из системы превращается в новую зависимость.

Оставить систему без владельца

Код можно обновить. Размытые правила обновляются сами и обычно в худшую сторону.

Когда своя CRM не нужна

Иногда честный ответ такой: не надо её строить.

Готовая CRM лучше, если:

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

Вайбкодинг снижает стоимость первого прототипа. Он не отменяет стоимость владения.

Какие показатели заложить

Не начинайте с идеального дашборда. Начните с показателей, которые помогают принимать решения:

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

Не ищите «правильный процент» из чужого отчёта. Сначала зафиксируйте базовую линию своего бизнеса.

Вывод: сначала логика продаж, потом CRM

Рабочий порядок выглядит так:

путь клиента → правила продаж → контрольные точки → минимальная CRM → тест → автоматизация

Вайбкодинг ускоряет сборку. Это сильный инструмент, если вы знаете, что именно собираете.

Если CRM уже есть, а воронка всё равно ничего не объясняет, начинать надо не с новой кнопки. На «Точке прорыва» мы разбираем путь клиента, сегменты, провалы продаж и точки контроля. После этого становится понятно, что действительно нужно собирать и автоматизировать.

Иначе вы автоматизировали не продажи. Вы автоматизировали бардак.