Как сделать CRM без кода: пошаговая сборка нейросетью

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

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

Что именно вы собираетесь заменить?

Ответ определяет всё остальное, поэтому его стоит дать до первого промпта. Под словом CRM живут две очень разные вещи.

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

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

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

Как разложить свой процесс на сущности и этапы?

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

Какие объекты вы ведёте. Клиент, сделка, объект, договор, заявка, задача. Обычно их два или три, а не десять. Если сущностей получилось больше пяти, скорее всего, часть из них это поля другой сущности.

Какие поля у каждой. Пишите те, которые реально заполняются. Поле, которое заводят «на всякий случай», через месяц пустое у всех записей и мешает читать карточку.

Какие этапы проходит запись. Своими словами, а не «квалификация, презентация, закрытие». Если у вас говорят «замер назначен», так и пишите: инструмент должен говорить на языке отдела.

Кто что видит. Менеджер видит свои сделки, руководитель все и сводку. Это описывается словами и превращается в разные экраны.

Как выглядит рабочий промпт для CRM?

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

Внутренняя CRM для отдела продаж [сфера].
Сущности: клиент (имя, телефон, адрес, источник заявки),
сделка (клиент, сумма, этап, дата следующего контакта, комментарии).
Этапы: [ваши этапы через запятую].
Главный экран: воронка по этапам с числом сделок и суммой в каждом.
Менеджер входит по почте, видит свои сделки, фильтр по этапу
и по дате следующего контакта.
Руководитель видит все сделки и сводку по менеджерам.
В карточке сделки можно менять этап, добавлять комментарий с датой
и планировать следующий контакт.

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

Дальше идут обычные правки в чате: «добавь фильтр по периоду на воронку», «подсвечивай сделку, если дата следующего контакта прошла», «выгружай список в CSV по кнопке». Каждая правка стоит 3 кредита. Формулировки разобраны в гайде как писать промт для ИИ-билдера.

Что делать с данными, которые уже лежат в таблице?

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

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

Затем решите, где данные будут жить. Zugo Cloud это встроенная база: ничего настраивать не нужно, подходит для прототипа и для инструмента на несколько человек. Коннектор Supabase даёт собственный Postgres в вашем проекте, и это правильный выбор, как только появляются настоящие клиентские данные: таблицу видно в дашборде, к ней можно выполнить SQL и загрузить туда историю напрямую. Разбор обоих путей в гайде про AI-приложение с Supabase.

Практическое правило: прототип на Zugo Cloud, боевая работа на Supabase. Перенос между ними это не катастрофа, но он проще на пустой базе, чем на заполненной.

Как развести доступы сотрудников?

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

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

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

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

Сколько это стоит?

Бесплатный тариф даёт 5 кредитов, этого хватает на первую рабочую версию, которую можно показать команде. Pro стоит $25 в месяц за 200 кредитов, это 33 быстрых сборок или 16 платформ, плюс свой домен. Business стоит $99 в месяц.

Простой инструмент на одном экране это обычная сборка за 6 кредитов. CRM с несколькими разделами это платформа: 12 кредитов за первые три страницы и по 3 кредита за каждую следующую. Правка стоит 3 кредита, в режиме Hi-Fi сборка и правка вдвое дороже: 12 и 6.

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

Как понять, что инструмент прижился?

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

Проверять это стоит по трём признакам, и все три видны через две недели. Первый: заносят ли данные в момент события или задним числом. Второй: смотрит ли кто-нибудь в главный экран, кроме вас. Третий: просят ли сотрудники правок. Отсутствие просьб это не одобрение, а равнодушие: люди не просят улучшить то, чем не пользуются.

Лечится это обычно не уговорами, а сокращением. Уберите поля, которые никто не заполняет, и экраны, на которые никто не заходит. Формулировка для чата: «убери из карточки сделки поля такие-то, оставь только эти». Правка стоит 3 кредита, и она почти всегда полезнее добавления новой функции.

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

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

Где проходит граница?

Три случая, где такой подход не лучший выбор.

Сложная серверная логика. Многоступенчатые согласования с эскалацией, расчёты по закрытым методикам, обмен с ERP по внутреннему протоколу. Интерфейс билдер соберёт, но начинку проектирует разработчик, и Zugo не заменяет команду разработки на таком продукте.

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

Большие объёмы и нагрузка. Инструмент на команду в десятки человек это рабочий сценарий. Система на сотни одновременных пользователей с аналитикой по миллионам записей это проект, который проектируют, а не описывают.

Между этими полюсами работает простая схема: собрать инструмент, месяц поработать в нём по-настоящему, а когда станет ясно, что процесс лёг, забрать код через экспорт в GitHub и продолжить с разработчиком. Первая версия за вечер обычно полезнее идеального техзадания за месяц. Начните с описания одного своего процесса на zugo.dev.