Как создать CRM с ИИ: ТЗ, экраны и проверка результата

Чтобы создать CRM с помощью нейросети, сначала опишите процесс продаж и состав данных, затем соберите одну рабочую цепочку: клиент, сделка, следующий шаг и результат. Генерацию стоит начинать с этой цепочки, а не с просьбы скопировать все возможности большой CRM.

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

Когда имеет смысл создавать свою CRM

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

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

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

Разделите клиента, контакт и сделку

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

Для учебного сценария достаточно трёх сущностей:

Не добавляйте поле только потому, что оно встречается в другой CRM. У каждого поля должно быть назначение: какое решение сотрудник принимает по этому значению? Поля «на всякий случай» увеличивают время заполнения и быстро перестают обновляться.

На этапе прототипа используйте вымышленные названия: «Компания А», «Компания Б», «Учебная сделка». Настоящие телефоны и почтовые адреса для проверки структуры не требуются.

Опишите статусы как правила работы

Для пилота можно взять воронку «Новая → В работе → Предложение → Выиграна / Проиграна». Это пример, а не обязательная схема для любой компании.

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

Перед генерацией ответьте на вопросы:

• Кто создаёт сделку и назначает ответственного?
• Может ли менеджер менять сумму и клиента после создания?
• Какие поля нужны при закрытии сделки?
• Можно ли вернуть закрытую сделку в работу?
• Кто видит сделки других сотрудников?

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

Готовое задание для генерации CRM

Создай веб-приложение CRM для небольшой команды продаж.

Первый сценарий: создать клиента, добавить ему сделку,
назначить следующую задачу и изменить статус сделки.

Клиент: название и заметка.
Сделка: название, ссылка на клиента, сумма в рублях,
ответственный и статус.
Задача: ссылка на сделку, текст, срок, выполнена или нет.

Статусы: Новая, В работе, Предложение, Выиграна, Проиграна.
Экраны: список клиентов, список сделок, карточка сделки.
В списке сделок нужны фильтры по статусу и ответственному.
В карточке должны быть следующий шаг и открытые задачи.

Используй только учебные данные «Компания А» и «Учебная сделка».
Не подключай телефонию, оплату и рассылки.
Не отправляй сообщения и не добавляй вымышленные интеграции.

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

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

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

Принимайте CRM по действиям, а не по скриншоту

Для одинаковой проверки возьмите учебные записи CRM в JSON и лист приёмки. В примере два клиента и три сделки: общая сумма — 22 000 ₽, выигранные — 10 000 ₽, открытые — 5 000 ₽. Это вымышленные записи с контрольными суммами. Они не подтверждают работу импорта в вашем приложении; если импорт не предусмотрен, внесите записи вручную.

Сумма выигранных сделок не равна полученным оплатам: платежей в этом примере нет.

Проверяйте всю цепочку на одной записи. Создайте «Компанию А», добавьте учебную сделку, поставьте задачу, измените статус и перезагрузите страницу. Затем откройте запись снова и проверьте, что связи и значения сохранились.

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

Проверьте доступ из двух учётных записей

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

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

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

Исправляйте обнаруженные проблемы небольшими запросами

Хорошая правка описывает воспроизведение и ожидаемый результат:

После переноса сделки в «Выиграна» и обновления страницы статус возвращается в «В работе». Исправь сохранение статуса. Поля клиента и внешний вид доски не меняй.

Плохая правка объединяет несколько несвязанных задач: «сделай как в большой CRM, добавь аналитику и красивый дизайн». После такого изменения трудно понять, какая функция сломалась и почему.

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

Что оставить за пределами первого запуска

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

До переноса рабочих сведений определите, как получить данные обратно и как восстановить их после ошибки. Не обещайте экспорт или резервную копию, пока не проверили конкретный способ и полученный файл.

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

Как создать CRM в Mottorable — ИИ-конструкторе приложений

1. Зарегистрируйтесь на бесплатном тарифе — без оплаты, без банковской карты.
2. Вставьте в чат учебное ТЗ из этой статьи и замените поля, этапы и роли на свои.
3. Проверьте первую версию по чек-листу приёмки. Правки — сообщением в чате или кликом по элементу в превью.
4. Опубликуйте CRM в один клик и повторите проверку доступа из двух учётных записей.

Что проверить о Mottorable до старта:

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

Отправная точка — сценарий создания CRM. Рабочую готовность оценивайте по результатам приёмки.

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