Система обработки заявок не сводится к подключению формы к CRM. Обращение может дойти, но остаться без ответственного; повтор — создать дубль; сообщение из мессенджера — продолжить жить только в личном чате сотрудника.
Сначала составьте карту каналов и этапов обработки заявки. Затем настройте один тип входящего обращения от приема до первого содержательного ответа и проверьте обычные и аварийные сценарии.
Что входит в обработку входящих заявок?
- Составить реестр сайтов, телефонов, почты, площадок и мессенджеров.
- Определить единый объект обращения и обязательные данные.
- Передавать идентификаторы источника и входного события.
- Настроить защиту от повторной обработки.
- Назначать ответственного или резервную очередь.
- Контролировать срок первого действия и все ошибки доставки.
Как построить систему обработки заявок из разных каналов?
Карта должна содержать не только официальные формы, но и обходные маршруты, которыми реально пользуются клиенты и сотрудники. Для каждого канала укажите технический источник, владельца и подтверждение успешной доставки.
| Канал | Что сохранить | Что проверить |
|---|---|---|
| Форма сайта | ID формы, страница, метки кампании, ClientID | Валидация и повторная отправка |
| Телефон | ID звонка, номер линии, время, результат | Пропущенный и повторный звонок |
| Мессенджер | ID диалога и сообщения, разрешённые контакты | Ответ вне рабочего времени |
| Почта | ID письма, ящик, тема и вложения | Ответы в существующую цепочку |
| Площадка | ID объявления, заказа или чата | Лимиты API и задержка |
Личные аккаунты сотрудников нельзя считать устойчивым каналом: компания не контролирует доступность, историю и передачу клиента другому ответственному.
Какие поля нужны для обработки заявки в CRM?
Единая модель не означает одинаковую форму для всех каналов. Она задаёт минимальный набор, по которому обращение можно найти, назначить и связать с дальнейшей сделкой.
- внутренний ID заявки и внешний ID события;
- канал, конкретный источник и дата получения;
- контактные данные в нормализованном виде;
- тема, продукт или тип запроса;
- согласованный источник и рекламные метки;
- ответственный, статус и дата следующего действия;
- связанные клиент, сделка и история сообщений;
- технический статус доставки и последняя ошибка.
Не переносите в карточку весь технический пакет и лишние персональные данные. Полный журнал хранится в защищённом контуре, а менеджер видит только то, что нужно для работы.
Как защититься от дублей и повторной доставки?
Каждому входному событию присваивают устойчивый ключ. Повтор с тем же ключом обновляет результат или подтверждает уже выполненную операцию, но не создаёт новую заявку.
| Совпадение | Решение |
|---|---|
| Тот же внешний ID события | Не создавать повторно, вернуть прежний результат |
| Тот же телефон и близкое время | Связать как кандидат, проверить контекст |
| Тот же клиент, другой вопрос | Создать новое обращение в существующей карточке |
| Конфликт контактов | Передать в очередь ручной проверки |
| Не хватает данных | Сохранить событие и запросить дополнение |
Правила очистки действующей базы описаны отдельно в материале про перенос данных в CRM.
Как распределять заявки между менеджерами?
Правило назначения должно быть прозрачным и иметь запасной маршрут. Сегмент, регион, продукт, рабочее время и текущая загрузка могут участвовать в распределении, но заявка не должна зависеть от одного недоступного сотрудника.
- фиксируйте, какое правило сработало;
- проверяйте права назначенного сотрудника;
- держите очередь без владельца на отдельном экране;
- переназначайте по регламенту отсутствия;
- не меняйте владельца молча после начала работы.
Как контролировать первый ответ клиенту?
Отсчёт начинается от фактического получения обращения, а заканчивается содержательным действием, а не автоматическим уведомлением. Обещанный срок учитывает канал, часы работы и приоритет.
- сохранить время получения и назначения;
- создать задачу с владельцем и сроком;
- напомнить до нарушения, а не после;
- эскалировать руководителю только необработанные случаи;
- отдельно учитывать автоответ и человеческий контакт;
- разбирать причины просрочки по конкретным карточкам.
Последующие этапы должны совпадать с воронкой продаж в CRM, иначе обращение будет принято, но потеряется позже.
Что происходит с заявкой при сбое интеграции?
Сбой не должен превращаться в пустой ответ API или письмо одному администратору. Событие сохраняют до обработки, классифицируют ошибку и назначают владельца очереди.
| Ситуация | Автоматическое действие | Ручной контроль |
|---|---|---|
| CRM временно недоступна | Ограниченный повтор с тем же ID | Очередь после исчерпания попыток |
| Неверный формат | Не повторять без изменения данных | Исправить источник или запись |
| Нет подходящего владельца | Поместить в резервную очередь | Назначить и исправить правило |
| Частичный успех | Зафиксировать выполненные шаги | Компенсировать или завершить |
| Подозрение на дубль | Не объединять автоматически | Сопоставить карточки |
Общие требования к журналу и откату собраны в статье про автоматизацию продаж в CRM.
Какие показатели покажут потери заявок?
- число событий в источнике и заявок в CRM;
- доля необработанных и неназначенных обращений;
- доля повторов и спорных дублей;
- время до первого содержательного действия;
- ошибки по каналу, типу и причине;
- заявки без следующего шага;
- доля обращений, связанная со сделкой и результатом.
Сверяйте количество с первичным источником, а не только с CRM. Если входящие события уже не попали в систему, внутренний отчёт не покажет потерю.
Как проверить единый контур на пилоте?
- 01
Один канал
Выбрать частый источник с понятным владельцем.
- 02
Набор сценариев
Обычная заявка, дубль, неполные данные, сбой и внерабочее время.
- 03
Сверка
Сопоставить все события источника с карточками CRM.
- 04
Рабочая неделя
Проверить назначение, сроки и ручную очередь.
- 05
Расширение
Подключать следующий канал после разбора ошибок.
Частые вопросы
Почему заявки теряются после подключения CRM?
CRM не гарантирует доставку сама по себе. Потери возникают между каналом и CRM, при ошибке обязательных данных, повторной доставке, отсутствии ответственного или работе менеджера вне системы.
Нужно ли создавать отдельную воронку для каждого канала?
Нет. Канал обычно хранится в отдельном поле. Новая воронка нужна, только когда меняются этапы и правила самого процесса.
Как не создавать дубли из звонка и формы?
Сохраняйте идентификатор события и источника, нормализуйте контакты и автоматически объединяйте только однозначные совпадения. Спорные пары передавайте на ручную проверку.
Что делать, если интеграция временно недоступна?
Событие должно остаться в очереди с причиной и числом попыток. После восстановления его обрабатывают повторно по тому же идентификатору, не создавая вторую заявку.
Какой срок первого ответа установить?
Опирайтесь на обещание клиенту, режим работы и собственную исходную линию. Универсальное число без учёта канала и типа обращения вводит в заблуждение.
Источники и границы материала
- Microsoft Learn: автоматическое назначение лидов и возможностей
- HubSpot Knowledge Base: подключение каналов к общему inbox
- Яндекс Метрика: импорт офлайн-данных из CRM и звонков
- Microsoft Learn: единая маршрутизация и очереди обращений
Материал носит информационный характер. Конкретная архитектура, бюджет, режим работы с данными и уровень человеческого контроля зависят от процесса и требований компании.
Проверьте путь заявки от канала до ответственного
Покажите источники обращений и текущую CRM. Мы поможем собрать карту событий, правила дублей и контроль необработанных заявок.