Ми знаємо, які проблеми є у вашому контакт-центрі. Їх всього дві, але вони змушують вас по-справжньому страждати.
Перша – це безпосередньо управління КЦ. Висока плинність персоналу, необхідність постійно наймати-навчати нових співробітників забирає багато часу. А час – це самі знаєте що. Причому в 90% випадків причина криється в купі додатків, з якими треба працювати оператору. Для клієнта дзвінок – це просто дзвінок. А ось для оператора контакт-центру він перетворюється на роботу з різними додатками, де міститься інформація про людину “на тому кінці дроту”: статус її замовлення, товари в кошику, залишки, рахунки.
І вишенька на цьому торті: у кожного такого сервісу – своя інструкція. Їх десятки – де натискати і що дивитися. Написані на папірцях, в іксельках та інших окремих документах. Немає чіткого алгоритму роботи, є тільки дратівливі папірці та додатки.
Друга проблема – це необхідність дати клієнту максимально повний сервіс за максимально короткий час. Клієнт хоче якнайшвидше вирішити своє питання, а не слухати півгодини заїжджену мелодію Баха.
Хоча здається, який там час – секунди, іноді частки секунд. Але порахуймо – ми ж за data driven business як-не-як. Нехай у вас невеликий контактний центр, де працюють 50 операторів. На кожному кліку ми втрачаємо частки секунди. А тепер перемножимо нашу кількість операторів, кількість звернень, кількість кліків. Ми отримаємо кілька людино-днів, які були витрачені на пошук інформації, на очікування відповіді системи! Кілька людино-днів, за які ми могли надати послуги десяткам і сотням клієнтів! Тому кількість кліків має бути мінімальною, а швидкість реакції – максимальною.
Рішення для обох проблем – завести замість великої кількості різних застосунків єдину систему, сервіс-деск. Розберемося, як це зробити.
Три основні блоки, які потрібно розглянути в рамках проєкту єдиного сервіс-деска:
- функціональність;
- безпека;
- юзабіліті.
Функціональність
Потрібно визначити, що саме і в яких застосунках робить оператор, щоб допомогти клієнту. Збираємо їх у єдину систему і вибудовуємо функціональний дизайн.
Що це означає? Скасувати замовлення і змінити замовлення – кардинально різні функції, які можуть задіяти різні додатки. Скасування замовлення, зміна дати доставки – це робота зі статусом замовлення, і це нескладно. А що робити, якщо нам потрібно замінити товар у замовленні? Тобто потрібно із системи, де замовлення обробляються (а це може бути і кілька застосунків, наприклад, логістична, складська), отримати дані, що взагалі є на складі і на що можна поміняти.
Дивіться, скільки всього задіяно:
- застосунок із даними клієнта;
- застосунок з інформацією про статус замовлення;
- застосунок із каталогом.
Це все різні застосунки, перемикання з одного на інший – це додаткові кліки і час. Оператор працює в режимі реального часу, на тому кінці дроту клієнт, який чекає на рішення. Тому нам потрібна якась єдина система, яка сама знає, що, з яких застосунків і в яких випадках зібрати і видати оператору.
Що ми робимо:
- Збираємо всі юзер-кейси, які є в оператора, що конкретно він робить у тій чи іншій ситуації.
- Складаємо потоки даних: дивимося, як ці юзер-кейси реалізуються різними системами – що куди і звідки передається.
На підставі потоків даних створюємо архітектуру додатків – як різні системи взаємодіють між собою, яка інтеграція між ними необхідна. У цій ситуації треба розуміти, що всі застосунки інтегруються з телефонією і чатами. І ця взаємодія не може бути синхронною, оскільки багато великих систем – “повільні”, вони оброблятимуть запит якийсь час. А оператору треба дати відповідь тут і зараз. Тому великий виклик у створенні архітектури полягає в тому, що максимальну кількість даних зібрати за той час, поки триває з’єднання абонента й оператора.
Далі весь цей “конструктор” треба зібрати й отримати те саме єдине робоче місце для оператора. Туди ще можуть бути додані елементи скриптів, щось на кшталт чек-листа діалогу тощо.
Юзабіліті та безпека
Коли зібрано весь функціонал і розроблено архітектуру інтеграції систем, переходимо до юзабіліті та безпеки.
Юзабіліті – критично важливий фактор у роботі сервіс-десков контакт-центру. Має бути мінімум кнопок і максимум результату на кожну дію. А інтерфейс – інтуїтивно зрозумілий. Як досягти зручності користування? Опрацьовуємо кожен окремий користувацький кейс. Ось прийшов дзвінок щодо скасування замовлення, що далі робить оператор? Що він бачить, що має натиснути, які його дії. При цьому пам’ятаємо, що дій має бути мінімально. Опрацьовуємо кожен можливий користувацький кейс і кожен крок оператора в цьому кейсі.
Складність у тому, що треба поєднати дві протилежності. З одного боку, слід дати максимально багато функціоналу оператору в єдиному робочому місці. З іншого боку, якщо навантажувати застосунок “кнопками”, то він стає не юзабельним. У підсумку втрачається час, знижується рівень сервісу.
Тому інтерфейси треба проєктувати так, щоб був доступний весь функціонал і оператор здійснював мінімальну кількість кліків. Для цього є спеціальні інструменти, які розділяють весь інтерфейс на блоки, при цьому все має бути доступно з єдиної картки. Таким чином ми отримуємо баланс між функціональністю і юзабіліті.
Далі – безпека. Питання безпеки виникає, тому що ми працюємо з персональними даними і є закони про персональні дані, яких потрібно дотримуватися.
Якщо стисло, то основна вимога безпечників – заборонити зберігання важливої інформації у фронтових системах, до яких має кінцевий доступ оператор. Мало того, що жива стороння людина бачить ці дані, так вона ще й віддалено працює, і хто знає, що вона там зробить із цими даними: перепише чи заскріншотить і з якою метою використає.
І якраз те рішення, яке ми пропонуємо, вирішує, зокрема, і питання безпеки. Щойно надходить дзвінок, компанія автоматично ідентифікує його за номером, і система підтягує у віконце оператора всю доступну на цей момент інформацію про цю людину. Усе відбувається за секунди, і коли до клієнта доходить черга, в оператора вже є всі необхідні дані. Зрозуміло, всі крім персональних. Оператор іноді навіть імені абонента не бачить.
Це, до речі, вічна війна між безпечниками і клієнтським відділом: можна показувати оператору ім’я чи ні? Одразу скажемо, ми стаємо на бік того, хто переміг, з технічного погляду нам немає різниці. Процес збору інформації має займати секунди. Ми керуємося золотим стандартом: 80/20: на 80% дзвінків мають відповісти за 20 секунд.
Коли ж оператор закінчив роботу зі зверненням, у системі не залишається жодних зайвих даних, окрім як інформації про сам дзвінок, про тип звернення, про витрачений час. Це, до речі, допоможе компанії збирати хорошу аналітику щодо роботи КЦ, щоб надалі її оптимізувати.
Саммарі
Кожен зайвий клік оператора – це по суті втрачені гроші компанії. Можна цього уникнути і створити умови, за яких взаємодія з клієнтом займатиме мінімум часу, а діалог буде максимально змістовним.
