Три категорії продаються окремо, а купуються для одного завдання: хелпдеск, інструмент лайв-чату, CRM для клієнтського сервісу. Усі вони існують, щоб відповідати клієнтам, не втрачаючи їх з поля зору. Перетин між ними достатньо великий, щоб більшість команд врешті користувалися двома і платили двічі за частину, що дублюється.
Вихід - не таблиця функцій. Це розуміння того, навколо чого насправді побудована кожна категорія, адже саме цей центр вона робить добре, а все інше - лише доповнення.
Три категорії, одне завдання
Кожна категорія організована навколо окремого об'єкта, і все інше випливає з нього.
Хелпдеск побудований навколо тикета: одиниці роботи зі статусом, власником, дедлайном і особою, яка за неї відповідає. Лайв-чат побудований навколо сесії: розмови, що відбувається зараз, виміряної в секундах. CRM побудована навколо облікового запису: людини чи компанії з історією, яка триває довше за будь-який окремий запит.
Запитайте, без якого об'єкта інструмент відмовився б працювати, і його категорія стане очевидною незалежно від того, як його називає сторінка з тарифами.
Інструмент обробляє власний об'єкт нативно, а два інші сприймає як доповнення. Саме тому інструменти лайв-чату незручно зберігають тикети, чому хелпдески показують тонкі профілі клієнтів, а CRM погано працюють як інбокси в реальному часі.
За що відповідає хелпдеск
Хелпдеск існує для того, щоб жоден запит не загубився і в кожного був власник. Його нативні поняття - черги, статуси, призначення, пріоритет, таймери SLA й ескалація.
Це правильний центр, коли робота надходить швидше, ніж вирішується, коли запити переживають більше однієї сесії і коли хтось має відповідати за те, що досі відкрите.
Хелпдеск-софт для тикетингу окупає свою ціну на другий день опрацювання запиту, а не в першу хвилину. Якщо майже все, з чим ви працюєте, закривається в межах однієї розмови, більшість механізмів простоює без діла.
Найкраще працює, коли: обсяг великий, запити переживають одну сесію, і хтось відповідає за дедлайн вирішення.
Лайв-чат і форма чат-розмови
Лайв-чат оптимізований під розмову, яка відбувається просто зараз, і весь його дизайн випливає з цього дедлайну.
Його нативні турботи - поведінка віджета, контекст відвідувача, маршрутизація до того, хто вільний, готові відповіді і перша відповідь, виміряна в секундах, а не годинах.
Він підходить для presale-питань і швидких проблем з обліковим записом. Загалом він підходить для всього, де швидка часткова відповідь переважає повну повільну.
Його слабкість проявляється в момент, коли чат не вдається завершити. Без тикета за спиною незавершена розмова не має ні власника, ні дедлайну, ні статусу, і виживає лише в чиїйсь пам'яті.
Найкраще працює, коли: розмови закриваються в межах однієї сесії і швидкість важливіша за відстеження.
CRM для клієнтського сервісу і картка облікового запису
CRM зберігає обліковий запис: хто цей клієнт, що він купив, що йому пообіцяли і що сталося минулого разу.
Для підтримки це змінює якість відповіді, а не її швидкість. Агент, який бачить план, дату продовження і попередню скаргу, відповідає інакше, ніж той, хто бачить лише поточне повідомлення.
CRM для клієнтського сервісу також робить підтримку видимою для решти компанії. Відділ продажів бачить відкриту скаргу до дзвінка про продовження, а менеджмент облікових записів бачить закономірність до відтоку.
Чим CRM не є, так це інбоксом. Обробка обсягу живих розмов у CRM, розробленій під воронки продажів, - найпоширеніший спосіб все одно отримати два інструменти.
Порівняння за питаннями, що визначають вибір
| Питання | Хелпдеск | Лайв-чат | CRM |
|---|---|---|---|
| Побудований навколо | Тикета | Сесії | Облікового запису |
| Природна одиниця часу | Години-дні | Секунди-хвилини | Місяці-роки |
| Відповідає, хто власник | Так | Ні | Частково |
| Відповідає, хто це | Частково | Ні | Так |
| Переживає зміну каналу | Так | Рідко | Так |
| Провалюється через | Повільну першу відповідь | Втрату незавершеної роботи | Погану обробку реального часу |
Спочатку прочитайте останній рядок. Кожна категорія провалюється передбачуваним чином, і провал, якого ви найменше можете собі дозволити, - найсильніший аргумент на користь того, який центр вам потрібен.
Перетин, за який доводиться платити двічі
Кожна з цих категорій зростала в бік інших, тому межі здаються розмитими на демо і чіткими в щоденному використанні.
Хелпдески додали віджети чату. Інструменти чату додали об'єкти тикетів. CRM додали інбокси. Кожне доповнення реальне, і кожне мілкіше за інструмент, побудований навколо цього об'єкта.
Дублювання рідко видно в рахунку. Воно проявляється як один і той самий клієнт, збережений двічі, одна й та сама розмова, порахована двічі в двох дашбордах, і дві команди, що сперечаються про цифру, бо читають різні системи.
Картки контактів - там, де це коштує найбільше. Два джерела правди про клієнта означають, що жодному не довіряють, і кожен звіт перетворюється на дискусію про те, який експорт правильний.
Сигнали, що ви переросли одну категорію
Момент для зміни легше розпізнати за симптомом, ніж за кількістю персоналу.
Лише чат перестає працювати, коли агенти ведуть таблицю незавершених розмов або коли клієнт повертається, а ніхто не може знайти, що було сказано вчора.
Лише хелпдеск перестає працювати, коли presale-питання надходять як тикети й отримують відповідь занадто повільно, щоб мати значення, або коли агенти відкривають другий інструмент для кожної відповіді, бо профіль занадто тонкий.
Лише CRM перестає працювати в перший же завантажений день, коли макет воронки заважає відповідати сорока людям.
Надійний сигнал у всіх трьох випадках: агенти ведуть власний список поза інструментом. Цей список і є функцією, якої вам бракує.
База знань: елемент, який передбачають усі три
Усі три категорії мовчки припускають існування бази знань, і жодна з них нею не є.
Без опублікованих відповідей готові відповіді розходяться між агентами, вирішення тикетів повторюють вже виконану роботу, а шар ІІ не має нічого надійного, з чого можна було б складати чернетку.
Софт бази знань для клієнтської підтримки окупається двічі: один раз на передньому краї, де клієнти відповідають собі самі, і один раз за лаштунками, де він стає основою для автоматичних чернеток.
Звітність ламається першою, коли інструменти розділені
Розділення проявляється в звітності раніше, ніж будь-де, бо кожен інструмент може порахувати лише те, що бачить.
Чат звітує про час відповіді і пропускає все, що продовжилося поштою. Хелпдеск звітує про час вирішення і не може знати, що на питання вже відповіли в чаті. CRM звітує про облікові записи і нічого не знає про навантаження черги.
Три зелені дашборди можуть описувати досвід, який провалюється, і жоден з них при цьому не помиляється.
Число, яке з'являється лише в об'єднаній системі, - це вартість клієнта по всіх точках дотику, і саме воно визначає штат.
Інтеграція чи одна платформа
З'єднання трьох інструментів - законний вибір, і він працює, коли інтеграції двосторонні, коли ключі ідентифікації співпадають і коли хтось відповідає за синхронізацію при зміні полів.
Він перестає працювати непомітно. Одностороння синхронізація деградує до застарілих даних, перейменоване поле ламає мапінг, якого ніхто не помічає, а провал проявляється як агент, що довіряє неправильному запису.
Одна платформа усуває синхронізацію, а не покращує її. Вартість цього вибору чесна: менша глибина, ніж у спеціалізованого інструменту в тій сфері, де цей спеціаліст найсильніший.
RolChat стоїть на боці єдиного робочого простору: тикети, чат, картки контактів, база знань і 11 каналів за однією моделлю маршрутизації та однією історією.
Порівняйте глибину, яку ви втрачаєте, із синхронізацією, яку більше не потрібно підтримувати. Команди з окремим власником операцій можуть добре керувати трьома інструментами. Команди без нього зазвичай виявляють поламану синхронізацію лише через місяць.
Моделі вартості, що поводяться по-різному під час зростання
Категорії ціноутворюються по-різному, і ця різниця накопичується швидше за будь-який розрив у функціях.
Ліцензування за агента множиться на кількість персоналу, тож сезонний найм двічі на рік змінює рахунок. Пакет, зібраний з трьох продуктів, множиться ще й на кількість продуктів, тому другий і третій інструмент коштують більше, ніж пропонував перший.
RolChat встановлює ціну за компанію, а не за агента: від $19 на тарифі Lite до індивідуальної ціни на Enterprise за запитом, з річною оплатою, що покриває десять місяців. Телефонія та згода - додаткові опції, недоступні на Lite.
30-денний пробний період відкриває всі функції з прив'язаною карткою, чого достатньо, щоб пропустити через нього реальний обсяг, а не зразок.
Вибір без надлишкової закупівлі
Почніть з провалу, якого ви найменше можете собі дозволити. Втрата контролю над роботою вказує на тикет. Втрата продажу, поки хтось чекає, вказує на чат. Відповідь без знання, з ким ви розмовляєте, вказує на картку облікового запису.
Потім перевірте другий за важливістю провал, бо саме він визначає, чи достатньо інструмента однієї категорії, чи перетин коштуватиме вам дорого.
Купуйте під обсяг, який у вас є, плюс один квартал, а не під обсяг з тарифного плану. У інструменти підтримки легко вирости, але дорого вирости з них.
Часті запитання
У чому справжня різниця між хелпдеском і лайв-чатом?
Хелпдеск побудований навколо тикета - одиниці роботи з власником і дедлайном. Лайв-чат побудований навколо сесії - розмови, що відбувається зараз. Перший відстежує, другий відповідає.
Чи потрібна нам ще й CRM для клієнтського сервісу?
Вам потрібна картка облікового запису, яку вона зберігає. Чи надійде вона у вигляді окремої CRM, чи як картки контактів усередині платформи підтримки, залежить від того, наскільки продажам і менеджменту облікових записів потрібен той самий погляд.
Чи можна використовувати CRM як хелпдеск?
Вона може зберігати кейси, але розроблена під воронки продажів, а не під черги. Команди, що обробляють реальний обсяг розмов усередині CRM, зазвичай додають другий інструмент протягом року.
У що насправді обходиться використання двох інструментів?
Крім другої ліцензії, це коштує дубльованих карток контактів, розмов, порахованих двічі в двох дашбордах, і синхронізації, за яку хтось має відповідати при зміні полів.
Як зрозуміти, що ми переросли підтримку лише через чат?
Найчіткіший сигнал - агенти ведуть власний список незавершених розмов поза інструментом. Цей список і є чергою тикетів, якої вам бракує.
Чи завжди одна платформа краща за три інтегровані інструменти?
Ні. Три інструменти працюють, коли інтеграції двосторонні, ключі ідентифікації співпадають і хтось відповідає за синхронізацію. Одна платформа усуває це обслуговування і натомість жертвує певною глибиною.
Де в цьому місце бази знань?
Поза всіма трьома категоріями, але передбачена кожною з них. Вона відповідає клієнтам напряму і постачає затверджений матеріал, на якому ґрунтуються автоматичні чернетки.
Яке число звітності втрачається, коли інструменти розділені?
Вартість клієнта по всіх точках дотику. Кожен інструмент рахує лише те, що бачить, тож три здорові дашборди можуть описувати досвід, який провалюється.
Пише про роботу служби підтримки, живий чат, сервіс із допомогою ШІ та інструменти, що стоять за добрим клієнтським досвідом.
LinkedIn
