Сценарий прошёл демо, а при обзвоне базы ломается: три причины разрыва

Демозвонок прошёл хорошо: робот ответил на вопросы, ЛПР послушал запись и дал добро. В первый же день обзвона базы что-то идёт не так — доля звонков «не по сценарию» растёт, менеджер смотрит на отчёт и спрашивает, что сломалось.

Текст скрипта тут ни при чём. Сломалось предположение, под которое его проверяли: демо и обзвон базы — это два разных по устройству звонка. Разрыв между ними легко предсказать заранее, если знать три места, где он почти всегда возникает.

Карточка клиента для демо чистая, карточка в выгрузке — какая получилась

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

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

Возьмём условный список в 1000 строк. Если у 15% карточек поле интереса пустое или относится к товару, который человек уже купил или от которого отказался, это 150 звонков, автоматически уезжающих в нетиповую ветку. Для демо такую карточку просто не готовили — отсюда ощущение, что сценарий «ломается», хотя причина в данных на входе, а не в тексте.

Разница слышна в первых секундах. На демо: «Здравствуйте, вы интересовались рассрочкой на окна — расскажу, что изменилось». Собеседник сразу узнаёт тему, разговор идёт по накатанной. На живой карточке с устаревшим полем ответ выходит так: «Здравствуйте, вы интересовались нашими услугами — уточню детали». Фраза ничего не значит для человека, который три месяца назад спрашивал про установку забора, а не про окна, и первая реакция — «вы вообще о чём?», на которую у скрипта нет отдельной развилки.

Для демо — типовые возражения, у выгрузки — личная история

Демозвонок почти всегда строится по вежливому плану: отвечает либо сам ЛПР, либо коллега, который знает про проверку и называет стандартные возражения — «дорого», «подумаю», «пришлите на почту». Все они заранее прописаны веткой, и ответ звучит гладко.

Живой человек из выгрузки держит в голове контекст, которого в ветках нет. «Вы мне в прошлый раз обещали скидку и не дали» или «я же говорил вашему менеджеру, что переехал в другой город» — личная претензия, завязанная на истории конкретного клиента, а не типовое возражение. Отдельной ветки под неё обычно нет, и ответ скатывается в общее «передам ваш вопрос менеджеру» — ровно в тот момент, когда человек ждёт, что его услышали.

Пример из записи: собеседник говорит «вы мне уже третий раз звоните, идите вы знаете куда». Это накопленное раздражение от повторных касаний без результата, а не стандартное «неинтересно». Скрипт для первого контакта продолжает вести разговор, будто он действительно первый, и только подливает масла.

Что делать, если такая реплика звучит у десятка собеседников подряд? Тогда дело в следе от прежней кампании по этому же списку — например, прошлогодних холодных звонках менеджера, а не в характере отдельного человека. Правильный ответ здесь — отдельный вопрос на входе, а не попытка оправдаться: «вам уже звонили по этому поводу раньше?» — и короткая развилка для тех, кто скажет «да», вместо попытки вести их как с чистого листа.

Демо назначают на удобное окно, выгрузка разбросана по времени суток

Демозвонок ставят на конкретное время, когда собеседник ждёт звонка и готов слушать. Диалог идёт в комфортном темпе, и скрипт для внимательного слушателя срабатывает без сбоев.

Выгрузка звонка в заранее назначенное время не ждёт. Один и тот же сегмент при звонке в рабочий полдень даёт одну картину, а при звонке ранним вечером — другую: меньше «сейчас некогда», больше завершённых диалогов. Разница в 15–20 процентных пунктов между окнами для одного сегмента — обычное дело, и если скрипт заранее не рассчитан на короткий, прерываемый диалог, он теряет именно тех людей, кого застали не в лучшую минуту. У демо такого разброса не существовало вовсе — там было одно окно, и оно по определению оказалось удачным.

Что проверить на первых 100–200 звонках

Три причины выше невозможно починить правкой текста до запуска — они видны только на живых записях. Четыре шага на первую неделю:

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

Когда разрыв не лечится правкой текста

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

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

Посчитайте на своих цифрах, сколько заявок сейчас теряется в базе и во что обойдётся их поднять