Разработка CRM под процессы компании: что заложить до кода
Владельцу компании, которому тесно в готовой CRM
Порядок разработки и список решений до сметы
7 мин
Заявки живут в разных местах, готовая CRM требует обходных действий
Каждый этап работы и ответственный видны в одной системе
Как подготовить разработку CRM: разобрать путь заявки, выбрать данные и роли, проверить отчёты на реальной работе команды.
Хотите разработать CRM под свою компанию? Откройте недавнюю заявку и пройдите её от первого сообщения до оплаты или отказа. Где сотрудник переписывал данные? Кто заметил задержку? Как владелец узнал итог? Эти ответы подскажут состав системы лучше списка желаемых кнопок. Если нужен готовый пример для стройки, посмотрите решение для строительной компании.
Когда своя CRM оправдана
Готовая система подходит, когда её этапы, роли и отчёты совпадают с вашей работой. Собственная разработка имеет смысл, если основные операции приходится вести параллельно в таблицах и чатах. Например, строительной компании нужен общий путь от заявки до замера, сметы, назначения бригады и закрытия объекта. У клиники другой путь: обращение, запись, приход, дальнейший контакт. Отраслевое название на коробке само по себе проблему не решает.
Проверьте три симптома. Во‑первых, сотрудники вводят один факт в несколько систем. Во‑вторых, руководитель собирает отчёт вручную и получает его уже после решения. В‑третьих, важный шаг остаётся вне карточки: смета ушла в личный чат, время врача поменяли по телефону, бригадиру сказали адрес голосовым сообщением. Если хотя бы один симптом стоит денег или времени каждую неделю, есть предмет для проектирования.
Необязательно сразу заменять всё. Иногда достаточно настроить действующую CRM и убрать лишние поля. В другом случае нужен отдельный экран для расчёта, который передаёт результат в существующую систему. Решение принимается после разбора потока, а не по названию платформы.
| Сигнал | Что выяснить до разработки | Возможный первый шаг |
|---|---|---|
| Заявка пропала | В какой канал пришла и кто должен был взять | Единая очередь входящих |
| Смета задержана | Где хранятся параметры объекта | Карточка замера и напоминание |
| Отчёт расходится | Как считаются этап и сумма сделки | Согласовать определения показателей |
| Сотрудник дублирует ввод | Какая запись должна быть главной | Связать источники данных |
Какие данные должны стать единственной правдой
На старте я отделяю сведения о клиенте от сведений о конкретной сделке. Один человек может обратиться повторно или по двум объектам. Если всё сложить в одно текстовое поле, история перемешается. В карточке клиента нужны контакт и согласованная история общения. В карточке сделки нужны источник, предмет запроса, этап, ответственный, следующий шаг, срок и результат. Дополнительные поля появляются только при понятном решении, которое на них опирается.
Цены особенно опасно копировать. Когда менеджер, сайт и бот читают три прайса, исправление одного файла оставляет два старых обещания. Определите владельца прайса, место изменения и порядок обновления. Если цена рассчитывается по площади, материалу и сложности доступа, формула должна иметь версию и понятный вход. Менеджер обязан видеть, какие значения использованы. Это помогает разбирать спорный расчёт без догадок.
Для клиники разделите медицинскую программу и работу с обращением. В CRM смотрите источник заявки, запись и дальнейший контакт. Медицинскую историю, назначения и доступ врача проектируйте отдельно. Это различие показано в примере медицинского центра.
Перед описанием полей пройдите маршрут заявки:
- найдите исходное сообщение и его канал;
- назовите сотрудника, который принял запрос;
- проверьте срок следующего действия;
- сверьте итог в карточке и отчёте.
Как превратить разговор с командой в задание
Попросите менеджера показать одну успешную, одну сорванную и одну зависшую сделку. Не спрашивайте только «какие поля вам нужны»: сотрудник перечислит привычные поля старой программы. Смотрите, какие действия он реально делает между звонком, сообщением, документом и задачей. У владельца отдельно узнайте, какие решения он принимает каждое утро и какие цифры проверяет в конце недели.
Схему полезно записать глаголами: «пришла заявка», «назначили ответственного», «согласовали замер», «отправили смету», «забронировали бригаду». Для каждого перехода укажите входные данные, событие, человека и допустимый срок. Так выявляются исключения: клиент перенёс замер, телефонов два, договор подписал другой человек, объект разделился на этапы.
- 1Новое обращениеДежурный менеджер
Должно случитьсяУвидеть канал и взять заявку
Где теряемСообщение осталось в личном чате
- 2ЗамерЗамерщик
Должно случитьсяСохранить параметры и дату
Где теряемФотографии остались в телефоне
- 3СметаМенеджер
Должно случитьсяОтправить расчёт и назначить ответ
Где теряемДокумент отправлен без задачи
- 4РаботаБригадир
Должно случитьсяПодтвердить дату и объём
Где теряемПлан работ разошёлся с продажей
После схемы можно обсуждать экраны. Нужна ли доска этапов, календарь, мобильное представление для бригадира, отчёт по источникам? Каждый экран должен поддерживать действие конкретного человека. Если ответа нет, экран пока не нужен.
Что показал строительный проект
В Radomir CRM я собрал CRM вокруг реального пути строительного заказа: от заявки и замера до работы бригады и финансов. На доске сделок видно 144 сделки в работе и 18 просроченных. Процесс разбит на 14 этапов, а на проблемных карточках есть подсказки о следующем действии. Это пример того, как состав этапов и экран руководителя проектируют под обязанности конкретной команды; копировать названия колонок в другую компанию без разбора процесса нельзя.
Как это выглядит в работе


Первым показан экран «Пульс бизнеса»: он связывает просрочки с деньгами. Следом доска показывает этап и срок. Важно, что сотруднику хватает одной карточки для работы, а владелец получает отчёт из тех же записей. Если отчёт приходится заново собирать из другой таблицы, система снова раздваивается.
Как принять результат разработки
Согласуйте несколько сквозных проверок ещё до начала работ. Создайте заявку с сайта, найдите её в CRM, назначьте замер, измените дату, отправьте смету, передайте объект бригаде, закройте сделку. Проверьте, как этот путь отражён в отчёте. Затем повторите для отказа и для клиента, который обратился снова. Тестируйте с людьми, которые будут ежедневно вводить сведения, иначе часть процесса уйдёт обратно в чаты.
Права доступа проверяют отдельно: бригадир должен видеть свою работу, менеджер свои сделки, руководитель общий отчёт. Историю изменений тоже стоит сохранить: если сумму поправили после согласования, понятно кто, когда и почему. Резервное копирование, восстановление и выгрузка данных входят в критерии приёмки наравне с красивым интерфейсом.
Разработку удобнее делить на работоспособные части. Сначала маршрут заявки и карточка сделки, потом критичные действия и отчёт, затем дополнительные каналы. Иначе команда ждёт «полную платформу» и продолжает терять обращения в старом процессе. Для первого разговора о вашей системе подготовьте три реальные сделки и разбор задачи.
Частые вопросы
Разработка CRM всегда означает отказ от готовой системы?
Нет. Сначала нужно выяснить, можно ли настроить существующие этапы и подключить недостающий экран. Полная замена оправдана, когда обходные действия становятся постоянной частью основной работы.
Что передать разработчику перед оценкой?
Три пути сделки с исключениями, список каналов, роли сотрудников, текущие отчёты и примеры документов. По ним проще оценить объём, чем по пожеланию «сделайте удобную CRM».
Как понять, что отчёту можно доверять?
Для каждого показателя закрепите определение и исходные записи. Сверьте несколько сделок вручную, в том числе возврат, перенос и отказ.
Что делать со старой базой клиентов?
Определить, какие поля и история нужны дальше, очистить дубли и проверить пробный перенос на ограниченной выборке. Полный перенос проводят после подтверждения соответствия карточек.
Можно ли добавить ИИ после запуска?
Да, когда в системе уже есть актуальные данные и понятные права. ИИ может помогать с первыми ответами и подсказками, но ему нужен проверенный источник сведений и передача человеку.