Для чего нужна демо-версия CRM-системы?
Тематика: CRM-системы
Отрасль: Банки
Автор: Достаточно часто бизнес-пользователи просят дать им демо-версию CRM-системы для тестирования. Давайте попытаемся разобраться, а всегда ли такой запрос оправдан…
На что в первую очередь смотрят представители бизнеса при оценке CRM-системы? Как правило, это так называемая «юзабильность» или, если сказать привычным языком, «дружественность интерфейса». Но ведь в ходе проекта внедрения CRM основная задача консультантов сводится именно к повышению удобства работы в CRM-системе в рамках того или иного бизнес-процесса.
Еще одним «весомым» аргументом для получения демо-версии является возможность оценки реализации в CRM-системе определенного бизнес-процесса. К сожалению, как показывает практика, самостоятельное ознакомление с функциональными возможностями CRM-системы оставляет множество «темных пятен». Например, в стандартном функционале Oracle Siebel CRM практически для каждой задачи в рамках того или иного бизнес-процесса независимо от отрасли существует множество (обычно пять/десять) возможных сценариев решения. Без предварительного ознакомления с документацией Siebel, разобраться в функциональных возможностях и найти оптимальное решение самостоятельно достаточно сложно.
В качестве примера давайте рассмотрим типичную ситуацию с обработкой запроса по поводу блокировки кредитной карты оператором контакт-центра банка. А точнее нескольких возможных способов её реализации в Oracle Siebel CRM.
Предположим, клиент дозвонился в сервисную службу банка. Прошел по соответствующей ветке IVR-меню и «по дороге» ввёл номер карты…
Все гениальное просто, но не все выгодно
При поступлении звонка на оператора контакт-центра у него открывается вся доступная информация по данной карте. Оператор запрашивает кодовое слово (данные для проверки), идентифицирует уровень доступа к карте и блокирует её нажатием одной кнопки.
Задача решена просто и быстро! Но всегда ли такой вариант может устроить клиента, а тем более банк?
В данном случае не производится идентификация клиента (есть только привязка к карте). Отсутствие доступа к полному профилю клиента препятствует проведению перекрестных и последующих продаж (Cross Sale/UP Sale) и озвучиванию различных уведомлений (изменение процентных ставок по кредиту, необходимость актуализации контактных данных в связи со сменой фамилии и т.п.).
Кроме того, такой подход возможен только в случае, если оператор контакт-центра, принявший звонок, обладает полномочиями самостоятельно выполнять блокировку кредитной карты.
Информация «про запас»
В данном случае оператор контакт-центра нажимает кнопку «блокировать» уже после идентификации не только карты, но и непосредственно клиента. Такое, незначительное, на первый взгляд, изменение может существенно сказаться в будущем. Информация о блокировке карты будет внесена в карточку клиента (профиль в CRM-системе), что позволит привлекать его для участия в кампаниях по перекрестным и последующим продажам в дальнейшем. Кроме того, у оператора контакт-центра будет возможность увидеть и озвучить предложения в рамках уже активных кампаний по клиенту.
Как правило, в CRM-системах перекрестные и последующие продажи могут реализовываться двумя способами:
— плановый — продажи проводятся в рамках кампании, запущенной на основании сегментирования клиентской базы и включающей предложение банковского продукта или услуги, наиболее подходящее данной целевой аудитории (по мнению маркетологов банка);
— ситуативный — соответствующий сценарий запускается при наступлении определенного события, запланированного в CRM-системе.
Уместный Cross Sale/UP Sale
В данном случае после идентификации карты и клиента в CRM-системе автоматически запускается сценарий блокировки карты, в котором уже встроены целевые предложения, срабатывающие при выполнении заданных условий (ситуативные продажи).
Например, оператор контакт-центра сразу же сможет увидеть, что данному клиенту можно предложить новую карту Visa Gold (к тому же, сейчас они предлагаются по акции). Кроме того, сценарий «поймёт», что клиент уже не первый раз теряет карту, и предложит ему дополнительно две неперсонифицированные карты, которые клиент сможет использовать, пока выпускается основная карта, либо передать их членам своей семьи (по сути, самостоятельно выполнить кросс-продажу).
В случае, когда у оператора недостаточно полномочий в системе, в рамках сценария в режиме реального времени будет произведено обращение к ответственному специалисту и оперативно произведена блокировка карты.
Каждый из перечисленных сценариев имеет право на жизнь при определенных условиях. Выбор одного из них будет непосредственно зависеть от тех целей, которые ставит перед собой служба обслуживания клиентов банка.
Как правило, настройка сценариев обработки обращений производится при локализации CRM-системы. В связи с этим, с высокой долей вероятности можно предположить, что в демо-версии отраслевой CRM-системы потенциальный бизнес-пользователь увидит лишь первый вариант сценария, который его не особо впечатлит.
При этом бизнес-консультант сможет правильно снять задачу, согласует бизнес-сценарий и при демонстрации возможностей CRM-системы покажет то решение, которое наиболее полно сможет реализовать потребности клиента.
