Компания: Застройщик Краснодар
Формат проекта: Загородная недвижимость
Отрасль: Девелопмент жилой недвижимости
Задача
Реализовать механизм абсолютного контроля дублей контактов в amoCRM, который:
- полностью исключает возможность ручного создания дубля контакта;
- корректно работает при любых уровнях прав пользователей;
- позволяет сотруднику, не имеющему доступа ко всей базе CRM:
- понимать, что клиент уже существует;
- видеть, что с ним уже ведется работа;
- понимать, почему создание нового контакта запрещено;
- не нарушает политику безопасности и разграничения доступов.
Ключевое требование заказчика:
никаких компромиссов между безопасностью и контролем качества данных.
Контекст и предпосылки
На момент старта проекта у застройщика уже была частично решена задача борьбы с дублями:
- В CRM внедрено наше решение по проверке дублей сделок при автоматическом создании:
- заявки с сайта;
- входящие звонки;
- онлайн-источники.
- Автоматические сценарии работали стабильно и давали ожидаемый эффект.
Однако оставалась критическая зона риска — ручные действия пользователей.
Проблема
1. Системное ограничение стандартной CRM-логики
В amoCRM (и большинстве CRM в целом) проверка дублей жестко привязана к правам пользователя:
- если пользователь не видит контакт — для него контакт «не существует»;
- если контакт «не существует» — система разрешает создание нового.
Таким образом:
- ограничение прав автоматически ломает контроль дублей;
- чем жестче политика безопасности — тем выше риск хаоса в данных.
2. Реальная операционная картина
На практике это приводило к следующим последствиям:
- менеджеры создавали дубли не из злого умысла, а из-за отсутствия информации;
- один и тот же клиент:
- существовал в системе 2–4 раза;
- был привязан к разным сделкам;
- имел разных ответственных;
- аналитика и отчеты искажались;
- возникали конфликты внутри отдела продаж:
- «кто первый взял клиента»;
- «кто имеет право вести сделку»;
- увеличивалась нагрузка на руководителей и администраторов CRM.
3. Почему не подошли готовые решения
Заказчик рассматривал маркетплейс-решения, но все они имели один общий недостаток:
- работают строго в рамках пользовательских прав;
- если контакт скрыт — проверка не выполняется;
- фактически повторяют стандартную логику CRM, не решая проблему.
Комментарий:
Это типичная ситуация, когда коробочное решение выглядит функциональным в демо, но не работает в реальной корпоративной модели доступа.
Решение
Мы разработали кастомный продукт внутри CRM с нуля, ориентированный не на интерфейс, а на бизнес-логику и регламенты работы.
Архитектура решения
Ключевая идея:
Проверка дубля должна быть независима от прав пользователя, но при этом не нарушать безопасность.
Что было реализовано:
- отдельный сервис проверки контакта;
- проверка выполняется:
- по телефону;
- по email;
- по дополнительным идентификаторам;
- система анализирует:
- наличие контакта в CRM;
- наличие активных сделок;
- ответственного менеджера;
- текущий статус сделки.
Пользовательский сценарий
При попытке создания контакта сотрудник получает структурированный ответ системы:
- найден ли контакт;
- кто ответственный;
- в каком статусе находится сделка;
- активна ли работа с клиентом;
- разрешено или запрещено создание нового контакта.
При этом:
- пользователь не получает доступ к чужим контактам;
- не видит историю, комментарии, суммы;
- получает ровно столько информации, сколько нужно для принятия решения.
Логика разрешений
Система выдает один из двух вариантов:
- Создание контакта разрешено
(клиент новый, конфликтов нет) - Создание контакта запрещено
(контакт уже существует, активная работа ведется)
Дополнительно:
- отображается причина запрета;
- указывается ответственный;
- дается ссылка на сделку (если права позволяют).
Комментарий:
Мы не запрещаем «вслепую». Мы объясняем логику запрета, что критично для принятия системы менеджерами.
Результаты
1. Полное устранение ручных дублей
- Ручное создание дублей исключено на 100%.
- Независимо от:
- роли пользователя;
- уровня доступа;
- сценария создания сделки.
2. Единая логика контроля
- Автоматические источники и ручной ввод работают по одним правилам.
- CRM стала предсказуемой и управляемой.
- Исчез «серый» сценарий обхода контроля.
3. Повышение качества данных
- Контакты перестали дублироваться.
- Сделки корректно привязаны к клиентам.
- Аналитика перестала «плыть».
4. Снижение внутреннего напряжения
- Уменьшилось количество споров между менеджерами.
- Руководителю не нужно вручную разбирать конфликты.
- Сотрудники перестали бояться «ошибиться».
Комментарий:
CRM перестала быть карательным инструментом и стала ассистентом, который подсказывает правильное действие.
Заключение
Этот кейс наглядно показывает:
Ограничения стандартных CRM — это не потолок, а отправная точка.
Мы умеем:
- находить системные уязвимости в процессах;
- разрабатывать кастомные решения под реальные бизнес-ограничения;
- обеспечивать контроль без расширения прав;
- внедрять сложную логику так, чтобы она была понятна пользователям.
Если вы знаете, что именно вам нужно — мы реализуем.
Если не знаете — мы разберем процессы и предложим решение, которое действительно будет работать
Если вы не знаете, как решить проблему — мы предложим решение. Если знаете — реализуем его с гарантией результата.
WEB - студия https://intopweb.ru/ предлагает вам индивидуальных подход при разумных ценах. От момента регистрации домена и до выхода вашего бизнеса в лидеры региона мы будем сопровождать вас в интернет-пространстве. Мы работаем с интеграцией CRM и сквозной аналитикой https://integrat.pro/ и наши клиенты получают результат в кратчайшие сроки.