Телефон звонил. Никто не ответил. В 10:06 в CRM появился исходящий вызов, и задача исчезла. На совещании всё выглядит отлично: возврат через четыре минуты. У клиента — четыре гудка и тишина. Он оставил заявку у тех, кому дозвонился. Это условная сцена, но ошибка в ней вполне рабочая: сделать техническое действие синонимом результата для клиента.
Пропущенный входящий звонок стоит закрывать после состоявшегося разговора, явного переноса на другое время или другого заранее оговорённого исхода. Запись об исходящей попытке сама по себе задачу не закрывает. Чтобы проверить маршрут, сведите входящий журнал, исходящие попытки и результат разговора по одному идентификатору обращения. Затем ищите обращения, которые остались открыты без владельца или срока.
Восемь минут из жизни одной заявки
Пусть в 10:02 человек звонит на общий номер, попадает в очередь и кладёт трубку через 34 секунды. В 10:04 он пробует ещё раз. Первый звонок поступил на линию продаж, второй на свободного сотрудника сервиса. В 10:06 менеджер делает исходящий вызов, но не получает ответа. В 10:08 клиент сам дозванивается до другого менеджера и договаривается о расчёте.
Оставим в телефонии четыре вызова. В рабочей очереди до 10:08 будет одно открытое обращение, если удалось установить, что речь об одной задаче. В 10:06 отмечаем первую попытку, а в 10:08 закрываем возврат по подтверждённому разговору. Задачу на расчёт открываем отдельно: запрос прозвучал и принят, но расчёт ещё не готов. В отчёте выводим четыре события телефонии, одно обращение с пропуском, один подтверждённый контакт и одну бизнес-задачу. Четыре числа помогают увидеть, в каком месте реально были потери. Одно «обработано» скрывает их.
Если вы выбираете, какие исходящие разговоры можно поручить автоматике, у Фонекса показан маршрут от базы и сценария до результата разговора. Сначала определите исход, который должен увидеть сотрудник после возврата, а потом сравните с тем, как сейчас передаётся результат.
Почему статус АТС не отвечает на вопрос «обращение закрыто?»
Журнал АТС знает, что произошло с соединением. Журнал очереди знает, когда звонок вошёл в группу и как из неё вышел. CRM знает, что компания обещала человеку. Эти три показания иногда совпадают, но задавать всем трём один вопрос бесполезно. Например, разговор с голосовым меню может считаться состоявшимся соединением, а клиент с человеком так и не говорил. И наоборот: звонок не приняли в продажах, но коллега с другой линии решил вопрос. Для клиента второй сценарий успешный.
В журнале очереди Asterisk есть разные события для выхода абонента до ответа, соединения с участником очереди и перевода. Поля и названия своей АТС сверяйте с её документацией. У ресурса Call в Twilio есть отдельный идентификатор вызова и состояния попытки. В описании Dial можно увидеть, почему результат исходящего плеча нужно читать отдельно. Это примеры технических моделей, а не список обязательных поставщиков.
Посмотрите, какое событие сейчас запускает автоматизацию. Если это любой завершённый вызов, вы можете открывать задачу даже после разговора с оператором. Если только отсутствие ответа на одном номере — потерять вызовы, брошенные в очереди до вызова сотрудника. Если берёте только входящие без записи, получите ложные пропуски там, где запись отключена. Для первой настройки отберите контрольную серию вызовов с известным ходом событий и откройте сырые записи телефонии. Самый информативный случай — когда человек дошёл до голосового меню, выбрал отдел и положил трубку в ожидании. Он разделяет соединение с системой и ответ человеку.
Чья очередь: продаж или сервиса
Запись в журнале видит интегратор. Сроком владеет конкретная смена. Сначала заведите две очереди по назначению номера, если компания разделяет продажи и поддержку. Для общего номера полезен третий вариант «уточнить тему». Присвоение конкретному менеджеру по последнему контакту допустимо, если у сотрудника есть рабочая смена и право вести эту задачу. Без этих проверок очередь превращается в музей красивых уведомлений.
Когда вызов доходит после закрытия смены, сохраните время самого события и отдельно время открытия следующего окна обработки. Иначе вы не поймёте, почему клиенту не перезвонили в понедельник, либо обвините менеджера за воскресенье. Для срочных действующих обязательств выделите официальный путь эскалации и явно решите, кому доступна информация. Если дежурства нет, не обещайте работу круглосуточно.
Назначение и принятие также различаются. CRM может указать Иванову задачу, пока Иванов разговаривает, а коллега уже ищет этого клиента. Сделайте состояние «принято в работу» видимым и ограничьте параллельные исходящие вызовы. При передаче владелец меняется записью с временем и причиной; в истории остаётся предыдущий. Не стоит строить гонку за первым нажатием, если линия уже держит исходящую попытку.
Как объединять повторы
Номер полезен как подсказка, но он не удостоверяет личность и цель звонка. Три попытки с одного номера в течение нескольких минут при общей очереди часто стоит показать рядом. Общий номер закупок крупной компании может представлять разных людей и задачи. Аналогично, обращение утром по доставке и вечером по новому заказу не обязано попасть в одну сделку. Дайте сотруднику возможность разъединить события и зафиксировать причину.
У группировки должны быть понятные признаки: нормализованный номер там, где он предоставлен; назначение входящего номера; краткое окно времени; известная активная заявка; результат последующего разговора. Не превращайте сложение признаков в скрытую магию, когда система безотзывно склеивает карточки. Для скрытого номера не выдумывайте контакт, а отмечайте, что возврат по телефону невозможен. Если спустя час приходит форма с телефоном, связь появится только по проверяемому контексту.
Связи должны идти в обе стороны. Из карточки видно, какие попытки в неё попали. По записи АТС можно выяснить, куда её отнесли. Это особенно важно, если новый сотрудник разбирает утренние пропуски и видит два похожих дела. Без связей он перезвонит ради статистики человеку, который уже договорился с коллегой.
Шаблон строки для очереди возврата
| Поле | Условный пример | Для чего |
|---|---|---|
| Идентификатор обращения | R-204 | Дело переживает повторные вызовы |
| Первый входящий | 10:02, продажи | Начало ожидания и исходный маршрут |
| Попытки | I-817, I-821, O-44 | Ссылки на технические события |
| Ответственный | Дежурный продаж | Есть тот, кто проверяет исход |
| Срок следующего действия | Сегодня, 10:15 | Видно, когда заметить задержку |
| Подтверждённый итог | Разговор в 10:08, нужен расчёт | Расчёт живёт своей задачей |
| Причина исключения | Скрытый номер, если применимо | Исключение не выдаётся за возврат |
Шаблон можно начать вести вручную. Возьмите журнал за часть смены и проставьте идентификаторы 15–20 событий. Проверьте, можно ли восстановить порядок по временам и кто способен подтвердить исход. Если в половине дел надо открывать три системы, автоматизируйте сохранение идентификаторов прежде, чем добавлять речевого агента: более умный разговор не починит отсутствующую связь между журналами.
Что считать на еженедельной встрече
Начните с двух знаменателей. Первый — все входящие попытки, дошедшие до выбранного маршрута. Второй — уникальные обращения с пропуском, пригодные к возврату по этому каналу. Не сравнивайте долю возвратов из второго с долей ответов от первого. Покажите исключения: скрытые номера, технические тесты, ошибки маршрутизации, обращения, закрытые входящим звонком. У каждого исключения должно быть собственное основание; «ничего не знаем» — отдельная категория.
В условной выборке 120 входящих попыток, из них 28 пропущены. Эти 28 собраны в 20 обращений. Два не имеют пригодного номера, поэтому у очереди 18 дел. В 12 удалось поговорить, четыре остались с исходящими попытками, два ещё ждут работы. Доля подтверждённых возвратов — 12/18, примерно 67%. Если исключения потерять, менеджмент перестанет видеть проблему определения номера. Если четыре попытки зачислить как успех, цифра станет 89% без единого дополнительного разговора.
Показывайте два времени: от исходного пропуска до первой попытки и до подтверждённого контакта. Быстрая попытка полезна, но не отменяет длинный хвост. Для небольших групп вместе с процентом дайте числитель и знаменатель. Один поздний контакт в группе из двух оказывает большее влияние, чем десяток в группе из сотни. Динамику сравнивайте по сопоставимым сменам, иначе праздник или сбой АТС будет притворяться изменением дисциплины.
Приёмка до включения автоматических возвратов
Попросите двух коллег прогнать несколько вызовов через тестовый номер. Один звонит, другой наблюдает CRM и журнал. В конце смены они сравнивают хронологию. Проверять надо не только счастливо прошедший вызов, но и выход до ответа, повтор, перевод, возврат, одновременную работу двух сотрудников, закрытое рабочее окно и отсутствие номера.
В ручной проверке важен шаг после ожидаемого результата. Если исходящий вызов попал в автоответчик, не появляется ли «клиент проинформирован»? Если человек сам дозвонился, снимается ли ещё не выполненная повторная попытка? Если сотрудник сказал, что уже договорился, сохраняется ли его решение после запоздалой доставки события из АТС? Такие несоответствия редки на демонстрации и типичны в рабочий понедельник.
Когда логика готова, не обязательно сразу переключать всю линию. Можно несколько смен параллельно считать результаты и сравнивать их со старым процессом без автоматических звонков. Разберите все расхождения: ошибочно созданная задача раздражает сотрудника; ошибочно закрытая незаметна и обходится дороже. После проверки понятных сценариев запустите одну очередь и оставьте возможность быстро вернуть старый маршрут.
Контрольные сценарии для тестового номера
Входящий заканчивается в голосовом меню
Звонящий выбрал отдел, но ушёл до попадания в группу. В общем журнале стоит «соединение», карточки нет.
- Что проверить
- Ищите событие выбора ветки, время выхода и отсутствие соединения с участником нужной группы. Проверяйте наличие номера отдельно: тот же маршрут возможен без обратного контакта.
- Решение
- Откройте задачу для выбранного отдела, если есть доступный контакт и правила позволяют возврат. При неизвестной ветке назначьте первичное уточнение, сохранив исходный номер линии.
- Ожидаемый результат
- Повторите вызов на тестовой линии дважды: дождитесь специалиста, затем завершите во время меню. В выгрузке число соединений может совпасть, число задач — нет.
Один человек звонит трижды
В 11:00, 11:02 и 11:05 звонки идут с одного номера. В 11:07 менеджер видит три заявки, а разные коллеги начинают набирать номер.
- Что проверить
- Сопоставьте назначение линии и активное обращение; определите, где уже есть принятая задача. Записи трёх событий сохраняются независимо от объединения.
- Решение
- Покажите три попытки внутри дела и ограничьте параллельный вызов. Дайте менеджеру разделить обращения, если выяснятся разные запросы.
- Ожидаемый результат
- Начните возврат у одного сотрудника и откройте очередь у другого. Второй увидит владельца и текущую попытку; ожидание продолжит считаться с 11:00.
Человек дозванивается сам
В 12:03 вызов пропущен, в 12:07 менеджер ещё не начал возврат, в 12:08 клиент дозванивается в соседнюю очередь.
- Что проверить
- Проверьте связь нового разговора с прежней задачей. Совпадение номера даёт кандидата, тема подтверждает или опровергает его.
- Решение
- При совпадении завершите возврат как «контакт входящим», сохранив владельца нового дела. Для второго вопроса не закрывайте первоначальную задачу.
- Ожидаемый результат
- Уведомление о просрочке исчезает только для подтверждённой связи. В отчёте сохраняется пропуск в 12:03 и отдельно контакт.
Занято, а затем автоответчик
Две исходящие попытки записаны как завершённые. Первая упирается в занятость, во второй слышно стандартное приветствие.
- Что проверить
- Посмотрите итоговые статусы плеча, правила распознавания и ручную отметку там, где уверенности нет. Время от начала набора к результату не равно длительности разговора.
- Решение
- Сохраните оба исхода как попытки. План следующего действия определяется согласованным интервалом, а не требованием «добить норму».
- Ожидаемый результат
- Следующий звонок не запускается немедленно и обе попытки не попадают в числитель подтверждённых контактов.
Один номер на два отдела покупателя
Звонящий утром спрашивает про готовность поставки, другой человек с того же номера днём хочет заказать новую партию.
- Что проверить
- Сравните цели, действующие карточки и подтверждения из разговоров. Если общий номер используется регулярно, добавьте явный признак.
- Решение
- Оставьте два обращения и свяжите оба с известной организацией. Поддержка и продажи получат свои следующие шаги.
- Ожидаемый результат
- В карточке организации два входящих и два дела. Контакты работников не подменяются одним человеком.
Перевод обрывается
Первая линия ответила, перевела звонок на менеджера и ушла с линии. На втором плече ответа не было.
- Что проверить
- Сопоставьте журнал разговора и дочерний вызов. Ответ первой линии не подтверждает, что нужная команда приняла вопрос.
- Решение
- Создайте задачу на завершение передачи с контекстом. Не отправляйте человека заново в общий сценарий, если отдел известен.
- Ожидаемый результат
- В журнале разные исходы «первый ответ» и «передача завершена». Если первая линия решила вопрос, задачи на перевод нет.
Номер не определился
Линия получила входящий без номера. В интерфейсе пустая строка, сотрудник не может набрать абонента обратно.
- Что проверить
- Проверьте, исчез ли номер на стороне АТС, при преобразовании или до поступления. Отделяйте ожидаемое отсутствие от поломки маршрута.
- Решение
- Не создавайте выполнимую задачу возврата. Сохраните исключение; при массовом появлении передайте диагностику владельцу телефонии.
- Ожидаемый результат
- Запустите тесты с доступным номером и без него. Пустой номер не приводит к попытке, а обычный случай не исчезает из очереди.
Событие приходит после закрытия
Менеджер поговорил в 14:09, закрыл возврат и поставил расчёт. Событие исходящей попытки в 14:04 доставилось только в 14:11.
- Что проверить
- Сравните время звонка и время поступления записи. Очередь могла задержаться; важно восстановить порядок, не откатывая подтверждённое решение.
- Решение
- Дополните хронологию исходной попыткой. Уже принятый итог остаётся; новое дело нужно только для независимого обращения.
- Ожидаемый результат
- Воспроизведите события в обратном порядке и повторите доставку одного. В карточке одно дело, нужное число событий и нет новой задачи на старый звонок.
Что делать, если старые журналы нельзя сопоставить
Если в CRM нет идентификатора вызова, не подбирайте пары автоматически по ближайшему времени. Начните с ограниченной ручной проверки: найдите несколько подтверждённых разговоров с подходящим контекстом, посмотрите, как они отражены в карточке, и выпишите недостающие поля. Старый период так и оставьте с неизвестным покрытием. С даты, когда ключ начал сохраняться, ведите новый сопоставимый ряд. История, которую нельзя восстановить, дешевле фиктивной: она хотя бы не направляет менеджеров звонить тем, кто ничего не просил.
В первые дни после исправления следите и за обратной ошибкой: одна интеграция может положить в карточку идентификатор входящего вызова, другая — заменить его последним исходящим. Храните связанные попытки списком, не в одном поле «последний звонок». Когда кто-то пожалуется на пропуск через неделю, вы сможете восстановить исходное событие, путь возврата и то, где оборвалась связь.
Где заканчивается работа очереди
Если заметная часть пропусков случается после перевода, смотрите контроль перевода звонков. Если не ясна экономика потерь, отдельно посчитайте цену пропущенного звонка. Если контакты подтверждаются, но обещания исчезают, нужен контроль обязательств менеджера. Это три разных решения, хотя издалека все выглядят как «плохо обрабатываем телефон».
Самая дешёвая доработка часто находится после гудка. Не менять голос, не рисовать новый дашборд. Просто договориться, кто и по какому факту закрывает дело. Когда этот факт виден в истории, владельцу становится понятно, за что он платит: за состоявшийся контакт и обработанный запрос.