— You have reached English Support. Will you be comfortable communicating in English?
— А по-русски можно?
— Мои извинения, как российской поддержки недоступен в данный момент. Я могу помочь вам перевод. Могу ли я? Я перевел свой ответ, используя Google.
— Хорошо!
Диалог с Дели во время российских праздников

Исторически так вышло, что даже когда первые люди Acronis сидели по чердакам МФТИ, нашими главными рынками были Германия, США и Япония. Поэтому из Москвы мы оказываем поддержку продвинутого, второго уровня на английском, немецком и ещё 4 языках. В других странах расположены команды, предоставляющие поддержку в основном первого уровня. Так, Япония поддерживается из Токио, в Бухаресте есть команда поддержки с несколькими европейскими языками, а также турецким. Ещё две большие команды поддержки, работающие с английским языком круглосуточно, в Дели и Бангалоре. На них иногда и попадают наши русские коллеги в нерабочие или праздничные часы — ниже будет ещё пара примеров, что из этого получается.

Я же расскажу о том, как у нас устроена работа, как мы ищем и обучаем команды, и чем отличается японский стандартный кейс поддержки, например, от немецкого.

Отбор

Первое отличие многоязыковой поддержки от обычной по организации: нужно набирать людей, умеющих свободно говорить на нужных языках. Например, в английском нам не всегда подходит даже Upper Intermediate — нужны те, кто может говорить, как на родном, без запинки. Увы, но с точки зрения технологической компании, сюрприз в том, что, например, для французского, испанского, итальянского и немецкого – это чаще всего выпускники гуманитарных специальностей. То есть люди, которые явно всю жизнь мечтали помогать ИТ-специалистам.

На практике мы пробовали и брать выпускников ИТ-специальностей и обучать их языку, и брать будущих переводчиков и обучать их нужной части ИТ. Второе получается куда эффективнее, поскольку всё реально серьёзное в любом случае уезжает к экспертам поддержки или разработки с собранной информацией и переведённое на русский или английский.

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

Тренер ковыряется в новом продукте до его релиза с QA и разработчиками. Ему важно понять не только и не столько список фич, сколько выявить новые технологии, понять, как именно они работают. Например, для пользователя через интерфейс может создаваться впечатление, что его данные при ресторе «по волшебству» появляются на SharePoint сайте. По факту, эти данные сначала временно помещаются в temp папку на машине и только потом помещаются в базу данных Content DB, после чего папка temp удаляется вместе с содержимым.

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

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

Как собирается информация

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

Наш основной инструмент — AcronisInfo, который собирает данные о машине, продукте, системе, подбирает логи ОС и логи продукта. Он запускается сразу из современных продуктов или же отправляется ссылкой, если речь о поддержке легаси. Acronis Cloud Connection Verification Tool — наша утилита для проверки подключения клиентской машины к дата-центру. По сути, это пакетник из ping, tracert и подобного. ProcessMonitor — очень часто мы пользуемся данным инструментом для того, чтобы понять, что вообще происходит у клиента на машине в процессе выполнения наших задач (бэкапа, рестора, синхронизации). Используем и Wireshark (или tcpdump в линуксовых системах), если нужно понять, что происходит с сетевым соединением, с NAS-ом, сетевой папкой или ещё чем-либо в сети. Он удобен, популярен и тоже не нуждается в комментариях.

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

При обращении из Германии очень часто нужно долго и подробно объяснять, зачем именно нужна каждая утилита, что конкретно (в деталях) она делает, что сотрудник собирается делать с ней и зачем именно, и как он гарантирует, что ничего, кроме описанного, не будет делаться в скрытом режиме. На это может уходить до половины времени обращения — скажем, 20 минут на диалог и 20 минут на непосредственно удалённый сеанс и решение проблемы. С другой стороны, когда мы используем что-то из своего внутреннего корпоративного инструментария для частных клиентов, на той стороне наступает тотальное счастье. Потому что в Германии очень ценят что-то, что сделали специально для тебя, такие вот шаги навстречу.

Обучение

Обучение проводится в двух случаях: для новичков и за 1-2 недели до нового релиза. Ещё время от времени в поддержку приходит отдел контроля качества и учит людей грамотнее говорить с другими людьми. На базе этих же курсов строится новичковое обучение этикету и менталитетам разных стран. Кстати, языков поддержки у нас меньше, чем языков продукта — «разница» поддерживается по-английски.

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

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

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

В конце первого месяца начинается практика с относительно простыми случаями (чаще — письма, где не нужно мгновенно реагировать), плюс идут по 1–2 часа тренинга в день. И подготовка по документации. У нас есть ряд лабораторных работ с нашими виртуалками. Мы разворачиваем заранее «сломанные» образы виртуальных машин, а новичкам нужно законнектиться «к клиенту», разобраться, что не так, и починить или передать экспертам. В конце обучения — экзамен.

Вот рассказывает девушка из команды:

«Только начиная читать, гуглила каждое слово. Приходя, не знала, что такое ленточные библиотеки и в гугл-картинках их смотрела. За 3 года — треть работы: гугление или поиск в нашей документации. Очень много чего освоила — всё равно мне нужно знать про все продуты. Я не спец в Linux, например, и если надо описать что-то в настройках, обязательно дойду до эксперта и проверяю с ним».

В качестве Learning Management System для обучения мы используем веб-платформу Docebo. Её делает итальянская компания, которая предоставляет очень неплохой, а главное, надёжный сервис. Начали недавно, потому что поняли, что надо как-то правильно копить базу знаний, — там внутри размещаются различные внутренние курсы. Ещё есть документация по аналогу внутренней Википедии. Поскольку мы поддерживаем все актуальные версии и «минус один» от них, разница бывает до 3 лет, поэтому нужно держать старые кейсы, но и не грузить новичков тем, что было 5 лет назад.

Процедуры поддержки прописываются в документации. Обычно информация поступает от разработки в достаточно хаотичном виде, но довольно быстро — в течение 3–8 часов от внедрения фичи. Всё это документируется и вносится в стандартные скрипты работы. Тем не менее, иногда нужно ходить и задавать вопросы. Учитывая некоторые интересные особенности общения людей с разным мировоззрением, это часто целая история. Потому что у разработчика мысль, и ему некогда. Бывает так, что техрайтер приходит и даёт понять, что не уйдет, пока не получит ответ, тогда ему стараются помочь чуть больше, чем обычно. Ну, и кроме самих процессов взаимодействия между командами, часто помогают устоявшиеся налаженные связи с конкретными экспертами разработки.

Национальные особенности

Ниже всего оценки у поддержки, выставляемые клиентом в Германии и Японии. В России, например, высший балл могут поставить, если просто услышат грамотную и вежливую техническую речь (особенно на контрасте с предыдущим негативным опытом; сервисная составляющая в России не так развита, как, скажем, в Германии, Японии или США), но быстрое решение тоже важно. В Германии получить высший балл — это редчайшая удача. Быстрое решение, подробное объяснение, «облизывание» и всё такое — это норма для местной поддержки. Чтобы получать оценку выше нормы, надо обязательно рассказывать в деталях, что именно было сделано для человека внутри компании экспертом прямо по шагам. Там очень любят получать отчёты о том, как для них работали, и вдаваться в детали.

В Японии же тройка или четвёрка — это уже хорошо. Чтобы получить пятёрку, надо совершенствоваться в решении одного и того же тикета, наверное, с самого рождения, обучаясь, как ниндзя. Философия такая: если что-то не работает в продукте, то наш контакт уже потратил время на то, чтобы нам об этом рассказать. О высшей оценке речи быть не может.

Особенность рынка США — многие пытаются пробиться сразу на эксперта второй линии, не особо слушая первую. Опытные специалисты умеют доказывать свои навыки и решать проблему. Но бывает и так, что некоторые особо важные клиенты имеют прямую связь сразу с экспертами — и не стесняются звонить по мелким вопросам. Для быстроты решения часто их «назад» не переводят на первую, но всё же основной контакт для них – тоже обычная поддержка.

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


Ну, и напоследок — несколько фактов про нашу поддержку: 63% технических запросов, 37% вопросов по лицензированию, веб-сайту и прочим темам, 95% проблем решаются без необходимости передачи экспертам, 58% проблем решаются после первого контакта; в год может быть до 35 000 сеансов удаленного доступа с клиентами; в поддержке работает 40% девушек, 60% мужиков, итого мы предоставляем поддержку на 9 языках, и вся эта дружная толпа за год может испить кофе из примерно тонны кофейных зёрен.