Этюд в синих тонах, или Работа в поддержке как детектив

Работа в отделе поддержки может стать настоящим детективом, когда вам приходит сложный и непонятный тикет. Словно Шерлок Холмс, вы ищете улики (логи), опрашиваете свидетелей (пользователей) и ищете причинно-следственные связи. О трёх таких делах расскажем в статье. При написании статьи никто из героев не пострадал!

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

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

Я обожаю все современные сериалы о Шерлоке Холмсе и в целом запутанные детективные истории. Мне всегда хотелось ощутить себя на месте главного героя, который по крупицам восстанавливает картину преступления и раскрывает его. Такую возможность мне дала работа в поддержке. Иногда это маленькие «дела» — понять запрос пользователя или поймать баг, о котором тебе сообщили (поверьте, бывает трудно).

Но отдельный вид детективного искусства — это головоломки, для решения которых нужно пройти не один круг ада. Давайте приступим к главному — посмотрим, как же все это происходит на практике.

Обычно люди представляют работу в поддержке примерно так:получение запроса — поиск информации / проверка бага — ответ пользователю.

Как говорится, нет подвоха, но есть нюансы.

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

Однако на практике всё не так прозаично. Как-то нам написали с просьбой помочь включить «новый кабинет».

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

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

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

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

Поскольку такие баги не всегда удаётся поймать с первого раза, при получении тикета и проверки мы можем уточнить, получается ли у пользователя воспроизвести ситуацию в режиме инкогнито. Это делается, чтобы отсеять часть ошибок, которые возникают из-за работы расширений (по умолчанию они в инкогнито выключены).

Однажды нам пришел тикет о том, что в поп-апе с большим числом фильтров не отображается ползунок и не работает сама прокрутка. Юзер предположил, что ошибка происходит после того, как он выбирает определенную группу, а затем повторно открывает список. Тестим — ошибка не ловится. Уточняем про режим инкогнито, однако ответа так и не получаем 😢

Через пару дней прилетает похожий тикет от другого пользователя — и снова без ответа (где-то в мире грустит один котик поддержки из-за этого).

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

Думаю дальше: возможно, пользователь выбирает конкретную группу (элемент фильтра во всплывающем окне), а затем настраивает что-то либо для просмотра данных в группе, либо в целом по проекту. Открытие окна с настройками проекта или экспорта, установка целевой ссылки, окошки с сортировкой, тегами и настройками вида — всё не то. И последнее — но не по значению — календарь. БИНГО! Открываю окно календаря, затем список групп — баг пойман. Передаю задачку нашим разработчикам, и готово — еще один преступник обезврежен.

Итак, наконец-то головоломки. Сегодня расскажем об одной из последних. Собственно, наше «дано» по задачке (прямо как в школьные годы чудесные):

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

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

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

Находясь на этом этапе, мы задумались над отображением записи. Если записи отличаются, может, проверку запустили каким-то нестандартным способом? И тут наш взгляд падает на API, будто это наша единственная зацепка, которая поможет распутать этот комок непоняток. Проверяем в наших логах — проверки действительно запускались через API. Но все еще непонятно, почему запись отличается.

И тут мы понимаем, что было использовано не просто API, а API первой версии, той, которую мы не поддерживаем с 2018 года. Поэтому и формат записи был другой.

Ответ: в компании пользователя с данными аккаунта G был настроен автоматический запрос по API к нам. Одновременно с этим сам пользователь O настроил в проекте автоматическую проверку на другую дату — и вот они, две полных проверки в месяц.

Решение подобного рода проблем само по себе уже интересно и увлекательно, однако отдельное наслаждение после напряженного расследования — видеть «спасибо» от наших пользователей. А помогает в этом также наша тикет-система, в которой они могут оценить ответы поддержки. И несмотря на то что у самурая нет цели и есть только путь, все же именно благодарность согревает нас в холодные питерские дни и ночи. Спасибо, что вы с нами ❤