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