Unified Communications. Варіант реалізації через vtiger.

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

Техпідтримка + iPad

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

Finding the Balance between IVR and Live-Agent Support | blog.incontact.com

Finding the Balance between IVR and Live-Agent Support | blog.incontact.com

CRM для людей

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

Техпідтримка. Новини

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

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

Подія дня

Була в гостях у служби підтримки MagneticOne. Провела невеличкий семінар про телефонну підтримку загалом і особливості технічної підтримки телефоном. Спілкувались про особливості їхнього саппорта, зокрема як можна впровадити телефонну підтримку продуктів та сервісів. Надзвичайно позитивна команда. Маса приємних вражень. 

Як побудувати call-центр. Початок.

Call-центри бувають  outsourcing (працює для інших компаній) та in-house (обслуговує компанію, в якій створений), які можуть спеціалізуватись на обробці вхідних або здійсненні вихідних дзвінків.  Маємо 4-и типи call-центру. Побудова кожного з них має свої особливості. Якщо outsourcing можна робити "з нуля", то in-house вимагає перебудови існуючих процесів обробки / здійснення дзвінків всередині компанії. 

В серії подальших постів розповім про досвід створення невеликого in-house call-центра з акцентом на обробку вхідних дзвінків, який працює в сфері телекомунікацій.  Call-центр - важлива частина Service Desk.

Зміни. Ефект

Одне з застережень, які давали в курсі OSA (ITIL v3):  Не чекайте позитивних змін відразу, як тільки зробили якесь ефективне нововведення. Обов"язково буде погіршення основних показників, тоді той самий  стан, з якого ви почали, а вже потім - покращення. Чим сильніші зміни, тим глибша "яма" спаду.

Техпідтримка техпідтримки :)

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

Результат: 

Для клієнта:

• кваліфікована відповідь
• можливість усунути проблему зразу

Для нових працівників:

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

Для досвідченіших працівників:

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

ITIL OSA та ентропія

З 1 числа  в контакт-центр додалося кілька нових працівників. Отримали ситуацію, коли частина клієнтів спілкується з досвідченими працівниками, частина зі "свіжими", які тільки проходять "курс молодого бійця". Зараз плануємо перебудувати службу підтримки з розподілом на 1-у та 2-у лінії підтримки. Але ще мінімум 2 тижні будемо мати нестабільність.  Торік  проходила курс ITIL v3 OSA (Operational Support and Analysis - підтримка сервісів). Там звучала теза: "Краще постійно низький рівень підтримки сервісів, ніж коливання між високим та недостатнім". Теза ніяк не обгрунтовувалась. Хоча пояснити це можна виходячи з теорії інформації : ентропія у випадку постійно низького рівня підтримки нижча. Але період нестабільності теж обов"язковий, тому що стабільно низький рівень надання сервісу не є добре. Треба прагнути до стабільного і високого.

Lviv Startup Club 9.0 & обслуговування клієнтів

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

 Виступ наштовхнув на ідею для покращення обслуговування:

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

Візуалізація даних для планування роботи

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

або так

чи так:

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

При цьому 3-ій варіант дуже зручний для моніторингу ситуації вцілому по місту (регіону),  якщо внести наступні доповнення:

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

Можна використовувати такий тип візуалізації і для моніторингу вхідних дзвінків.

Будні техпідтримки

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

Причин порогу в n заявок для m працівників є кілька:

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

Київстар. Досвід спілкування

Передісторія.

Кінець листопада 2009 року - перейшли на з djuce на контракт Київстар. В грудні в системі "Мій Київстар" можна було переглянути  звіт по витратах за листопад. Але тиждень + бонусні кошти + відпустка = 5 грн витрат. На основі цього робити якісь висновки ясно неможливо. Відповідно дуже цікавили звіти за грудень. У поясненнях було вказано що загальна інформація по витратах за попередній місяць надається 5 числа, а детальні звіти з 11. До 5 січня на сторінці було попередження що інформація з"явиться 5, 5 з"явилось що 11, а 11 повідомлення зникло, але у випадаючому меню грудень так і не з"явився. Тобто отримали цікаву ситуацію - дані доступні в системі, а їх  відображення недоступне.

Історія.

12.01 Звертаюсь  в контакт центр Київстар. Суть звернення: "У системі ""Мій Київстар"  нем ожливо  відобразити звіти по витратах за грудень" .Відповідь: "Ми знаємо, мають зробити завтра (13.01) до 18 год"

13.01 18.30 - Не працює. Повторне звернення. Відповідь: "Так, знаємо, термін вирішення - сьогодні 19.00".

13.01 20.00 - Не працює. Повторне звернення. Відповідь: "Так, є проблеми. Інформація, яку вам надавали була приблизною, наступний приблизний термін - завтра, 14 січня, 13 год".

16.01 20.30 - Не працює. Повторне звернення. Відповідь: "Проблема ще є. Орієнтовний час - понеділок, 18.01 11 год."

18.01 12.20 - Не працює.

18.01  18.30 Нарешті ! Правда поки що доступні виключно звіти по дзвінках, а витрати по sms/mms/gprs далі лише за листопад. Тобто можна вважати що по суті звернень до контакт центру - проблема вирішена.

Висновки.

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

Техпідтримка. Звіти

Новий графік - динаміка заявок поденно за січень 2009, січень 2010 та грудень 2009. Вісь X - дні місяця, вісь Y - кількість звернень.

Явно видно що в грудні 2009 - січні 2010 картинка приблизно однакова (принаймі поки що) і звернень приблизно в 2 рази більше ніж за аналогічний період минулого року.

Техпідтримка. Звіти

Аналіз даних дедалі більше захоплює. На черзі інформація за 2009 рік. На графіку нанесено по осі X дні місяця та кількість заявок по осі Y.

На графіку можна помітити мінімальні значення - це дні свят - Паска, 9 травня, 24 серпня та максимальні - дві грози в червні та одна в серпні. Єдиний місяць коли кількість звернень менша середньомісячного значення - січень (що цілком зрозуміло).

Робота техпідтримки.

Трохи проаналізувала роботу нашого відділу за січень (1.01-13.01). Отримала цікаву статистику

• 2 числа було недостатньо працівників для обробки звернень;
• з усіх звернень лише кожен 6 дзвінок стосується  невирішених технічних проблем;

Середня кількість заявок на одного працівника