CRM • аналитика • автоматизация продаж • собственные виджеты
Услуги →Виджеты →Кейсы →Блог →О компании →Контакты →Поддержка →Оставить заявку →

amoCRM

Распределение лидов в amoCRM: очередь, лимиты и исключения

Программа приёмки очереди amoCRM: одновременные заявки, смена доступности, повтор доставки, лимиты переназначений и доказательства фактического принятия.

Редакция Balance••3 мин на чтение

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

Зафиксируйте правило и условия испытания

Запишите порядок выбора получателя: действующий владелец клиента, подходящая специализация, доступность, затем выбранный алгоритм очереди. Укажите лимиты и правило переполнения. Эти решения нужны как эталон проверки; изменять их во время теста ради совпадения с результатом нельзя.

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

Испытайте одновременные заявки и повтор доставки

Условный отдел распределяет запросы между Анной и Борисом. Анне доступен один дополнительный запрос, Борису — два. Отправьте два независимых события почти одновременно и проверьте, что ограничение Анны не превышено из-за параллельной обработки. Правильный результат определяется согласованным алгоритмом, но каждая заявка должна получить единственное подтверждённое назначение.

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

Проверьте изменение доступности во время назначения

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

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

Различайте назначение и принятие

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

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

Соберите протокол допуска к работе

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

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

Применить в вашей компании

Обсудим вашу задачу?

Поможем разобраться с процессом, данными и настройками. Работаем удалённо с компаниями по всей России.