«Неразобранное» в amoCRM нужно превратить в очередь с владельцем, сроком разбора и понятным решением по каждому обращению. Дежурный проверяет содержание и контекст, принимает целевой запрос в работу либо отклоняет подтверждённый мусор. После принятия нужно отдельно проверить ответственного, следующий шаг и фактическую связь с клиентом: исчезновение карточки из очереди ещё не означает, что клиент получил ответ.

Ниже — регламент входящего обращения и проверки для его запуска. Это редакционная методика; сроки и роли следует адаптировать к своему графику. Поведение источников и подключений проверяйте на контрольных заявках именно в вашем аккаунте.

Как устроено «Неразобранное» и где его включить

Раздел собирает входящие заявки из подключённых источников для первичного разбора. Администратор включает его через «Сделки» → «Настройки воронки», а доступ сотрудникам настраивает в разделе пользователей. Прежде чем поручать разбор, проверьте видимость очереди под обычной учётной записью сотрудника. Официальная инструкция по подключению «Неразобранного».

Не каждый канал обязан направлять обращения сюда. Например, в настройках встроенной формы выбирается этап, в том числе «Неразобранное». Если заявка сразу появилась на рабочем этапе, сначала проверьте маршрут источника, а не ищите её только в очереди. Форма сайта и «Неразобранное».

Отсутствие колонки само по себе не доказывает поломку: официальная справка связывает её отображение с наличием заявок. Для проверки отправьте учебное обращение из конкретного источника и проследите, где оно появилось. Логика отображения раздела.

Отключать раздел ради пустой очереди не стоит. По инструкции amoCRM после отключения новые заявки попадают на первый этап, а ответственным назначается первый администратор аккаунта. До такого изменения проверьте конечного получателя и дальнейшие действия на каждом используемом канале: очистка экрана не заменяет обработку.

Почему заявки остаются без разбора

Сначала возьмите несколько самых старых обращений и разберите их путь: источник, время появления, кто должен был увидеть, что сделал и что помешало продолжить. Не начинайте с массового принятия всего накопленного.

  • Очередь общая, владельца нет. Каждый считает, что её проверит коллега. Назначьте дежурного и замену на время отсутствия.
  • У сотрудника нет доступа. Администратор видит заявку, а исполнитель — нет. Проверьте права и нужную воронку из рабочей роли.
  • Не определён результат разбора. Менеджер ждёт полной квалификации или оплаты, прежде чем принять обращение. Опишите минимальные признаки передачи в работу и следующий шаг для неполного запроса.
  • Поток превышает доступное время. Сопоставьте поступление по часам с фактическим графиком дежурства. Напоминание не добавит сотрудников в перегруженную смену.
  • Неясен контекст повторного клиента. Для сообщения по текущему заказу и нового запроса нужны разные маршруты. Не отклоняйте их только из-за знакомого телефона.
  • Автоматизация не выполнила ожидаемое действие. Если принятие было автоматическим, найдите конкретную попытку и результат. Не считайте любую оставшуюся заявку ошибкой робота, пока не проверены его условия.

Если обращения вообще нет в CRM, это другая задача — проверка доставки. Используйте разбор пути заявки с сайта. Если обращение уже в очереди, сначала устраняйте задержку принятия и передачи.

Кто принимает входящие

Для небольшого потока можно назначить дежурного менеджера на смену. При более сложной квалификации — отдельного сотрудника первичного разбора. В любом варианте должны быть известны заместитель, время передачи очереди и руководитель, который разбирает просрочки и спорные случаи.

Отделите владельца очереди от ответственного за дальнейшую продажу. Дежурный может принять и передать заявку, но передача завершена только после проверки, что получатель видит обращение и знает следующий шаг. Подробные правила выбора менеджера рассмотрены в матрице распределения заявок.

Если несколько сотрудников работают одновременно, договоритесь о способе фиксации начала разбора, который доступен в вашей конфигурации, и проверьте одновременную обработку на тесте. Общая видимость не должна приводить к двум ответам клиенту. В конце смены передавайте список оставшихся обращений с причиной ожидания и следующим действием.

Как отличить спам от нового клиента

Основанием служит содержание и контекст обращения. Короткое сообщение «Здравствуйте», неизвестный номер или отсутствие бюджета не доказывают спам. Если запрос может быть целевым, уточните потребность или передайте его в контролируемую квалификацию. Отдельно определите, куда направлять обращения по поддержке, от поставщиков и соискателей: это не обязательно мусор, хотя они могут не относиться к продажам.

  • Понятный интерес к продукту: принять, назначить следующего исполнителя и действие.
  • Недостаточно сведений: уточнить по доступному каналу; ожидание имеет владельца и срок проверки.
  • Вопрос по действующему заказу: проверить связь с клиентом и передать владельцу заказа, сохранив содержание обращения.
  • Явная массовая реклама, не связанная с задачей компании: отклонить по принятому правилу, зафиксировав основание там, где оно останется доступным.
  • Подозрение на технический дубль: сверить исходное событие и уже существующую обработку; новый запрос того же человека не считать дублем автоматически.

Перед отклонением выясните последствия для источника. Для формы amoCRM описывает перемещение сформированных сущностей в удалённые. Для звонков справка указывает, что при отклонении информация о звонке не сохраняется. Поэтому отклонение нельзя использовать как универсальный способ «отложить на потом». Телефония в «Неразобранном».

Не обещайте одинаковое связывание с существующей сделкой для всех каналов: документация API ограничивает описанный метод привязки неразобранным типа «Чат». Для остальных источников проверьте поддерживаемый способ сохранения контекста, не создавая лишние карточки вручную. Официальная документация API.

Регламент входящего обращения

Заготовка для согласования с командой. Замените роли реальными ответственными, установите срок первичного разбора и срок первого действия по каждому каналу. Место фиксации решения нужно выбрать и проверить заранее: не все поля этого регламента являются штатными полями «Неразобранного».

ШагКто отвечаетЧто делаетЧто подтверждает результат
Начало сменыДежурныйПроверяет доступ, остаток и самые старые обращенияНет оставшихся без владельца исключений
Первичный разборДежурныйЧитает запрос, проверяет источник и возможную связь с текущим клиентомЗафиксированы решение либо причина уточнения и срок
ПринятиеДежурный или согласованная автоматизацияПринимает подходящее обращение и проверяет полученную карточкуСохранены содержание, источник и нужные связи
ПередачаДежурный и менеджерПроверяют исполнителя, доступ и следующее действиеПолучатель может продолжить работу; задан срок действия
ОтклонениеУполномоченный сотрудникПроверяет основание и последствия для данного источникаРешение объяснимо по доступной записи; спорный случай передан руководителю
Превышение срокаРуководитель сменыВыясняет причину, назначает замену или устраняет препятствиеЕсть конкретный исполнитель и ближайшее действие
Конец сменыУходящий и следующий дежурныеПередают остаток с причинами и срокамиСледующий дежурный подтвердил получение очереди

Учебный пример сроков. Команда работает с 09:00 до 18:00 и согласовала первичный разбор за 15 рабочих минут. Обращение в 17:55 должно быть разобрано до 09:10 следующего рабочего дня, если в календаре нет иной смены. Это пример расчёта, а не норма amoCRM или обещание CHECK CRM. При необходимости вечернего ответа нужен другой график и ресурс, а не только другое уведомление.

Как контролировать время обработки

Разделите четыре отметки: поступление в источник, появление в CRM, решение по очереди и первое содержательное действие сотрудника. Разница между первыми двумя показывает доставку, между появлением и решением — разбор, между поступлением и действием — ожидание клиента. Автоматическое приветствие и кнопка принятия не подтверждают содержательный ответ.

Для текущей очереди считайте возраст открытых обращений и количество превысивших согласованный срок. Для обработанных — время до решения и причины отклонения. Показывайте каналы и рабочее/нерабочее время отдельно. Среднее по уже принятым заявкам может выглядеть хорошим, пока самые старые ещё остаются без обработки.

В API amoCRM у неразобранного есть UID, источник, категория, воронка и время создания created_at; список можно сортировать по времени. Это позволяет строить отдельный контроль очереди с учётом прав доступа. Само наличие API не означает, что в аккаунте уже настроен нужный отчёт, уведомление или рабочий календарь. Способ фиксации решения и первого ответа нужно проверять отдельно.

Если история не сохранялась, не восстанавливайте точное время принятия по догадкам. Начните с наблюдения текущей очереди и фиксации событий на пилоте. При периодическом опросе учитывайте интервал: исчезновение между двумя проверками даёт диапазон времени, а не точную отметку решения, и само по себе не объясняет причину исчезновения.

Как проверить регламент перед запуском

  1. Отправьте учебную заявку из каждого включённого источника. Сверьте содержание, время и место появления.
  2. Войдите под дежурным: очередь видна, а решение можно выполнить с его правами.
  3. Примите целевое обращение: проверьте карточку, исполнителя, следующий шаг и доступ получателя.
  4. Проверьте неполный запрос и сообщение существующего клиента: они не теряются и не отклоняются только из-за нехватки данных.
  5. На явно учебных данных испытайте отклонение отдельно для формы и звонка; зафиксируйте, какие сведения остаются доступными.
  6. Смоделируйте отсутствие дежурного, превышение срока и передачу смены. Подтвердите, кто получает сигнал и кто действительно продолжает работу.
  7. Сверьте итог: у каждого тестового обращения есть объяснимый маршрут, а принятие и первый ответ не смешаны в одном показателе.

Если очередь регулярно накапливается, передайте несколько конкретных примеров и этот регламент на разбор в рамках сопровождения amoCRM. Цель — сохранить обращения и обеспечить своевременное следующее действие, а не добиться пустой колонки любой ценой.

Источник и метод. Продуктовые сведения проверены 3 ноября 2026 по официальной документации; ссылки и оговорки приведены в тексте. Рекомендации основаны на практике обследования, внедрения и сопровождения CRM.