Для чого потрібна демоверсія 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-системи покаже те рішення, яке зможе найбільш повно реалізувати потреби клієнта.
