Про можливе переоцінення CJM

 Про CJM — т.зв. карту клієнтської подорожі (customer journey map).

Багато консультантів, а за ними і клієнтів, схильні перебільшувати значення та ефективність цього інструменту.

Особливо це помітно у нас, в Україні, через відсутність системного підходу до побудови сервісу, процесів та взаємодії з клієнтами. Багато компаній хапають щось нове, йдуть "по верхам".

Що таке CJM коротко та простими словами? Це, перш за все, візуалізація. Візуалізація того, як клієнт, в тому числі потенційний, взаємодіє з вашою компанією.

У CJM є певні обмеження, але спочатку давайте визначимо, що має передувати побудові цієї "карти"?

Перш за все, мають бути якісь сценарії надання сервісу (давайте для простоти обмежимось сервісами). Так, як це визначають бізнес-аналітки. Наприклад, клієнт хоче отримати сервіс, він робить те і те, йому відповідають, він надає необхідні уточнення і т.д.

Це не прогноз і не звіт — це припущення. Припущення, які дозволяють зробити початкову версію сервісу.

При побудові "карти" одним з пунктів є визначення т.зв. точок дотику — обставин, за яких клієнт взаємодіє з компанією або щось від неї сприймає (рекламу, наприклад). Це схоже на сценарії, але це принципово різні речі: по-перше, сценарії є припущеннями, тоді як точки дотику вже існують, це не припущення; по-друге, сценарії робляться для побудови сервісу, їх можна змінювати ще до реальної взаємодії з клієнтом, тоді як для змін точок дотику треба перебудовувати повністю весь процес.

Дуже часта ситуація: компанія хоче слідувати модним трендам, хоче CJM , робить перелік точок дотику — і в ході аж сама дивується тому, що у неї відбувається. Тобто якісь сценарії по замовчуванню були, але їх ніхто не аналізував до цього і не збирав статистику. Іншими словами, питання "а що ж ми взагалі робимо" виникло лише при побудові CJM. Не запізно?

Тоді, наприклад, може виявитись, що клієнт на певному етапі невдоволений, це виправляється (дякувати "карті"), але насправді цей етап взагалі зайвий. Це те, чого б можна було уникнути ще до запуску сервісу, але просто над цим недостатньо подумали свого часу, а пізніше ніяк не відслідковували і не аналізували.

Але проблема в тому, що CJM це може і не "помітити". Основне джерело даних для побудови CJM — це відгуки клієнтів. Клієнти не завжди знають, як оптимальніше побудувати сервіс, а ще частіше їх і не питають — питають лише про враження, готовність рекомендувати іншим і т.п.

Тобто спочатку треба сценарії, хоча б базові, потім, виходячи із сценаріїв, побудувати процеси (знову ж таки, хоча б базові), потім, після запуску, почати відслідковувати результати поведінку клієнтів (поведінку, а не лише досвід, бо про досвід ми можемо і не дізнатись), аналізувати дані, коригувати процеси, відслідковувати кейси, що випадають з припущень-сценаріїв та побудованих процесів, знову вносити коригування і т.д.

І лише потім, коли все працює, відслідковується, аналізується і коригується, якщо на те є можливості, відслідковувати тонші моменти, наприклад, рівень задоволеності-невдоволеності клієнтів на тому чи іншому етапі.

Приклад: запропонувати клієнту чашку кави під час очікування — може бути неоптимально з точки зору витрат та процесів, але виправдано з точки зору спроби поліпшити сприйняття клієнтом бренду в цілому і обслуговування зокрема. Тобто це той момент, який може виявити CJM.

Але (і це реальний приклад) якщо у вас не продумані сценарії та процеси, самі процеси виконуються незадовільно, то чашка кави може виглядати лицемірно або навіть як знущання.

Інший реальний приклад: клієнт дзвонить "на підтримку", йому треба "живий" експерт, але він вимушений проходити довгий шлях з різних пунктів автовідповідача, кінець кінцем він достукується до "живої" людини (а може і ні), але питання не виходить вирішити одним дзвінком, рішення відкладується. І після того, як клієнт поклав слухавку, йому приходить смс з проханням оцінити роботу автовідповідача. Бо треба "нагодувати" даними CJM.

Припустимо, що клієнт розумів, що його питання не просте, тому він з самого початку хотів поспілкуватись не з автовідповідачем, а з експертом. Але, з іншого боку, для компанії занадто дорого всіх клієнтів обслуговувати "вживу", вона просто не може собі це дозволити в 99% випадках, тому і "проганяє" його або через автовідповідач, або, як це зараз модно, через бота. Якщо клієнт покаже своє невдоволення — зможе компанія наступного разу відразу давати доступ до експера? Ні, занадто дорого. Якщо клієнт з ввічливості чи просто з розуміння скаже, що його все задовольняє, — от скажіть чесно, можна буде йому повірити? І не думати, що, можливо, треба якось так побудувати процеси, щоб у нього взагалі не виникало необхідності звертатись до підтримки?

Іншими словами, що покаже CJM в такому випадку? Невдоволення, якому зміною автовідповідача все одно неможливо завадити?

Ще одне обмеження: CJM узагальнює дані і не може бути повноцінною заміною аналізу і клієнтської поведінки, і процесів. Це просто по визначенню. Згадаймо, CJM — це перш за все візуалізація. Допомога — може бути, заміна — ні. Сучасний рівень "зняття" даних може дозволити те, що раніше було зробити важко, — аналізувати взагалі всі дані, а не вибіркові чи гіпотетичні. Саме це, а не "карта", може показати і реальний стан процесів, і, частково, поведінку (а не почуття) клієнтів.

Підсумуємо. CJM — прийнятний інструмент, який допомагає зрозуміти певні аспекти взаємодії з клієнтами. Але його не варто переоцінювати і тим більш не варто ним підміняти іншу роботу.

Дещо додам — те, про що тут коротко писалось по сценаріям, зараз виділене в окремий супер-модний напрямок, т.зв. сервіс-дизайн. Плюс: всі розумні та логічні речі (як часто буває, більшість з них відома дуже давно) об'єднані методологією зі своїми принципами та підходами. На основі цієї методології розробляється безліч прикладних методик, часто доволі ефективних та корисних.

Але, як водиться, там, де хайп, треба остерігатись перетворення корисних підходів на щось типу золотого ключика чи срібляної кулі, і не намагатись те, що прийняте на певному етапі, запровадити буквально всюди.

Типовий процес як складова сервісу — кілька думок про це.

Приводом був огляд функціоналу одного сервісу для організації довідки та учбового процесу, але суть не в конкретному сервісі, а в тому, що при ознайомлені власники сервісу намагаються розповісти про функціонал і майже ніколи не розповідають про можливі чи типові процеси.

Більшість сервісів орієнтується на тих клієнтів, у яких вже вибудувані свої процеси, тому вони намагаються не нав'язувати свої, але, по-перше, відсутність хоча б процесів для прикладу ускладнює розуміння функціоналу. По-друге, є велика кількість клієнтів, у яких процеси не вибудувані або потребують корекції. І насправді, вони свідомо чи підсвідомо сподіваються, що доступ до нового сервісу якось "сам собою" налагодить процеси — але в реальності просто не розуміють, як використовувати запропонований функціонал, навіщо він потрібен, чому зв'язки між функціями саме такі, а не інші, і так далі.

Аналіз процесів — найочевидніші проблеми та помилки

Аналіз процесів — розберемо найочевидніші проблеми та помилки.

Контроль процесу з боку клієнта

Клієнт не управляє процесами провайдера (постачальника, продавця і т.д.), але чи можливий контроль процесів з його боку?

Зазвичай, максимум, що очікують від клієнта, — оцінки результату чи відгуку.

Розглянемо на прикладі дуже простого кейсу, чому деколи корисно давати клієнту більше можливостей.

Ситуація: клієнт купив щось онлайн, чекає на доставку. Через якийсь час кур'єр зв'язався з клієнтом і повідомив, що в узгоджений час прибути не може, бо взагалі знаходиться за містом, і чи можна узгодити інший час. 

Клієнт не задоволений ситуацією, бо вже змінив плани, щоб бути вдома в призначений час, але діватись нікуди, погоджується на нові умови. При цьому, кур'єр чітких обіцянок не дає, а пропонує подзвонити пізніше, коли він буде в потрібному районі, і "якось доставити". Клієнт погоджується і пропонує, як варіант, адресу родичів, які завжди дома, кур'єр погоджується і обіцяє дзвінок.

Через якийсь час, коли вийшли всі розумні строки очікування і дзвінка від кур'єра так і не сталось, клієнт телефонує в службу підтримки з запитанням, коли буде доставлено оплачений товар. На що служба підтримки відповідає, що їх дивує така постановка питання, бо ж клієнт сам постійно переносить час доставки — це зі слів кур'єра.

Зрозуміло, що в даному випадку слово кур'єра проти слова клієнта, більш нічого.

Що маємо: компанія-продавець думає, що контролює процес, але насправді певні ланки знаходяться під контролем кур'єра, який може навіть не бути працівником компанії. Більше, компанія не має об'єктивної інформації щодо того, як проходить процес. 

Як можна було б поліпшити ситуацію? Як варіант — заборонити кур'єру переносити строки від імені клієнта, а клієнту, навпаки, дати таку можливість і навіть зобов'язати оформлювати перенос самостійно (на порталі, через дзвінок в контакт-центр, через бота, через аплікацію і т.д.)

Тобто:

1) кур'єр може переносити час доставки, але лише за своєю ініціативою і зі своїх причин (тобто від свого імені, а не від імені клієнта), при цьому і компанія, і клієнт мають бути інформовані;

2) перенос часу доставки чи зміну умов доставки через клієнта — лише за його документованою ініціативою (а не кимось від його імені), з погодженням від компанії та кур'єра, коли буде знайдено варіант, що задовольняє всіх.

Не дивлячись на те, що подібні варіанти вже давно не є новинкою, вони часто ігноруються, і, як наслідок, компанія може дізнатись про невдоволення клієнта лише по факту незадовільного результату, а не в процесі.

Управління помилками — деякі думки

 Принято думати, що помилок треба уникати, пропоную подивитись на це питання трохи ширше.

По-перше, при певній частоті якихось дій помилки, фактично, невідворотні. І має значення: що ми робимо, щоб їх уникнути (і чи робимо взагалі), як ми на них реагуємо, які висновки робимо.

Стереотипний погляд: помилок треба уникати, будь що, помилки треба виправляти, аналіз помилок потрібен для того, щоб помилки не повторювались.

Це досить "прямий" підхід, ми його, по суті, можемо назвати оптимізацією.

Тобто:
- ми знаємо, що треба робити, в цілому,

- ми виправляємо помилки (тобто корегуємо хибний хід процесу),

- наш аналіз націлений на те, щоб змінити сам процес чи інші фактори так, щоб в майбутньому або таких помилок було менше, або ми їх виправляли ефективніше, а частіше — і те, і інше.

Що ми можемо сказати про ситуацію, коли перший пункт не виконується, тобто ми не знаємо, як досягти мети "правильно" (ефективно, результативно) чи взагалі її досягти?

Такі питання, наприклад, стоять перед винахідниками, іноваторами, взагалі перед тими, хто намагається зробити щось нове, що до цього ще ніхто чи мало хто пробував.

І тоді ми можемо сказати, що помилки, фактично, робляться свідомо (наприклад з експериментальних міркувань), тобто мова про уникнення помилок не йде. 

Більше, часто і мова про виправлення помилок в такому разі не йде, бо гіпотеза чи концепція просто відкидаються і все, більше нею мало опікуються.

Аналіз, при цьому, направлений не на виправлення чи на те, щоб більше не повторювати, скільки на вивчення ефектів, що супроводжували помилку, спричинили її, були частиною процесу (часто заздалегідь не врахованою). Тобто фактично помилки, в даному разі, — це свідоме набуття певного досвіду, знань та умінь.

Деякі гуру іновацій пропонують такий підхід: максимально швидко створювати т.зв. MVP (minimal viable product), перш за все з метою перевірки, тобто такий собі "перевірочний" продукт (з цим пов'язаний ще один усталений термін — PoC, proof of concept), швидко перевірити гіпотезу-концепцію і рухатись далі — відкинути, переробити чи розвивати, в залежності від результатів перевірки.

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

Хочу звернути увагу на момент, чому великим корпораціям важко бути ініціативними: там в управлінні помилками превалює традиційний підхід. І дуже важко обгрунтувати радикально інший, експериментальний.

Відомий приклад, свого часу Марісса Майєр прийшла в Yahoo з Гуглу, фактично, рятувати компанію, що втрачала лідерство і перетворилась на донора спеціалістів для більш успішних конкурентів. На новому місці вона, крім іншого, фактично робила рівно те саме, що робила і в Гуглі: скупала пачками нові стартапи, в надії, що якийсь з них "вистрелить" і витягне компанію в цілому чи хоча б покращить її становище, додасть "нової крові".

Але такий підхід потребує і іншого підходу до помилок, які робляться, фактично, свідомо. Що було важко витримати акціонерам Яху: після кількох коштовних і невдалих покупок Маріссу Майєр звільнили.

Я не певен, що її підхід був правильним, просто приводжу це як приклад різного підходу до управління помилками.

Ще один важливий аспект — реагування на помилки.

Парадоксально, але в реагуванні на помилки консервативні компанії часто-густо роблять традиційну помилку: вони припускають, що помилок не повинно бути взагалі. Їх процеси, буває, просто навіть не враховують теоретичну вірогідність тієї чи іншої помилки. Якщо менеджер скаже, що, в разі такої помилки ми будемо реагувати ось так, — то цілком вірогідно йому накажуть просто не робити таких помилок. І все.

Результатом цього є те, з чим стикався, я певен, кожен з нас, — коли клієнт не може "достукатись" до потрібного працівника, бо у них нема сталого алгоритму реагування на певну помилку (системи чи навіть клієнта — не принципово). І працівники "футболяють" звернення один одному, "піднімають" питання на вищий рівень, аж до такого рівня, де менеджер (буває, що це доходить до топ-менеджерів) може без будь-яких процедур і регламентів просто взяти на себе відповідальність за рішення.

Приклад без імен: одна угода на кілька мільйонів мало не зірвалась через принципове бажання клієнта отримати, як він вважав, справедливу знижку на 50 гривень. Справа була, зрозуміло, не в грошах, а в принципі. І взяти гроші від працівників клієнт відмовлявся, він хотів офіційно від компанії-постачальника. А офіційно — не було процедури. Попри те, що стягувати 50 гривень в тих умовах було абсурдно (опущу деталі заради кофіденційності), це просто було бюрократичне перенесення платежу на випадок, де він не мав будь-якого сенсу. Так ось, справа вирішилась лише тоді, коли дійшла до головного бухгалтеру. Хоча це взагалі не той рівень ні питання, ні ціни питання.

Чому? Бо була задача розробити процедуру. Яка виключає помилки (а це неможливо). І, якщо вона виключає помилки, то і реагування на помилки не має сенсу — їх же не має бути.

Сподіваюсь, ті, хто сприймав термін "управління помилками" іронічно, зараз зміг подивитись на це питання ширше — і отримав певну користь від прочитаного.

Персоніфікація та індивідуалізація — деякі особливості з точки зору управління процесами.

Перш за все, чим відрізняється персоніфікація від індивідуалізації? Часто їх використовують разом, часто вони мають однакові чи схожі форми, тому так само часто між ними не роблять різниці, але вона є (якщо під персоніфікацією розуміти і індивідуалізацію також, то, звісно, нема, але тоді й нема про що говорити).

Персоніфікація стосується суто комунікацій з клієнтом і полягає в тому, що клієнта знають, як певну особу, і спілкуються з ним відповідно.

Приклади: звернення по імені чи по імені та по-батькові замість знеособленого "шановний клієнт", вітання з персональними датами (днем народження, річницями та інше), ведення історії спілкування і її використовування (пам'ятати історію замовлень, підказувати стандартні чи найбільш часті замовлення і т.і.)

Індивідуалізація стосується продукту і його змін згідно з індивідуальними потребами клієнта чи особливостями відносин з ним.

Приклади: виготовлення будь-чого "на замовлення" (на відміну від масового продукту), надання сервісу, що дозволяє індивідуальні налаштування, фактично вся проектна робота, різноманітні "конструктори" і т.д.

З точки зору процесів для персоніфікації потрібно:
- мати достатньо потрібної інформації про клієнта;
- забезпечити коректність цієї інформації та її однозначну прив'язку до процесів (відсутність дублювання, наприклад);
- забезпечити "зв'язність" цієї інформації у різних процесах.

Приклади, коли зв'язності інформації про клієнта нема:
1. Служба доставки доставляє продукт, але кур'єр не може його віддати, бо не "бачить" інформацію про оплату, яка була зроблена картою на сайті.
2. Служба безпеки компанії призупиняє надання послуг клієнту, не цікавлячись особливостями його бізнесу — які відомі екаунт-менеджерам.
3. Служба інформування банку вимагає від клієнта сплатити борг, за деталями відсилає до обслуговуючого відділення, — а там інформації про заборгованість не мають.
4. Відповідний відділ прийняв рішення щодо відшкодування, а абонентський відділ про це нічого не знає.
5. Відділ по дебіторській заборгованості шле листи клієнту щодо погашення заборгованності по окремому напрямку, тоді як в цілому у клієнта значна переплата, а загальна щомісячна сума сплат на порядки вище незначної заборгованності.

Всі приклади — реальні, "з життя". Щоб уникнути подібних проблем, важливо забезпечити у всіх процесах, пов'язаних з конкретним клієнтом, наявність відповідної інформації про нього, а також відрегулювати самі процеси згідно з загальною політикою відносин з клієнтами, а не лише процедурами певних відділів.

Індивідуалізація, умовно, має два "полюси": та, що виконується на кінцевому етапі руками клієнта, та та, що виконується виробником, провайдером чи посередником.

Перша "крайність" — це продукти чи сервіси, що дозволяють індивідуальні налаштування та конфігурації. Тобто індувідуалізація "закладена" в сам продукт. До речі, в такому разі вона може бути реалізована без персоніфікації.

З огляду на управління процесами, варті уваги такі моменти:
- відслідковування клієнтського досвіду (через те, що кінцеві налаштування виконує сам клієнт);
- ефективний канал зверненого зв'язку, заради уникнення проблем з продуктом;
- урахування в процесах можливості виникнення небажаних подій та можливості вирішення проблем, що при цьому виникають.

Останній пункт — в тому числі про гарантії, страховки, технічну і нетехнічну допомогу та всі процеси, що з цим пов'язані.

На іншому "полюсі" індивідуалізація, що реалізується самою компанією-виробником (постачальником, провайдером) чи посередником, на замовлення клієнта — частково чи повністю.

З точки зору процесів тут важливо:
- виділити повторювані та стандартні процеси та процедури (навіть якщо виконання повністю індивідуальне, такі все одно є), це підвищує ефективність, зменшує час виконання і здешевлює весь процес;
- забезпечити точність "наскрізних" процесів, що реалізують координацію різних підрозділів чи компанії з партнерами;
- забезпечити зв'язок процесів з загальною політикою та урахування особливостей, навіть за умов широкої індивідуалізації;
- забезпечити достатньо точну аналітику — через унікальність можна легко "вискочити" за рамки бюджету чи навіть можливостей.

Приклад по повторюваним процесам — робота в проектах. Не дивлячись на те, що проекти можуть бути дуже унікальними, все рівно є певні етапи, процеси, процедури і т.і., які різні за змістом, але однакові за призначенням і власне алгоритмом виконання. Наявність "готових процедур" сильно спрощує планування і пришвидшує роботу — що позитивно впливає на витрати.

Про "наскрізні" процеси ще кажуть, що якби з ними не було постійних проблем, то управління процесами як окрема дисципліна ніколи б і не виникла.

Звісно, вони важливі в будь-якому випадку, але у випадку індивідуалізації, коли чітких регламентів та "процедур на всі випадки" може не бути, з ними треба бути окремо обережними і уважними. Інакше може виникнути ситуація, коли відділ продаж домовився про індивідуальний продукт, розробники його фактично створили, але компанія в цілому не може його постачати в потрібних об'ємах через об'єктивні причини. "Загубився" етап узгодження? Так — і там можуть бути також і інші важливі дії, такі, наприклад, як можливість найму виконавців потрібної кваліфікації в потрібних кількостях, оцінка ризиків, вплив на інші продукти.

Згадування загальної політики щодо відносин з клієнтами окремим пунктом — через те, що у випадку індивідуального підходу цей момент є дуже важливим і подекуди забувається. Приклад: клієнту надали унікальний набір послуг, що було закріплено індивідуальною угодою (на відміну від шаблонних), але не було враховано, що певні технічні та юридичні моменти виконуються за іншими, стандартними угодами, що вступають в коллізію з індивідуальною угодою.

Також досить поширеним прикладом є ситуація, коли надання унікального сервісу одному клієнту фактично викликає низку звернень інших клієнтів, що потребує повного перегляду не тільки основних процесів, а подекуди навіть бізнес-моделі.

Пару слів про аналітику — так, без неї нікуди в будь-якому випадку. Але коли вона фактично подається в автоматичному режимі чи близько до того, — це одне. І геть інше, коли унікальність проекту означає і новий набір даних, і, можливо, принципово іншу аналітику, з урахуванням факторів, які до цього не були важливими.

Наприклад, робота в "конвейерному" режимі дозволяє досить чітко планувати ресурси, в тому числі людські. Але коли працівників "висмикують" на окремі проекти, то можуть виникнути "провали", вимушені простої, непередбачувані затримки і т.і.

На завершення додам, що коли є можливість використовувати і персоніфікацію, і індивідуалізацію (хоча б у простому вигляді), то це може стати дуже сильною конкурентною перевагою, — але за умови, що потрібні процеси налагоджені.

Карта клієнтського досвіду чи сценарій

Карта клієнтського досвіду чи сценарій (можливих дій клієнта)?

Насправді, термінологія має вторинне значення, більше важлива суть.

Історично так склалось, що сценарії складають та відслідковують розробники та дизайнери сервісів (програмного забезпечення, програмних додатків, тощо). Їм треба розуміти, що буде робити користувач, що він може, що йому слід дозволити чи заборонити, що може піти не так.

За принципом це схоже на побудову процесів: об'єктом є майбутні дії, важливе значення має оптимальність та наближення до бажаного перебігу і уникнення небажаного.

Тоді як карта клієнського досвіду і взагалі управління клієнтським досвідом передбачає вже наявність і процесів, і, бажано, сценаріїв можливих дій клієнта, — і більш схожа на аналіз процесів. Її об'єктом є певні факти, що вже стались, незалежно від того, за сценарієм це пройшло чи ні, бажаний такий перебіг чи ні. Крім того, дуже часто враховуються речі, які при складанні сценаріїв мають вторинне значення або взагалі не враховуються, наприклад, рівень задоволення клієнта.

Тобто частіше за все сценарії — царина бізнес-аналізу як його розуміє IT-галузь, а карти клієнтського досвіду і взагалі управління клієнтським досвідом — більше частина маркетингу, хоч звісно, по-перше, є взаємний вплив, по-друге, при модифікації сервісу аналітики також досліджують клієнтський досвід, але задачі та способи трохи інші.

На завершення можна сказати, що певний хайп і мода навколо карт клієнтського досвіду з одного боку допомагає розвитку цієї концепції, з іншого, як це часто буває в таких випадках, — заважає і підміняє серйозну роботу її видимістю.

Тож завжди має сенс пам'ятати суть — і знати відповідь на питання "навіщо воно вам".