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