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

1. Подготовьте одну контрольную заявку
Договоритесь с менеджером о тесте в рабочее время. Используйте свой доступный телефон в роли клиента и заранее предупредите сотрудника, который должен принять вызов. Отправьте форму один раз: несколько нажатий подряд затруднят сопоставление заявок и попыток.
Зафиксируйте:
- страницу и конкретную форму: виджет, форма записи или кнопка в мобильном меню;
- дату, время и часовой пояс;
- введённый телефон, выбранный офис и время звонка, если форма их запрашивает;
- сообщение после отправки и результат на телефонах обеих сторон.
Не меняйте одновременно номер менеджера, расписание и способ подтверждения. Сначала сохраните исходные условия, затем проверяйте по одной гипотезе.
2. Убедитесь, что сервис получил заявку
Надпись «Спасибо, мы вам перезвоним» показывает результат работы интерфейса сайта. Для проверки обратного звонка нужно установить, передала ли форма обращение в сервис и был ли запрос принят.
Найдите обращение в доступном журнале или списке заявок по номеру и времени. Проверьте выбранный сайт, виджет, офис и период. Если ничего не найдено, сначала исключите неподходящий фильтр и ограничение доступа: отсутствие строки в текущей выборке ещё не доказывает потерю заявки.
Для собственной формы сайта попросите разработчика проверить две части: приём формы вашим сервером и передачу в сервис обратного звонка. Запись в CRM или письмо с заявкой подтверждают только соответствующее действие. Автоматический запуск звонка требует отдельной интеграции; общий принцип описан в статье «Обработка форм на сайте в звонок».
В браузере разработчик может увидеть запрос формы, отправленные поля и ответ сервера во вкладке Network. Если дальнейший вызов выполняет сервер сайта, его нужно искать в серверных журналах: браузер эту часть цепочки не показывает. Важно проверить результат обработки, а не ограничиваться HTTP-кодом ответа. Вкладки для просмотра запроса и ответа описаны в документации Chrome DevTools.
Если запрос отклонён, сохраните точное сообщение. Если запрос не отправился, зафиксируйте действие, после которого это произошло. Такие наблюдения полезнее предположения «виджет не работает».
3. Проверьте, должен ли звонок начаться сейчас
Принятая заявка может ожидать назначенного времени. Сравните время отправки с рабочим графиком, выбранным посетителем временем и часовым поясом настройки. Отдельно проверьте, к какому офису относится обращение: расписания подразделений могут различаться.
В CallKeeper предусмотрен отложенный запуск заявок, полученных вне рабочего времени. Конкретное поведение зависит от настроек, поэтому проверять нужно назначенное время своей заявки, а не только факт её появления. Сценарий описан на странице обратного звонка CallKeeper.
Если время ещё не наступило, отсутствие немедленного вызова само по себе не является сбоем. Если наступило, но попытки нет, передайте поддержке ID заявки и назначенное время с часовым поясом. Не запускайте ручной перезвон, пока не выяснили, не ожидается ли уже автоматическая попытка.
4. Разделите дозвон менеджеру и дозвон клиенту
В стандартном сценарии CallKeeper сначала звонит менеджеру, а после подтверждения соединения — клиенту. Поэтому фраза «мне никто не позвонил» со стороны клиента ещё не указывает, где остановилась обработка. Проверьте порядок соединения, установленный для вашего сценария.
Менеджер не получил вызов. Сверьте номер или направление, на которое должна поступить контрольная заявка. Проверьте доступность этого телефона и историю вызовов на стороне офисной телефонии. Если там есть попытка, но сотрудник ничего не слышал, разбирать нужно прохождение вызова внутри этого направления. Если попытки нет, поддержке сервиса понадобится время и ID обращения.
Менеджер ответил, а клиенту не звонят. Выясните, было ли выполнено требуемое подтверждение. При подтверждении кнопкой важно не только нажатие сотрудника, но и получение системой тонального сигнала DTMF. Не подбирайте кнопку наугад: сверяйте инструкцию и настройки. Если менеджер услышал подсказку и нажал нужную кнопку, но соединение не продолжилось, зафиксируйте это для проверки телефонии.
Клиент получил вызов, но не ответил. Сверьте введённый телефон и историю входящих на устройстве. Статус неуспешной попытки не всегда объясняет, почему человек не поговорил: он мог не успеть ответить, отклонить вызов или быть недоступен. Конкретную причину устанавливайте по подробностям вызова, а не по одному общему статусу.
Обе стороны ответили, но разговора не было. Зафиксируйте, что слышала каждая сторона: тишину, голосовое меню, автоответчик или односторонний звук. Если запись доступна, сопоставьте её с этими наблюдениями. Ответ телефонного оборудования сам по себе не подтверждает содержательный разговор с клиентом.
5. Не смешивайте заявку, попытки и разговор
Одна заявка может привести к нескольким попыткам. CallKeeper позволяет настраивать повторные звонки, но наличие этой возможности не означает, что повтор включён для каждого обращения. Проверьте действующие правила и наличие назначенной попытки.
При разборе запишите отдельно результат каждой попытки и итог обращения. Например, первая попытка не состоялась, затем клиент ответил при повторе. Для оценки обработки заявки важна вся последовательность, а для поиска технической причины — детали конкретной неудачной попытки.
Условный пример: форму отправили в 14:02, менеджер получил вызов и ответил, но подтверждение не было зарегистрировано. На телефоне клиента входящего нет. Здесь проверку стоит продолжить на этапе подтверждения менеджером. Переустановка формы без дополнительных признаков её неисправности не поможет проверить эту гипотезу.
Если разговор состоялся, но не появился в аналитике, это отдельный этап. Его разбирает статья «Почему звонки в коллтрекинге не совпадают с целями Яндекс.Метрики».
Что передать поддержке
Соберите короткое описание одного воспроизводимого случая:
- Страница, название формы или виджета, выбранный офис.
- Время отправки с часовым поясом и ожидаемое время звонка.
- ID заявки или звонка, если он найден; номер для сопоставления передайте в личном обращении поддержке.
- Последний подтверждённый этап и фактический результат у обеих сторон.
- Точное сообщение об ошибке, доступные детали попытки и скриншот проблемного шага.
- Какие условия меняли и что произошло при повторной проверке.
Не прикладывайте пароли, ключи API и полные журналы с посторонними контактами. Для диагностики нужна конкретная цепочка событий, а не вся история аккаунта.
После исправления повторите тот же сценарий. Проверьте, что заявка найдена, звонок начался в ожидаемое время, обе стороны соединились и слышат друг друга, а результат отражён в журнале. Так проверка заканчивается наблюдаемым результатом для клиента.