CRM и внутренние инструменты нейросетью: без программиста

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

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

Что считать «CRM без программиста», а что нет

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

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

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

Собранный нейросетью инструмент — компактное веб-приложение с вашей моделью данных и вашим порядком действий. Это тот класс задач, который годами не доходил до разработки — «ради такого не будем нанимать программиста» — и оседал в таблицах и переписке. Общая логика сборки разобрана в гайде как создать приложение нейросетью.

Как это работает в Zugo по шагам

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

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

Шаг 3. Дождаться проверенной сборки. Виден живой лог с таймером и чекпоинтами по ходу. Статус «проверено» означает конкретную вещь: сборка реально загрузилась и отрисовалась в песочнице, а не «код скомпилировался без ошибок». Без технического фона это критично — иначе роль тестировщика достаётся вам.

Шаг 4. Довести правками в чате. «Добавь в карточку клиента поле "источник" с выбором из списка». «Выведи на главную счётчик заявок в работе». Каждая правка проходит тот же цикл сборки и проверки. Ускоряет дело одна привычка: один раз запишите скилл воркспейса вроде «мы называем клиентов контрагентами, даты — в формате ДД.ММ.ГГГГ», и следующие сборки учтут это без напоминаний.

Начинать с чистого листа не обязательно: в библиотеке шаблонов есть готовый CRM-макет Orbit с воронкой сделок и контактами, и кнопка «Использовать шаблон» клонирует его в новый проект мгновенно — без AI и без списания кредитов.

Где живут данные и кто получает доступ

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

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

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

Разграничение доступа описывается словами в том же промпте: «менеджер видит только свои сделки, руководитель — все и сводку по отделу». Здесь нужна честная оговорка: любое приложение с данными сотрудников — собранное AI или написанное руками — заслуживает отдельной ревизии того, кто что может читать. Прежде чем заводить туда персональные данные клиентов, просмотрите правила доступа сами; в дашборде Supabase политики видны и правятся напрямую, и это само по себе аргумент в пользу коннектора, когда ставки растут.

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

Что писать в промпте: разбор на примере отдела продаж

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

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

Что здесь стоит перенести в свой промпт: конкретные сущности с конкретными полями, этапы вашими словами, разница между главным экраном и карточкой, два явно разведённых типа пользователей. Это и есть граница между инструментом под ваш процесс и абстрактной CRM. Дальше идут обычные правки в чате: «добавь на воронку фильтр по периоду», «если дата следующего контакта прошла — подсвечивай сделку», «выгружай список сделок в CSV по кнопке».

Что нужно внутреннему сервису — и как это закрывает Zugo

Сегодня подключаются шесть внешних коннекторов плюс встроенный Zugo Cloud: Supabase, Stripe, Resend, Google Analytics, Vercel и GitHub. В каталоге видно больше — HubSpot, Salesforce, Telegram, Notion, Google Sheets, — но они честно помечены как «в работе» или «по запросу» и сегодня не подключены; если весь ваш сценарий держится на интеграции с внешней CRM по API, это стоит учесть заранее. А если внутри сервиса нужно принимать деньги, механика разобрана в гайде про оплату через Stripe в AI-приложении.

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

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

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

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

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

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

Сколько это стоит и что будет, если вы уйдёте

Начать можно бесплатно: стартовые кредиты Zugo выдаёт без привязки карты, и их хватает, чтобы собрать первую рабочую версию и показать её команде. Pro стоит $25 в месяц за 200 кредитов — примерно 16 полных платформ или 33 быстрых сборок, — туда же входят собственные домены. Business — $99 в месяц. Детали на странице тарифов.

Вопрос «что будет, если мы уйдём» для внутреннего сервиса важнее, чем для лендинга: в нём накапливаются рабочие данные компании. Ответ из двух частей. Код не заперт в билдере — экспорт в GitHub создаёт настоящий репозиторий со стандартным scaffold (src/, package.json, конфиг Vite), как это устроено, разобрано в гайде про экспорт приложения в GitHub. Данные не заперты, если подключён Supabase: проект Postgres ваш в любом случае. Связка этих двух вещей и есть страховка от привязки к платформе. А если вы сейчас выбираете между AI-билдерами, сравнение по цене входа, проверке сборок и экспорту лежит в разборе Zugo, Lovable и Bolt.

С чего начать сегодня

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