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