Найкраще ПЗ для служби підтримки: дев'ять платформ порівняно

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

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

Анатомія тикета

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

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

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

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

Спільна поштова скринька чи система тикетів

Цю категорію розділяють дві філософії, і вибір неправильної спричиняє більше тертя, ніж вибір неправильного постачальника.

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

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

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

Деякі платформи поєднують обидва підходи, зберігаючи форму скриньки на поверхні і структуру тикетів під нею. Саме такий підхід використовує RolChat.

Дев'ять платформ одним поглядом

RolChat

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

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

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

ШІ працює на вашому власному ключі серед 62 текстових моделей від семи постачальників. Ціноутворення охоплює компанію, а не місце: $19, $49 і $99 на місяць, Enterprise - за індивідуальною ціною на запит.

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

Zendesk

Zendesk - еталонна реалізація в цій категорії. Тригери, автоматизації, макроси, подання та політики SLA глибші, ніж будь-де в цьому списку, і рівень звітності відповідає цьому.

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

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

Найкраще підходить: для великого обсягу тикетів з окремим адміністратором. Перевіряйте тарифи на сайті Zendesk.

Freshdesk

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

Суміжні продукти Freshworks розширюються до чату, телефонії, CRM та аналітики, кожен зі своєю драбиною тарифів.

Freddy забезпечує шар ШІ по всьому пакету на умовах, які публікує постачальник.

Найкраще підходить: для роботи у форматі тикетів при великому обсязі, особливо разом з іншими продуктами Freshworks. Перевіряйте тарифи на сайті Freshdesk.

HubSpot Service Hub

Service Hub розташований усередині CRM-пакету, тож картка клієнта справді спільна з маркетингом і продажами з першого дня.

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

Для компаній, що вже використовують цю CRM, це легке доповнення. Для решти це рішення більше, ніж просто купівля служби підтримки.

Найкраще підходить: командам, вже прив'язаним до відповідної CRM. Перевіряйте вміст рівнів на сайті HubSpot.

Help Scout

Help Scout - найвідоміша спільна поштова скринька в цьому списку, побудована навколо пошти з прив'язаним довідковим центром і навмисно спокійним виглядом для агента.

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

Покриття каналів вужче, ніж у комплексних платформ, а телефонія не входить до продукту.

Найкраще підходить: для підтримки на основі пошти, де тон важливіший за механіку черги. Перевіряйте тарифи на сайті Help Scout.

Front

Front - спільна скринька для колективної роботи: внутрішні коментарі, спільні чернетки і призначення розташовані поруч з повідомленням, а не в окремому ланцюжку.

Такий формат підходить для B2B-обслуговування, де акаунти мають іменованих власників і де відповідь обговорюється перед відправкою.

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

Найкраще підходить: B2B-командам, що спільно готують відповіді для іменованих акаунтів. Перевіряйте тарифи на сайті Front.

Zoho Desk

Zoho Desk - компетентна система тикетів усередині дуже великої родини продуктів, і її ціноутворення давно одне з найагресивніших у категорії.

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

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

Найкраще підходить: компаніям, вже присутнім в екосистемі Zoho. Перевіряйте тарифи на сайті Zoho.

Gorgias

Gorgias - служба підтримки, створена спеціально для інтернет-магазинів, з даними про замовлення, поверненнями та діями з підпискою прямо в тикеті.

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

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

Найкраще підходить: для підтримки електронної комерції, тісно пов'язаної з платформою магазину. Перевіряйте тарифи на сайті Gorgias.

Groove

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

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

Широта каналів і глибина автоматизації обмежені тим самим вибором.

Найкраще підходить: малим командам, яким потрібна перша служба підтримки без кривої навчання. Перевіряйте тарифи на сайті Groove.

SLA, пріоритети та ескалація

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

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

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

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

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

Автоматизація, що переживає реорганізацію

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

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

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

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

ШІ в службі підтримки

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

Тріаж - найменш помітний і часто найцінніший: класифікація, теґування, встановлення пріоритету та маршрутизація без прочитання агентом.

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

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

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

Варіанти для малого бізнесу

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

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

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

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

Безкоштовні тарифи і скільки вони коштують потім

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

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

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

У RolChat немає безкоштовного назавжди тарифу. 30-денна пробна версія відкриває всі функції і вимагає картку, з першим списанням на 31-й день і нагадуванням за три дні до цього.

Самообслуговування та відхилення тикетів

Відхилення - єдиний важіль у цій категорії, що прибирає роботу, а не переміщує її.

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

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

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

Звітність, що впливає на штат

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

Обсяг за годиною дня визначає графіки змін. Обсяг за причиною визначає, що автоматизувати і що документувати. Частка повторних відкриттів визначає, чи тримається якість.

Навантаження агента важливіше не саме по собі, а в порівнянні розкиду навантаження між агентами: рівномірна черга з довгим середнім - проблема штату, нерівномірна - проблема маршрутизації, і виправлення різне.

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

Доставлюваність пошти та адреса, з якої ви відповідаєте

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

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

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

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

Міграція та прив'язка до постачальника

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

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

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

Два тижні паралельної роботи коштують один додатковий період ліцензії і прибирають більшість ризиків. Це залишається найдешевшою страховкою в цій категорії.

Ролі, дозволи та журнал аудиту

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

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

Журнал аудиту фіксує, що було зроблено і ким. Це те, що просить аудитор, і те, що ніхто не перевіряє, поки не попросять.

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

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

Багатомовні служби підтримки

Другий ринок - найчастіша причина перегляду вибору служби підтримки протягом двох років.

Покриття інтерфейсу - перша вимога, і воно не те саме, що покриття контенту. RolChat має 40 мов інтерфейсу, і маршрутизація може направляти запит тому, хто говорить цією мовою, а не тому, хто вільний.

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

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

Інтеграції та ширший стек

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

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

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

Там, де конектора немає, API та вебхуки, що передають тикети, контакти та події в обидва боки, - запасний варіант, вартий перевірки під час пробного періоду.

Часті запитання

Ruslan Nazarov

Керівник SEO в RolChat

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

LinkedIn