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

Однако эта мера также оказалась неэффективной: мы не разгрузили операторов, а лишь ввели дополнительные 300 автоматизированных линий IVR, которые тоже быстро забивались.

Хотя время ожидания в этих линиях и было меньше, общая нагрузка на контактный центр не снижалась. Однако IVR всё же принёс полезную функцию: клиентам, попавшим в блокировку, система предлагала оставить номер мобильного телефона для получения СМС‑уведомления о списании абонентской платы. Таким образом мы смогли пополнить базу мобильными номерами клиентов, что впоследствии оказалось полезным.

Тем не менее проблема переполнения линий из‑за недостаточного баланса оставалась нерешённой, и требовалось принимать более кардинальные меры.

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

Напомню: ранее у всей клиентской базы дата списания была единой — 1‑го числа каждого месяца.

После доработок биллинговой системы:

Разумеется, эффект от этих мер наступил не сразу. Большинство клиентов по‑прежнему имели дату списания 1‑го числа, не подключали sms‑уведомления и не доверяли IVR, предпочитая получать ту же информацию от оператора. Однако примерно через полгода от даты реализации всех описанных мер, новая система стала работать. Списания «размазались», база обогатилась мобильными номерами, а клиенты стали более дисциплинированными.

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

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

Решить эту проблему в одиночку мы не могли — требовалось наладить более тесную интеграцию с МГТС, которая отвечала за физическую инфраструктуру.

Информационное взаимодействие между нами и МГТС уже существовало: системы управления заявками были внедрены в обеих компаниях.

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

Чтобы эффективнее работать с массовыми проблемами, нам в первую очередь пришлось доработать бэкенд‑сервисы обмена данными о массовых проблемах между нами и МГТС.

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

Этот механизм был несовершенен по трём причинам:

МГТС обладал:

После доработки механизмов обмена мы стали получать подтверждённые или обнаруженные массовые проблемы вместе со списком затронутых ресурсов. Это позволило:

При обращении клиента IVR, проверял не только наличие массовых проблем, затрагивающих клиента, но и наличие открытых заявок, заведённых на него.

Кроме того, мы предлагали клиенту оставить номер мобильного телефона для получения sms‑оповещения — о том, что массовая проблема или его личная заявка устранены.

Впоследствии мы доработали сервис: стали предлагать клиенту отправить ответное сообщение для подтверждения решения проблемы или возобновления работ по заявке. Это позволило разгрузить службу контроля качества, которая ранее обзванивала клиентов по всем отработанным заявкам.

Таким образом, нам удалось задействовать два новых building block:

Одновременно мы настроили более тесное взаимодействие между уже существующими компонентами — системами обработки заявок обеих компаний (нашей и МГТС).

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

Разобравшись с причинами массовых обращений, мы смогли уделить больше внимания индивидуальным проблемам клиентов. В результате выделили третью группу проблем, приобретавших массовый характер: настройка оборудования и ПК для доступа в интернет.

При первичном подключении к клиентам приезжал инженер и настраивал оборудование. И здесь тоже возникали сложности:

Такие клиенты лишались права на бесплатный выезд и обращались в контактный центр.

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

Сама по себе эта проблема не носила массового характера: хотя она затрагивала большое количество людей, но не была связана с какой‑то одной причиной. Однако низкая компьютерная грамотность клиентов и необходимость проводить настройку удалённо (как я уже упоминал, средств удалённой настройки у нас не было) увеличивали время разговора до 7–8 минут, что неизбежно отражалось на длине очереди.

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

Как и в случае с попыткой разгрузить очереди за счёт привлечения дополнительных сотрудников, эта мера не сработала. Людей не хватало, очередь из звонов трансформировалась в очередь из заявок, а растущее количество заявок создавало отложенный спрос и провоцировало волну повторных обращений с вопросом: «Когда мне уже позвонят и помогут?»

Решая проблему мы вновь обратились к ИТ‑технологиям.

В первую очередь мы наняли ИТ‑компанию для разработки визарда по настройке нашего оборудования. Визард поставлялся на диске вместе с оборудованием и включал:

С его помощью клиент мог самостоятельно настроить оборудование или провести диагностику.

Однако даже наличие диска и подробной инструкции не решило проблему полностью. Многие клиенты по‑прежнему звонили в контактный центр и просили операторов пошагово провести их через процесс настройки.

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

Вторым этапом развития этой идеи стало обращение к производителям оборудования, которое мы продавали. Мы попросили их создать для нас специальную прошивку.

Клиенту достаточно было правильно подключить устройство к телефонной розетке — задача несложная, а при необходимости её можно было выполнить с подсказками оператора. Затем оборудование автоматически подключалось к специальному порталу. Специалист технической поддержки, имея MAC‑адрес этого устройства, мог полностью им управлять.

Мечта специалистов технической поддержки стала реальностью. Однако нам не удалось до конца побороть третью группу проблем. Причины были следующие:

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

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

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

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

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

Ключевые блоки, составившие основу системы:

Объединяя эти блоки и надстраивая над ними вспомогательные сервисы, мы изменили не только нашу компанию, но и индустрию в целом. Многие решения, разработанные в «Комстар‑Директ», впоследствии были повторены и скопированы другими телеком‑компаниями.

Правильное выделение building block остаётся актуальным и сегодня — в эпоху микросервисной архитектуры. На мой взгляд, грамотное определение границ и создание устойчивых структур — единственная защита от хаоса макросистемной несвязанности в мире микросервисов.

Некоторые решения из этого опыта я внедрял перед своим уходом из телекома в 2018–2019 годах — спустя 12 лет после их первичного запуска.