Список обзвона в агентской CRM: что передать ИИ-продавцу

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

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

Строка с телефоном ещё не является заданием продавцу

Представим утро отдела продаж. В CRM есть организации, несколько выгрузок и список «позвонить». В одной строке — действующий покупатель, в другой — компания из исследования, в третьей — человек, который уже обсуждает вопрос с менеджером. Если всем передать одинаковое поручение, голосовой агент начнёт каждый разговор без понимания, зачем именно он нужен.

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

В Цифре опубликована модель агентской CRM: поиск, карточка, коммуникации и история связаны с правилами участия человека. Для списка обзвона это означает явный переход от найденной компании к принятому поручению. Состав полей и телефонное подключение настраиваются под процесс; существование карточки само по себе не включает исходящие действия.

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

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

Единица списка — конкретная задача

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

Сравните две строки. «Компания Север, позвонить» требует догадаться обо всём. «Уточнить, нужен ли разбор обработки обращений для нового филиала; исходный источник приложен; действующий проект не обсуждать» задаёт предмет и границу. Вторая запись не гарантирует интереса, но позволяет вести предметный разговор и правильно принять отсутствие интереса.

В списке могут соседствовать разные типы задач: ответить на запрос, согласовать продолжение, уточнить исходные данные или проверить актуальность предмета. Их нельзя объединять одним итогом «контакт обработан». Для каждой нужен свой критерий результата. Если предмет не определён, полезнее вернуть строку на подготовку, чем попросить агента заполнить пробел убедительным вступлением.

Минимальный паспорт строки

Опишите поля так, чтобы их понимали продавец, руководитель и разработчик. Некоторые значения приходят из CRM, другие — из исследования или решения сотрудника. Происхождение должно оставаться видимым. Нельзя выдавать предположение исследователя за просьбу клиента только потому, что оба значения помещаются в одно поле «потребность».

Вместо длинного свободного текста полезно иметь несколько обязательных смысловых полей и ссылку на подробности. Но не заставляйте сотрудника вручную переписывать уже известное. Агент может подготовить черновик на разрешённых данных, а человек — подтвердить спорные части. Автоматическое заполнение помогает тогда, когда происхождение и неизвестные значения не исчезают.

Откуда строка попадает в очередь

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

Если источник — исследование, приложите факт, дату и вопрос для проверки. Если заявка, сохраните её исходный предмет и ожидаемый канал. Если поручение менеджера, укажите, какое продолжение согласовано. Так список становится продолжением реальной истории, а не соревнованием агентов в придумывании поводов. Когда основание пропало или устарело, строка должна покинуть готовую очередь.

Внешний пример подобной организации работы есть в списках действий Microsoft Dynamics 365. Это пример подхода к рабочей очереди, а не утверждение о такой же функции по умолчанию в Цифре. Для своего процесса нужно определить состав объектов и переходов, а затем показать их на конкретном поручении.

Готовность важнее красивого балла

Прежде чем ранжировать строки, проверьте их выполнимость. Есть ли достаточный контакт и понятный предмет? Действуют ли сведения? Доступен ли нужный сценарий? Есть ли сотрудник, который примет продолжение? Очередь из неподготовленных задач не станет полезнее после присвоения каждой оценке 87 из 100. Балл не создаёт отсутствующий номер и не подтверждает право звонить.

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

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

Версия задания и изменения до запуска

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

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

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

Что именно получает голосовой участник

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

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

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

Как закрывается одна строка

Сформулируйте критерий завершения по типу поручения. Для проверки актуальности важен ответ на предмет, для уточнения — подтверждённый параметр, для передачи — принятое продолжение. Недозвон не должен автоматически означать отказ, а завершившееся соединение — достижение деловой цели. У телефонной попытки и задания разные жизненные циклы.

В Twilio Call resource технические состояния вызова выделены отдельно. Используйте этот пример как напоминание о двух уровнях учёта. Ваша телефония может иметь другие поля, но всё равно нужно определить, как техническое событие превращается в известный или пока неизвестный деловой результат.

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

Пример одной очереди на рабочий день

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

У первой проверяют исходный предмет, обещанный канал и доступные ответы. Вторая требует решения о допустимом обращении и подтверждения актуальности сигнала. Третья сверяется с владельцем существующей работы: новый контакт может оказаться лишним. Четвёртую возвращают на подготовку. Это не потеря объёма — это предотвращение разговора, который система пока не способна обосновать.

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

Как принимать список у ИИ-команды

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

Проверьте сохранение неизвестности. Если роль собеседника не установлена, поле должно показывать это честно. Заполнение всех ячеек гладкими догадками ухудшает качество. Для агента полезным результатом иногда является вопрос сотруднику или возврат на уточнение. Критерий приёмки должен признавать такой исход, иначе система будет учиться скрывать пробелы ради зелёного отчёта.

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

Как измерять пользу очереди

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

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

Не смешивайте эту задачу с приоритетом обращений в CRM и чисткой базы перед обзвоном. Приоритет определяет порядок, чистка исправляет данные, а паспорт поручения задаёт исполнимое действие. Все три слоя могут понадобиться, но принимаются по разным критериям и не заменяют друг друга.

Что должно остаться после внедрения

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

Как сотрудник останавливает уже выпущенное поручение

После формирования списка обстоятельства продолжают меняться. Менеджер мог договориться с клиентом вручную, услуга — стать недоступной, а покупатель — попросить другой канал. Нужен понятный способ отменить ещё не начатое действие и увидеть, что очередь приняла отмену. Изменённая заметка в карточке не гарантирует остановку задания в отдельном телефонном сервисе.

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

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

Начать удобно с небольшой согласованной выборки и полного прохождения нескольких задач. Затем расширяют объём, сохраняя определения и наблюдение за исключениями. Хороший список обзвона не заставляет ИИ-продавца каждый раз заново изобретать задачу. Он передаёт понятное поручение, сохраняет происхождение контекста и возвращает компании проверяемую следующую работу.