Привет, меня зовут Андрей и на момент написания статьи я уже 2,5 года занимаюсь технической поддержкой внутренней CRM-системы в Росбанке. Я хочу поделиться своим опытом и историей развития команды технической поддержки как таковой.
На нашем пути в разные периоды времени были определенные трудности, с которыми мы не могли смириться и закрывать на них глаза. И каждую такую сложность мы воспринимали как вызов, с которым обязательно нужно справиться. Иначе зачем вообще стоило за это браться.
История развития поддержки в нашей внутренней CRM-системе довольно объемная, поэтому я решил разбить ее на несколько статей, каждая из которых будет рассказывать об определенном этапе со всеми сопутствующими деталями и важными моментами.
Но для начала хотелось бы дать небольшую вводную, а именно обозначить некоторые термины, которые я буду использовать по ходу повествования.
PRO Business – внутренняя CRM-система Росбанка, которая предназначена для работы с клиентами малого бизнеса. В ней работают не клиенты банка, а именно сотрудники сети (менеджеры, которые сидят в физическом офисе и обслуживают индивидуальных предпринимателей, владельцев малого и среднего бизнеса).
SD – внутренняя Help Desk система, чьи аналоги довольно распространены в крупных компаниях и реализованы в том или ином виде. Эта система представляет собой общебанковский стандарт, в котором можно получить любую помощь, если она вам действительно требуется. К примеру, решить проблему с оборудованием (как на программном, так и на аппаратном уровнях), получить доступ на внутренние ресурсы банка, обратиться за помощью в профильные команд и подразделения и многое другое.
911 – страничка внутри нашего PRO Business. Этакая точка входа, через которую сотрудники могли обратиться к нам за помощью.
Первая часть этой истории расскажет о том, как мы принимали обращения сотрудников через общий почтовый ящик нашей платформы. Здесь я опишу, какая у нас была боль, и как мы с нею справлялись.
Вторая часть будет посвящена переходу от поддержки через почту к общебанковскому стандарту, а именно в SD. Расскажу, как мы совершили этот длинный прыжок вперед и о том, что этим прыжком мы не достигли того уровня взаимодействия с сотрудниками, который был бы для нас удобен.
В третьей части опишу текущее положение дел и подведу некие итоги. Также в этой финальной части я расскажу о некоторых фичах, которые мы решили реализовать для того, чтобы взаимодействие сотрудников поддержки было удобно прежде всего нам самим.
Итак, поехали. Я пришел в банк в сентябре 2021 года. Моему трудоустройству, разумеется, предшествовало собеседование с руководителем PRO Business, который (так совпало) его и создал много лет назад.
Здесь, пользуясь своим положением автора статьи, хочу позволить себе небольшое лирическое отступление. До Росбанка у меня не было того места работы, где мне искренне хотелось вкладывать в работу всю свою душу. Само собеседование представляло собой не стандартную беседу, в ходе которой кандидату предлагают выполнить какое-нибудь задание или ответить на конкретные вопросы в live-режиме. Это было что-то наподобие разговора по душам. И в душе сразу возникло ощущение, будто мы уже были знакомы какой-то период времени.
Первое знакомство с системой
Итак, собеседование было пройдено, HR-специалисты оформили документы, и я приступил к работе. В первый же день ко мне приставили наставника, который помог оформить заявки на доступы в разные ресурсы нашего банка, чтобы я мог полноценно выполнять свои обязанности, а именно: заниматься технической поддержкой нашего PRO Business.
Меня сразу же начали знакомить с нашей формой обратной связи – страничкой 911, которая была расположена в одной из вкладок в навигационном меню. Скриншота из тех времен у меня, к сожалению, не сохранилось, но я прекрасно помню ее и без этого.
Это была страничка с простенькой HTML-формой, в которой был стандартный набор полей: ФИО сотрудника, выпадающий список тем и подтем для каждого варианта первого, ссылка на страничку, на которой у сотрудника возникла проблема, поле типа textarea, где сотрудник мог текстом описать свою проблему и, конечно же, поле для добавления вложений.
Уже тогда я сразу же отметил для себя некоторые фичи, которые мне хотелось бы реализовать для улучшения рабочего процесса. К примеру, поле «ФИО сотрудника» было пустым при загрузке странички 911, и у меня сразу возник диссонанс – а почему бы не брать готовое значение из сессии текущего авторизованного на PRO Business пользователя, чтобы не вписывать его руками? Да к тому же сделать его нередактируемым, потому что (забегая вперед) иногда это доставляло нам определенные неудобства.
К примеру, руководитель сотрудника мог написать обращение в поддержку, в котором он просит для своего нового подчиненного выдать определенные доступы в рамках PRO Business. И тут сразу возникает вопрос – а чье ФИО писать: свои (то есть того, кто обращается в поддержку) или те, кому требуется помощь? В первом случае руководитель, заполняя поля формы обратной связи, мог забыть указать ФИО своего подчиненного в описании проблемы, а во втором нового сотрудника на PRO Business могло еще и не существовать (он ведь новый сотрудник).
911 + почта = ?
Как сейчас помню свою первую задачу, которую мне поставил руководитель. Иногда в нашей форме обратной связи на страничке 911 терялись вложения, и мне нужно было разобраться почему. Надо отметить, что у меня уже были определенные навыки программирования, и мне нравилось выводить текущий дамп, чтобы шаг за шагом видеть состояние объекта или конкретных переменных. И на одном шаге я увидел, что если в названии вложения (это мог быть скриншот, excel или pdf-файлик) присутствуют русские буквы, то скрипт не пропускал их, и они терялись. Решение оказалось простым: нужно было в функции json_encode() добавить флаг (какой именно, уже не помню), и вложения перестали теряться.
Немного позже коллега из одной внутренней команды внутри нашего PRO Business поделилась своей болью. К ним зачастую приходили обращения, в которых сотрудник не приложил ссылку на одну из основных сущностей, а без ссылки не представлялось возможным начать работу с обращением. Решение также было несложным. Я взял ссылку из формы обратной связи, распарсил ее и перед отправкой формы сделал проверку на существование определенных get-параметров в адресной строке. Если там было ключевое слово (которое обозначало эту сущность), то обращение можно смело отправлять; иначе будьте добры, укажите ссылку на страницу, о которой идет речь.
Здесь я уже описал некоторое положение дел, но все еще специально не упомянул о том, где именно мы видели отправленные сотрудниками обращения в техническую поддержку PRO Business. И здесь также нет сюрприза, потому что всю поддержку мы оказывали посредством электронной почты, а именно общим почтовым ящиком нашего PRO Business. Иными словами, в скрипте отправки формы на страничке 911 была реализована функция отправки письма на наш общий почтовый ящик.
Особо хитрые сотрудники время от времени догадывались писать на эту общую почту напрямую, минуя официальную форму обратной связи, и это доставляло нам определенные неудобства. Во-первых, письмо приходило к нам в совершенно голом виде, без какой-либо верстки. А ведь именно в скрипте отправки формы мы и строили итоговое письмо так, как нам было удобно его видеть. К примеру, первая строка – ФИО сотрудника; вторая строка – его должность; третья строка – выбранная тема и подтема и так далее.
Во вторых, в том же самом скрипте в форме обратной связи была настроена автоматическая навигация по внутренним командам в зависимости от выбранной темы и подтемы. И если к нам приходило такое голое прямое письмо, нам приходилось тратить дополнительное время на выяснение темы и подтемы у сотрудника и направлять его в ту команду, которая отвечает за описанный в обращении функционал. Но через какое-то время, если такое действительно происходило, мы разворачивали сотрудника с комментарием о том, что для обращения необходимо использовать страничку 911.
Зачем нам Application Manager?
Итак, сотрудник заполнил поля формы обратной связи и нажал кнопку «Отправить». Спустя несколько секунд на наш общий почтовый ящик приходит письмо, которое содержит в себе структурированную благодаря HTML-тегам информацию, все вложения и что дальше?
Как я уже упомянул выше, у нас была настроена навигация по внутренним командам в зависимости от выбранной темы и подтемы. Поэтому, открыв письмо, можно было увидеть кому оно также было отправлено помимо нашего общего почтового ящика. Среди получателей можно было увидеть аналитиков из этих самых команд, разработчиков и обязательно их лидеров.
И тут возникает вполне резонный вопрос: а для чего вообще нужно было брать сотрудника технической поддержки, если все работает как часы? Письмо отправляется нужным адресатам (пусть даже и не всегда верно), аналитики и разработчики есть в его получателях. Бери, да отвечай.
Но для того, чтобы глубже понять причину потребности в отдельном сотруднике поддержки, необходимо отправиться в недалекое прошлое. На собеседовании лидер нашего PRO Business рассказал мне, что ранее технической поддержкой занимались сами разработчики. Они создавали и делили между собой определенный график дежурства, и каждый отвечал за свой конкретный временной слот. Спустя какое-то время пришло понимание, что такая схема работы расходует потенциал разработчика, который в это время мог бы заниматься важными задачами исходя из функционала своей внутренней команды. Поэтому было принято решение освободить разработчиков этих команд и посадить на поддержку другого разработчика, который на тот момент занимался скорее общим развитием PRO Business (и он не был привязан к какой-то конкретной команде). Но и у него со временем стали копиться задачи в бэклоге, поэтому такой вариант тоже перестал удовлетворять. И вот, взяли меня.
Моя задача заключалась в том, чтобы прочитать отправленное сотрудником письмо, провести первичную аналитику и попытаться решить его проблему самостоятельно. Если случалось так, что у меня не хватало уровня экспертизы в каком-то конкретном функционале, мне нужно было собрать от сотрудника дополнительную информацию (более подробное описание действий для воспроизведения проблемы на стороне аналитика или разработчика, условия, при которых возникает ошибка и так далее) и направить ее коллегам в ту команду, к которой относится обращение.
Небольшой интересный факт. Если внутри наших команд происходили кадровые перестановки (а именно если кто-то увольнялся или же поднимался по карьерной лестнице), требовалось скорректировать участок скрипта про навигацию писем, и это также ложилось на мои плечи. Задачка плевая, но в долгосрочной перспективе она принесла плоды, поскольку я научился лучше читать код.
Тут важно упомянуть о том, что все наши внутренние команды трудились в мировом гиганте от компании Atlassian и ее реализации продукта Jira. У них были свои продуктовые доски, в рамках которых они создавали и распределяли между собой задачи и планировали бэклог на ближайший спринт.
И здесь я хочу плавно подвести к тому, что осуществление технической поддержки PRO Business было для нас болью, с которой мы никак не могли смириться и которую обязательно надо было решать. Причем эта боль усиливалась по мере того, как наши команды выкатывали все больше и больше своего функционала.
Мы выросли - пора менять подходы к поддержке системы
Как я уже описал выше, наши аналитики и разработчики работали в рамках своего проекта в Jira. И, если честно, времени на поддержку уже имеющегося функционала у них было все меньше и меньше. Разумеется, у всех наших ребят были и свои рабочие почтовые ящики (на которые, я напомню, дублировалось письмо со странички 911), но как им оказывать поддержку, если практически все их время было занято работой над предстоящим релизом?
Ниже я опишу основные тезисы, которые мешали слаженной работе технической поддержки PRO Business:
-
Нам приходилось собирать данные по «крошкам». Напомню, что моей задачей было оказывать сотрудникам помощь и решать их проблемы, которые время от времени проявлялись во время их работы с клиентами малого и среднего бизнеса.
Например, с какой-то конкретной страницей в рамках нашего PRO Business возникла ошибка. Определенно, я не обладаю тем должным уровнем экспертизы, чтобы выявлять причины ошибки на уровне аналитика. Из этого следует вывод: для того, чтобы направить письмо коллегам из внутренних команд, требовалось собрать достаточно информации из длинной переписки с самим сотрудником. В первом письме сотрудник дал лишь наводку; во втором письме он ответил на вопрос «а где именно возникает ошибка?» и предоставил конкретную ссылку; в третьем письме подключился его руководитель и подтвердил, что он все проверил и ошибка действительно имеет место быть. Весь этот процесс затягивался, а решение нужно было здесь и сейчас.
Мы не знали, взяли ли коллеги из внутренних команд обращение сотрудника в работу. Я не зря упомянул о том, что все наши внутренние команды работали в своих проектах внутри Jira, и их время было расписано довольно плотным образом.
Не было выстроенной системы приоритетов и четких сроков решения проблемы (в простонародье SLA). Все это приводило к тому, что важные и даже порой критические ошибки рассматривались в порядке живой очереди, чего нельзя было допускать. Особенно если учесть, что релизы выпускались регулярно и не без сопутствующих ошибок, и все эти ошибки нужно было править. И их правили, но в рамках заведенной на соответствующей доске задачи от аналитика или лидера команды. Опять же внутри своего проекта в Jira.
Как выстроить взаимодействие между командами по части решения обращений в техническую поддержку PRO Business? Да еще и сделать так, чтобы их не просто решали, а решали вовремя. Как найти ту золотую середину для всех разработчиков и аналитиков, которая позволит удовлетворять не только требования бизнеса, но и потребности самих сотрудников?
На эти вопросы я отвечу в следующей части моего цикла об эволюции технической поддержки клиентов малого и среднего бизнеса в Росбанке. Эта первая часть и без того получилась весьма объемной и, честно признаться, я немного в приятном шоке. Сейчас, набирая весь этот текст, я вспоминаю те времена и понимаю, что вся работа была проделана не зря.
Спасибо за то, что уделили время прочтению этой статьи. Увидимся в следующей части!