Выделение building block в архитектуре (часть 1)

Этап 1. Специалисты по "дохлым лошадям" или устаревшие методы борьбы

В начале своей карьеры я работал в технической поддержке телеком‑оператора. На тот момент я уже имел опыт работы монтажником телеком‑сетей и знал, как работать с технологией Ethernet, поэтому освоение технологии ADSL мне далось относительно легко. Существенной проблемой было то, что поддержкой приходилось заниматься по телефону, т. е. исправлять технические проблемы руками пользователей. Никаких удалённых способов типа Radmin, видеозвонков, чатов с отправкой фотографий у нас тогда не было.

Сложно в это поверить, но тогда в контактный центр, даже в отдел рекламы, брали людей только с высшим или незаконченным высшим образованием. В службу технической поддержки требовалось не просто любое высшее образование — оно обязательно должно было быть техническим. Техническая поддержка делилась да две линии, собственно первую и вторую, инженерную линию поддержки. Попасть на вторую линию поддержки можно было, только проработав от полугода на первой линии поддержки, имея чистую «прослушку» и пройдя аттестацию.

Набирать под такие требования людей было достаточно сложно, и линия технической поддержки была почти всегда занята: клиенты порой часами дожидались ответа специалиста.

Я был одним из первых, кто попросился сразу на вторую линию поддержки, так как уже закончил ВУЗ и имел опыт работы в телекоме. Мне не хотелось полгода проводить на первой линии, чтобы потом попробовать перейти на вторую. Мне повезло: мой тогдашний руководитель согласился на такой эксперимент.

Я прошёл базовое обучение на первую линию, а затем, уже работая на второй линии поддержки, параллельно осваивал техническую часть. Работа была сменной — день‑ночь. Ночью звонков было мало, а свободного времени — много, поэтому я использовал его для изучения недостающих технических аспектов. В итоге мы с коллегой успешно справились с обучением и рабочими задачами и остались трудиться на второй линии поддержки.

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

Примерно через 7 месяцев после того, как я вышел на работу, проблема приобрела критический характер, и руководством компании было принято решение понизить требования к кандидатам. HR‑служба получила задачу обеспечить поток кандидатов и активнее работать со студентами. Так у нас появились разные рабочие графики, а не только 5/2 и 2/2: возникли вечерние графики с 18 до 23, ГПХ с повременной оплатой и руководство стало гибче относиться к отработкам в другие дни.

Первый признак неэффективности подхода - "bottle neck"

И это помогло — у нас пошёл поток кандидатов. И сразу проявилось «бутылочное горлышко» в виде команды обучения, которая сама выросла из службы поддержки, проработав там несколько лет. Усилить эту команду извне было невозможно, а внутри кадры намеренно не выращивались, так как не было такой необходимости, как и штатных вакансий. В итоге мы получили замкнутый круг: тренеров не хватало на поток людей, а новых тренеров взять было неоткуда.

В этот момент я уже перешёл на график 5/2 и был старшим инженером второй линии поддержки, то есть имел опыт и право обучения новичков на вторую линию.

Мой руководитель предложил мне совмещать работу инженера и тренинг‑менеджера и помогать HR‑службе с обучением, когда они не справлялись. Мне было интересно хотя бы иногда не сидеть на звонках, и я согласился.

Обучение пошло быстрее, и колл‑центр стал быстро наполняться персоналом, но на проблему загруженности линий это влияло мало. Да, время ожидания сокращалось, но всё равно оставалось большим: линии были забиты, а удовлетворённость качеством сервиса — низкой.

Проблема требовала от компании иных решений. Компания обратила внимание на ИТ‑технологии, и мне, как человеку, оказавшемуся в нужное время в нужном месте, открылась дорога в ИТ.

Этап 2. Анализ и поиск альтернатив

Так как существенное увеличение численности персонала не дало ожидаемого роста производительности. Для анализа причин нам требовалась статистика, которой у нас не было. Поэтому параллельно с наймом сотрудников мы стали внедрять решение, которое сейчас называют CSRD (Customer Service Representative Desktop).

Первоочередная задача этого приложения заключалась в том, чтобы интегрировать все наши базы данных и сократить время, которое оператор тратил на поиск клиента во всех базах (их было пять). Система получала номер клиента от определителя номеров и автоматически открывала карточку клиента во всех необходимых базах. Второй немаловажной функцией стала фиксация причин и итогов обращения по завершении звонка.

Так начала формироваться наша аналитическая база. В первую очередь была выявлена проблема, о которой мы и так знали, но теперь она была подкреплена цифрами. Дело в том, что тогда биллинговый цикл у всех клиентов был одинаковым: каждый месяц 1‑го числа у всех списывалась абонентская плата. Те клиенты, у которых не оказывалось достаточного количества средств, блокировались и, как следствие, обращались в контактный центр, чтобы выяснить, почему не работает интернет.

Анализ показал, что многие клиенты просто забывали оплатить интернет вовремя. Поэтому каждый месяц с 1‑го по 5‑е число колл‑центр накрывал шквал звонков от клиентов‑должников. Звонили как физические, так и юридические лица.

Такие звонки, конечно, радовали специалистов первой линии, поскольку помогали выполнять KPI по количеству обработанных звонков. Но для компании они были абсолютно бесполезны: клиенты, которым действительно нужна была помощь оператора, не могли дозвониться, а те, кто просто забывал оплатить, получали быстрый и шаблонный ответ о требуемой сумме пополнения.

Этап 3. Разработка новых building blocks

Первоначально мы подумали, что, раз причина в том, что клиенты забывают оплатить, нужно им напомнить о необходимости оплаты. Мы разработали и внедрили систему sms‑уведомлений.

Тем самым, мы заложили первый building block новой системы отношений с клиентами - sms платформа, которой раньше у нас не было.

Тут важен контекст времени: речь идёт о середине 2000‑х, и эффективность этого решения оказалась невысокой. Произошло это по двум причинам.

Во‑первых, номера мобильных телефонов были далеко не у всех клиентов в нашей базе. Тарифы на связь были дорогие, да и аппараты стоили немало, поэтому мобильными пользовались крайне неохотно.

Во‑вторых, банковские сервисы оплаты были крайне слабо развиты. Не то что мобильных приложений — интернет‑банкинг у многих банков отсутствовал.

Потому клиенты, даже получив sms в середине рабочего дня, откладывали оплату на потом и забывали о факте получения уведомления. Как следствие, они всё равно попадали в блокировку.

Более молодое, чем я, поколение может понять эту ситуацию на примере ЖКХ: каждый месяц нужно не забывать передавать показания счётчиков воды и электричества, если дом не оснащён системами автоматизированного учёта. Я многократно попадал в ситуацию, когда напоминание всплывало в моменты, когда я был не около счётчиков, — и порой я даже забывал поставить новое напоминание.

С момента описанной здесь истории прошло почти 20 лет, и необходимость помнить про показания счётчиков вызывает у меня лишь раздражение, а не воспоминания о винтажных временах.

Анализируя проблему дальше, мы решили усилить способы уведомления и вывели уведомления о балансе в IVR — поскольку телефоны городских номеров в 99 % случаев совпадали с теми, что были привязаны как идентификаторы к лицевому счёту.

Для этого мы доработали IVR, интегрировав его с нашей клиентской базой и добавив интерактивные функции.

Теперь IVR получал от телефонии номер обратившегося клиента и передавал его в базу данных. По этому номеру система могла:

Таким образом, клиент получал ключевую информацию автоматически — без переключения на оператора.

А мы получили второй building block - интерактивный IVR.

Продолжение в части 2