Управление сервисным обслуживанием

Когда говорят про управление сервисным обслуживанием, многие сразу представляют себе гору бумаг, SLA-договоры и бесконечные очереди заявок в тикет-системе. Это, конечно, часть правды, но только самая верхушка. На деле, всё упирается в то, как ты выстраиваешь процессы так, чтобы клиент не просто ?получал услугу по контракту?, а чувствовал, что его проблема — это твоя проблема. Особенно это касается сферы, в которой работает наша компания, ООО Хэнань Цзюйхэ Текнолоджи — цифровая трансформация. Тут сервис это не ?починить сломанное?, а обеспечить непрерывность бизнес-процессов клиента, которые уже завязаны на твои решения. Одна ошибка — и простой может стоить ему огромных денег. Поэтому мой подход всегда был не ?реагировать на сбой?, а ?предвидеть его возможность?. Хотя, признаюсь, не всегда это получалось.

От теории ITIL к суровой реальности цеха

В книгах всё красиво: есть инциденты, есть проблемы, есть изменения. Чёткие процедуры. В жизни же, особенно когда внедряешь комплексные решения, как мы в Хэнань Цзюйхэ Текнолоджи, границы размываются. Клиент звонит по ?инциденту? — система тормозит. А на деле оказывается, что это ?проблема?: неверно настроен балансировщик нагрузки из-за неучтённого пикового спроса, который, в свою очередь, стал следствием ?изменения? в бизнес-логике заказчика две недели назад. И вот ты уже не просто техподдержка, ты — детектив, который должен связать воедино звонки от разных отделов одного клиента.

Мы пробовали строго следовать классическим фреймворкам. Завели систему категоризации, приоритизации. Но быстро столкнулись с тем, что высокоприоритетный инцидент от финансового директора (?не могу сформировать отчёт?) на деле решается за пять минут (перезапустить службу), а ?низкоприоритетный? запрос от инженера на производстве (?данные со станка передаются с задержкой в 2 секунды?) — это симптом начинающегося коллапса в сети цеха, который через час парализует линию. Пришлось переучивать и свою команду, и, что сложнее, заказчика. Объяснять, что критичность определяется не должностью звонящего, а влиянием на его ключевой бизнес-процесс. Это был болезненный переход.

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

Проклятие ?зелёного света? или проактивность как она есть

Все хотят быть проактивными. Мониторинг всего и вся, дашборды, зелёные индикаторы. И вот ты смотришь на панель — всё зелёное, тикетов нет. Идеал? Чаще всего — самообман. Потому что клиент уже месяц мучается с неудобным интерфейсом отчёта, просто не хочет ?беспокоить по мелочам?, а потом раз — и уходит к конкурентам, назвав причиной ?плохой сервис?. Сервис-то технически работал, а удовлетворённости не было.

Мы наступили на эти грабли с одним из наших проектов по автоматизации склада. Система работала, датчики передавали данные, но логисты жаловались на ?неудобство?. Жалобы не доходили до уровня ?инцидента?. Пока не выяснилось, что из-за неоптимального интерфейса они тратили на формирование маршрутов на 15% больше времени. Упущенная выгода. После этого мы ввели обязательные регулярные (раз в квартал) обзоры работы системы не с IT-отделом, а с конечными пользователями. Просто спрашиваем: ?Что раздражает? Что можно сделать лучше??. Это даёт больше для реального управления сервисным обслуживанием, чем тонны данных мониторинга.

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

Цифры vs. Восприятие: где настоящий KPI?

Метрики — это святое. Среднее время решения (MTTR), количество инцидентов, удовлетворённость (CSAT). Но слепая вера в цифры опасна. Был случай: наш MTTR был лучшим в портфеле, а клиент был недоволен. Оказалось, мы быстро закрывали тикеты первым попавшимся решением (?перезагрузили сервер?), но проблема возвращалась. Клиент видел не ?быстрое решение?, а ?постоянные перебои?. Мы гонялись за красивой метрикой, а теряли доверие.

Пришлось пересматривать KPI. Теперь мы смотрим не только на время закрытия тикета, но и на процент повторных обращений по одной и той же теме. Ввели метрику ?полноты решения?. И главное — стали чаще звонить. Не писать ?проблема решена, закрываю тикет?, а звонить и говорить: ?Иван Иваныч, мы сделали то-то, проверьте, пожалуйста, со своей стороны. Всё ли теперь работает как надо??. Это простое действие радикально подняло CSAT, даже если объективное время решения немного выросло.

Для компании, позиционирующей себя как ведущий поставщик услуг цифровой трансформации, как ООО Хэнань Цзюйхэ Текнолоджи, это критически важно. Ты продаёшь не софт, а результат. И сервис — это гарантия этого результата. Если на сайте https://www.hnjhkjjt.ru мы заявляем о трансформации, то наша служба поддержки должна быть не ?ремонтной бригадой?, а частью команды, которая обеспечивает непрерывность этой новой, цифровой реальности для клиента.

Инструменты: спасение или ловушка?

Без современных инструментов — никуда. ServiceNow, Jira Service Desk, Zendesk — выбирай на вкус. Мы много чего перепробовали. Ошибка, которую мы совершили изначально — попытались взять ?коробочный? продукт и настроить его под все наши процессы. Получился монстр, в котором команда ненавидела работать. Поток времени уходил не на решение проблем клиента, а на заполнение полей в тикете.

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

Сейчас наш стек — это гибрид. Что-то готовое, что-то своё. Главный критерий — чтобы инженер не думал о системе, а думал о проблеме клиента. Инструмент должен быть невидимкой, помогающим, а не диктующим. Это, кстати, напрямую влияет на качество управления сервисным обслуживанием. Уставший, раздражённый системой инженер никогда не будет по-настоящему доброжелателен с клиентом.

Команда: последняя миля, которая решает всё

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

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

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