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