Конструктор всплывающих окон, которые не раздражают пользователя

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

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

Если же человек зашел на сайт напрямую, то он, скорее всего, уже присмотрел что-то конкретное. Страница попала в его “шорт-лист” и нет нужды отвлекать пользователя дополнительными маркетинговыми сообщениями. Лучше дать ему больше времени на изучение. А персональное предложение, которое простимулирует к покупке, можно сделать, когда он соберется уйти с сайта.

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

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

Настроить по этим параметрам можно любое модальное окно. Дополнительно мы ввели понятие “сессия”. Она задает ограничение на число показов инструментов за определенный промежуток времени. Например, виджет — не чаще раза в полчаса. А если пользователь открыл несколько вкладок и переходит между ними, сессия учитывается суммарно для всех. Это позволяет избежать появления всплывающего окна по триггеру времени на каждой открытой странице сайта.

Таким образом нам удалось снизить надоедливость всплывающих окон и не заваливать пользователей ненужными сообщениями.

Чтобы быстро менять облик всплывающих окон и маркетинговые сообщения внутри этих окон под конкретные сайты, мы сделали визуальный редактор. Получилась эдакая “Tilda для всплывающих окон”. Управление всеми элементами доступно в специальной панели. Меняются тексты, цвет, форма и размер элементов, их расположение. Можно выбирать фон и настраивать анимацию.

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

Чтобы соединить клиента и колл-центр, можно сначала позвонить в колл-центр и затем клиенту. А можно — наоборот, начать со звонка в сторону колл-центра.

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

Неудобства с первым звонком в сторону оператора начинаются, когда клиент оказывается вне зоны доступа. Точное время его появления в сети не известно, а регулярные звонки в колл-центр создают лишнюю нагрузку. Логичнее в таком случае сначала позвонить клиенту.

Чтобы разгрузить колл-центр и добраться до клиента, не “заспамив” его звонками, мы придумали “умный” автодозвон. Он работает следующим образом:

За непосредственное соединение оператора и клиента, который оставил заявку на сайте дилера, отвечают роботы. Собственный робот — система маршрутизации вызовов IVR — есть у колл-центра. Ему звонит наш робот-дозвонщик, который либо сразу подключается к свободному оператору, либо занимает очередь. “Вы пятый в очереди. Дождитесь ответа оператора” — говорит IVR нашему роботу.

Перед тем, как выводить звонок на клиента, важно убедиться, что оператор свободен и готов общаться. Иначе клиенту придется ждать на линии, слушая “песенки” колл-центра. Еще лучше — не просто вовремя соединить оператора с клиентом, но и позаботиться о том, чтобы оператор точно понимал суть предстоящего разговора.

Иными словами, у нас было две задачи:

1. Избавить клиента от долгого ожидания ответа оператора.
2. Сообщать оператору информацию о заявке.

Обычно, пока оператор колл-центра не нажимает нужную кнопку в тоновом режиме, робот проговаривает ему сообщение без остановки. “Нажмите 5 или скажите 5, чтобы позвонить клиенту. Клиент Петр Иванов заказал обратный звонок с формы trade-in на сайте ‘Мазда Ключ Авто’”.

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

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

Основные сущности:

1. Клиенты (обычно сеть дилерских центров)
2. Офисы (куда звонить)
3. Проекты (по маркам авто)
4. Сайты (может быть даже для отдельной модели)

Вокруг этого:

1. Биллинг
2. Выдача доступов пользователям к основным сущностям

Продукт работает по нетрадиционной для сервисов обратного звонка модели монетизации. Раньше сервисы-конкуренты боролись за клиентов, демпингуя по стоимости минуты звонка. В Konget решили продавать минуты по себестоимости и отдельно взимать плату за сервис.

Поэтому на уровне системы мы разделили плату за сам сервис и за минуты звонков. Надо было учесть демо-период, предоплату без авансов и с авансами, постоплату. Также мы интегрировали в обвязку необходимый документооборот.

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

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

Мы придумали такое решение: вместо одной колонки, в которой хранился json, выделили по колонке под каждую настройку. Когда у нас добавляется новая настройка, мы делаем миграцию базы встроенными средствами СУБД. Так для всех объектов эти поля автоматически заполняются дефолтными значениями.

Вначале Konget устанавливался только на сайтах автодилеров Москвы, и скорость загрузки не вызывала нареканий. По мере экспансии в регионы стали возникать проблемы с долгой загрузкой инструментов в зонах, которые находились далеко от серверов компании. Чтобы устранить эти проблемы, мы перенесли скрипты и настройки инструментов в CDN. Он позволяет хранить настройки на серверах рядом с теми пользователями, которые их запрашивают.

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

Поэтому при каждой отправке кода в репозиторий мы автоматически запускаем unit-тесты, которые проверяют логику работы. Если какая-то функциональность выходит из строя, мы тут же об этом узнаем и устраняем проблему еще до того, как тестированием обновления займется тестировщик. Написание тестов под каждую новую задачу занимает порядка 30% времени в разработке, но при этом то время, которое экономится на отладке при запуске обновлений перекрывает затраты на покрытие кода тестами.