Человеку нужен человек. Как выстроить работу технической поддержки в IT

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

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

Давайте разберёмся, как работает техническая поддержка и какие основные функции у неё есть.

Мониторинг

Функция по умолчанию

Техподдержка подразумевает мониторинг сайта, и если сайт упал, то это моментально станет известно техподдержке. А сайт может упасть по разным причинам: что-то сделал криво разработчик или заказчик сам напортачил. Также могут быть проблемы с хостингом, баги в CMS, атака хакеров. Возможно, что-то и в техподдержке сделали не так, но именно техподдержка узнает о проблеме первой. Идеально, а так часто и бывает, если сайт поднимается техподдержкой еще до того, как о его падении узнает заказчик. И да, о доверии (см. выше) — техподдержка обязательно сообщит заказчику об инциденте.

Помимо аварий могут быть и другие неприятности: закончился срок действия SSL-сертификата, не установлены критические обновления CMS (или заказчик забыл проплатить такую возможность) или банально подходит к концу регистрация домена. Обо всех потенциальных угрозах заранее предупредит система мониторинга, находящаяся в ведении техподдержки.

3 линии

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

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

• Первичная обработка и/или маршрутизация всех вопросов, возникающих у заказчиков, со всех каналов взаимодействия (чаты, почта, телефония): мы гарантируем, что ни одна задача не будет потеряна, а также будут соблюдены условия SLA по времени реакции на запрос.
• Оповещение об инцидентах не только в чат, но и по звонку, в том числе, по сложным правилам эскалации, а ещё ребята могут сообщить краткие характеристики инцидента, основываясь на показателях мониторинга.
• Формирование задач на основе запросов и комментирование статусов задач заказчику, дополнение задач согласно новой информации, полученной от заказчика, ведение календаря запланированных работ.

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

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

• Разрешение базовых инцидентов — кончилось место на диске, истёк срок действия SSL-сертификата и т.п.
• Консультация клиентов по вопросам работы мониторинга;
• Решение типовых задач.

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

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

• расследования, решение и анализ сложных инцидентов;
• решение сложных комплексных задач;
• формирование инструкций и пополнение базы знаний.

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

Как выбрать систему

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

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

Систему можно интегрировать с Битрикс24, Telegram, Вконтакте и Одноклассниками.

Специалисты в штате, знающие ваш проект

Старый друг лучше новых двух

Текучка в IT всегда есть, пусть и не самая высокая по отраслям и составляет 18%. Однако, если сравнивать текучку в проектном отделе (те самые ребята, которые делали ваш сайт) и отделе поддержки, они значительно отличаются. Само собой в каждой компании своя ситуация, но мы берем информацию из нашего опыта. Если вы пришли заказать сайт — это не имеет никакого значения, а вот если вы на поддержке — всегда спокойнее, когда специалисты: а) в штате; б) уже работали над вашим проектом.

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

Определение и функции

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

В зависимости от того, какой продукт или услугу предлагает компания, техническая поддержка может различаться.

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

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

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

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

Например, у сотрудника не печатает принтер. Сотрудник направит запрос о решении проблемы к специалисту внутренней поддержки. Тот, в свою очередь, даст инструкции удалённо или поможет решить проблему на месте.

Теперь разберёмся, какие функции есть у техподдержки.

Качество, которое выгодно

Либо качественно, либо никак

Учитывая долгосрочное сотрудничество, исполнителю не получится скрыть какой-то баг и убежать. Объяснение простое: завтра в рамках того же договора клиент к тебе вернется и возьмет за грудки. И какой смысл экономить ресурсы сегодня, чтобы потратить минимум столько же завтра? Выгоднее сразу сделать хорошо, чтобы не возвращаться к вопросу заново, при этом сэкономить время и не потерять репутацию. Техподдержка не может себе позволить шалость недобросовестных разработчиков, которые не планируют что-то править после истечения гарантийного срока (допустим, 3 месяца) и соответственно могут оставить невидимые на первый взгляд мины замедленного действия.

Срываем шаблоны

Но это как-то все вилами по воде писано, да? Ликуйте, перфекционисты, приступаем к метрикам. Метрики, надо сказать, очень тонкий и сложный вопрос. Мы не будем сейчас описывать всем известные количественные метрики, – среднее время первого ответа, решения проблемы или доля решенных заявок – потому что мы, в Voximplant, не решились их применять в явном виде. Дело в том, что слепое следование метрикам приводит к автоматизации и роботизированности, которой в качественной поддержке быть не должно. 

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

Но рано или поздно перед руководителями встает задача унифицировать работу сотрудников, чтобы предоставить какие-то результаты начальству или самому оценить эффективность работы. Эта участь не обошла и нас стороной. Однако было не совсем понятно, как именно это сделать, ведь разные задачи как минимум имеют разную сложность. Есть, к примеру, типовые – телеком кейсы, а есть те, с которыми впервые сталкивается даже тимлид. Поэтому, если вводить какие-то метрики по скорости и количеству ответов, у сотрудника появится стимул работать на количество, а не качество. 

Когда тебе надо набрать 30 ответов в день, чаще всего ты берешься за самые легкие тикеты, чтобы набрать заветные баллы, оставляя сложные, но не менее важные вопросы пользователей на потом. Поэтому мы стараемся стимулировать работу головой, анализируя каждый свой шаг. Да, возможно так они потратят больше времени, чем закладывалось, но, если сотрудник разберется с незнакомой проблемой сейчас, то будут оказывать более высокий сервис в будущем. Стоит также понимать, что обучение и торможение процесса – разные вещи. Если сотрудник полдня копался в документации, не попросил помощи и в итоге не решил проблему – есть повод задуматься. Однако право на ошибку есть у всех, но не на систематические провалы.

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

Нужна ли вам техподдержка сайта и кто заказывает музыку?

Доработки по сайту всегда можно заказать

Но на самом деле, всё не так просто. После того, как сайт принят, наступает период, в течение которого исполнитель гарантирует устранить недочеты за свой счет. Но если сайт работает исправно или закончилась гарантия, то все работы будут проводиться в рамках отдельных договоренностей. А это означает инициализацию нетривиального процесса согласования нового договора/приложения/доп. соглашения, в котором задействованы почти все подразделения обеих компаний: от курьера до директора, а в промежутке — менеджеры, специалисты нескольких департаментов и бухгалтерия. Так что прежде, чем раскрутить этот маховик, заказчик, то есть вы, не раз подумаете, а стоит ли новая кнопка или “фича” таких усилий? Не забываем и про то, что согласование документов может затянуться, а “фича” нужна вчера.

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

Еще один существенный момент — за небольшой объем работ web-студия может вообще не взяться. У каждой компании есть своя минимальная стоимостная планка, ниже которой договор не заключается. Как показал беглый обзор рынка, у ряда компаний (но не у всех) эта планка находится на уровне 1000 долларов.

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

По большому счету минимальный уровень поддержки нужен любому сайту, но тут снова стоит вернуться к вопросу окупаемости. Если сайт сделан “для себя” или не рассчитан на извлечение прибыли, то можно обойтись тем, что есть.

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

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

1. Кто-то не может (или не хочет) позволить себе штат из менеджера, админа, разработчика, верстальщика, тестировщика и контент-менеджера. Посчитайте зарплату и накладные расходы для двух-трех человек и поймете, что прикрутить анимированную картинку на сайт будет стоить, как чугунный мост.
2. Кто-то принципиально отдает эти работы на аутсорсинг, дабы не обременять себя непрофильным бизнесом и соответствующим web-департаментом (что кстати соответствует духу времени).

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

Публикация подготовлена компанией ITSOFT. Размещение и аренда серверов и стоек в двух ЦОДах в Москве. Создание и техническая поддержка сайтов, порталов и информационных систем.

Менеджмент задач

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

• приемка,
• первичная обработка,
• распределение задач по исполнителям,
• выполнение,
• консультация по задаче коллег и заказчика,
• передача результатов выполнения.

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

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

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

Профилактика выгораний

Ежедневно в Service Desk приходит сотни обращений от пользователей с различными проблемами, на каждую из которых важно посмотреть с разных ракурсов: проанализировать и задаться вопросом «Что будет, если я решу задачу так или иначе?». Поэтому неудивительно, что любая деятельность, завязанная на повторяющихся задачах, рано или поздно превращается в рутину. Так что же делать, если в дверь все же постучало выгорание? 

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

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

У нас также есть прозрачная система грейдов, а значит и понимание, какие навыки надо подтянуть, чтобы перейти на новый уровень. Это, естественно, влияет и на зарплату, и на статус. Более того, никто не отменял смежного перехода между отделами. Возможности для развития как в техподдержке, так и вне отдела есть у всех. Вопрос в том, хочет ли человек их использовать, готов ли взяться за чуть более сложную задачу или принять участие в нестандартном проекте? Ведь только так, выйдя из зоны комфорта, можно получить новый опыт и развить навыки. 

И главное, помните – минимум рамок и шаблонов. Благодаря этому принципу в голове не перестает трудиться серое вещество.

Зачем нужна техническая поддержка и как в ней не выгореть?

Не всем нравится работать в поддержке. Огромное количество людей выгорает на ней. Так может не стоит вообще её иметь? Какую выгоду она несёт? Можно ли как-то не выгорать от поддержки? Попробуем найти ответы в этой статье.

Расскажу пару слов о себе. В данный момент я работаю C# программистом в компании PVS-Studio, которая занимается разработкой одноименного статического анализатора. К слову, я успел приложить руку к нему. Писал диагностические правила и ядро ломал улучшал. Сейчас работаю в отделе Tools&DevOps, в котором занимаюсь не только очевидными для него вещами, но и оказываю техническую поддержку пользователям.

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

Свой опыт обращения в поддержку

Начну с рассказа о моём первом обращении в поддержку. В общем, дело было так. Шли школьные годы, я играл в World of Warcraft, если память не изменяет, дополнение Mist of Pandaria. Все шло прекрасно, как вдруг столкнулся я с технической проблемой – игра посчитала, что у меня другой класс, и тем самым давала мне неподходящие вещи. Нагуглить решение не получилось, и я решил написать в поддержку.

Мой предыдущий опыт обращения в поддержку других компаний заканчивался обычно одинаково: либо мне просто не отвечали, либо отвечали через неделю что-то в духе “спасибо за ваш отзыв, мы попробуем исправить вашу проблему”. Решения, как вы понимаете, я так и не получал. Поэтому надежды на решение моей проблемы я не чаял, но делать что-то надо было. Однако это были ещё те самые старые Blizzard. Написав сообщение, я получил ответ с решением своей проблемы в чат игры менее чем за 5 минут! Меня поразила скорость и качество работы данной компании.

После этого случая я понял как должна действовать поддержка.

Про нашу поддержку

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

Поддержку, которую я оказываю в рамках направления Tools&DevOps, можно разделить на:

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

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

Теперь, внимание, вопрос: “А зачем вообще всё это нужно?” В чём, собственно, плюс для нас и для пользователей?

Плюс поддержки для пользователей

Плюсы поддержки для пользователей очевидны: проблема решается, улучшается опыт работы с продуктом, периодически добавляется желаемый функционал (или его добавление происходит быстрее). Например, у нас был в далёких планах плагин для CLion. Однако большое количество запросов пользователей явно сказало нам, что его нужно делать. И чем быстрее, тем лучше. Если интересно, то вот статья моего коллеги о его разработке.

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

Плюс поддержки для нас

На самом деле, из поддержки мы, возможно, получаем даже больше пользы, чем пользователи. Давайте по порядку.

Решая проблему вида “что-то не работает”, мы улучшаем качество нашего продукта. Тут всё просто. Тестами покрыть все возможные варианты как, где и с чем использовать наши программы невозможно. У нас уже достаточно большое количество утилит и плагинов, и, соответственно, сценариев их использования. Например, из последнего, нас пробовали использовать в uVisionKeil, о чём пользователь написал очень хорошую статью.

Ещё, из-за специфики технологии статического анализа неизбежны ложные срабатывания. Ложные срабатывания – это ошибочные предупреждения, которые выдаёт анализатор. С данной проблемой борются наши отделы, которые разрабатывают диагностические правила, но всего предусмотреть невозможно. Поэтому, когда пользователь скидывает нам пример кода, на который мы ошибочно ругнулись, мы его исправляем. Тем самым делаем анализатор в каком-то смысле умнее.

Реализуя запросы по добавлению нового функционала от пользователей, мы делаем именно то, что действительно нужно пользователям. Особенно, когда нам об этом написали не один раз. Плюс, когда долго работаешь над чем-то, то взгляд “замыливается”, и уже можешь не замечать, например, что чего-то не хватает или что-то неудобно. В такие моменты обратная связь очень выручает. К слову, за полгода, начиная с 2021, мы сделали по предложениям клиентов следующий функционал:

• Утилита Blame Notifier теперь может сортировать предупреждения по номерам и датам коммитов. Это позволяет видеть предупреждения на правки кода за определённый день;

• В утилиту для проверки C++ и C# Visual Studio проектов PVS-Studio_Cmd.exe добавлена возможность передавать файл подавленных сообщений напрямую через командную строку. До этого подавленные сообщения можно было добавлять только на уровне проектов и solution’а;

• Добавлена поддержка проверки проектов, использующих компилятор MPLAB XC8;

• В утилиту для отслеживания вызовов C++ компилятора CLMonitor.exe добавлен режим проверки списка файлов с учётом зависимостей компиляции между исходными и заголовочными файлами. Данный режим можно использовать для автоматизации проверки merge и pull request’ов. Также добавлен новый режим “AbortTrace”, который позволяет останавливать работу монитора без запуска анализа.

Если вам вдруг стало интересно, что ещё было сделано, то вот тут можно посмотреть историю версий.

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

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

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

Борьба с выгоранием

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

Основное – это то, что человек у нас не занимается постоянно одной только поддержкой. В этом нам помогают ротации. То есть этот месяц я занимаюсь поддержкой, следующий я работаю с плагинами, далее занимаюсь оптимизаций рабочего процесса (Jenkins, скрипты, все дела), затем я улучшаю утилиты и так далее, и так по кругу. Кроме того, можно вообще перейти на ротацию в другой отдел и, например, поделать диагностические правила. Всё это помогает не заскучать и разнообразить рабочие будни. Про разнообразие самих задач я вообще молчу.

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

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

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

Конечно, пандемия внесла свою лепту в подобного рода мероприятия.

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

Для начала – удовольствие после получения благодарности от человека, проблему которого ты решил. Поверьте, тёплые слова всегда приятно слышать. А когда за ними стоят трудозатраты, которые ты совершил – их слушать вдвойне приятнее. Лично меня не раз этот пункт заряжал позитивом и энергией для дальнейшей работы.

Ещё можно поиграть в детектива и потешить внутри себя маленького Шерлока. Я говорю про расследование сложного случая, когда не работает то, что в теории должно работать всегда. При этом зацепок мало, и вот ты начинаешь своё расследование. Об одном таком я уже написал статью. Там рассказывается об интересном случае с WCF и TraceSource. Можете почитать, мне будет приятно 🙂

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

Вывод

Надеюсь, что смог донести до вас своё видение, почему поддержка – это добро, и как от неё получать пользу. Ну а чтобы от неё не выгорать, нужно своеобразно организовывать процессы работы и отдыха. Поэтому не стесняйтесь задавать вопросы своим менеджерам 🙂

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

Спасибо за внимание.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Nikolay Mironov. Technical support: what it’s for and how to avoid burnout?.

Линии технической поддержки

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

Стандартная классификация включает 3 линии технической поддержки.

1 линия. К специалистам этого уровня клиенты попадают при первичном обращении. Здесь собирают информацию о проблеме клиента и помогают решить простые вопросы.

Например, клиент звонит интернет-провайдеру и попадает на 1 линию. У него собирают информацию, создают на её основе задачу и передают специалисту следующего уровня.

2 линия. Здесь решают основные проблемы, которые могут возникнуть у клиента. Специалисты этого уровня обладают большими техническими знаниями и навыками, чем сотрудники 1 линии.

Например, если у клиента не работает одна из услуг мобильного оператора. В таком случае специалист 1 линии поддержки перенаправит клиента на 2 линию, где уже и будут решать проблему.

3 линия. Если вопрос не удалось решить на первых двух линиях, клиента отправляют на 3 линию. Здесь работают с сложными и неординарными проблемами.

Добиться максимальной эффективности работы отдела технической поддержки можно не только с помощью разделения её на уровни. Можно воспользоваться автоматизацией.

Каналы взаимодействия

Под каждый канал коммуникации можно выбрать один или несколько инструментов — или использовать один для всех. У себя мы выделяем следующие каналы:

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

Работа с личным менеджером

Техподдержка — семейный web-доктор

Техподдержка означает взаимодействие с персональным менеджером и выделенными под проект исполнителями. Они закреплены за заказчиком, им не надо объяснять, что было ранее, так как все предыдущие работы задокументированы, соответственно специалист техподдержки может сразу приступить к делу. Если же работать с web-студией в рамках разовых работ (о чем тоже расскажем), задача может быть передана свободному на момент обращения менеджеру/исполнителям, которым потребуется “с нуля” вникать в суть вашего проекта. Проблема ли это? На самом деле нет, но это увеличит стоимость, так как подготовку закладывают в смету.

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

Как выстроить защиту, если чеснок не помог?

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

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

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

Скорость VS Качество

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

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

А как же суперсила техподдержки – скорость? Отвечает Александр Друзь. Для клиента первоначально стоит качество решения проблемы, а не скорость – шок. Результат может быть как через пять минут, так и через день, но исход должен быть один – проблема должна быть решена. И да, это правда может занять целый день, ведь решение каждой проблемы индивидуально и не происходит по чек-листу. 

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

Готовность работать с любыми (почти любыми) сайтами

У техподдержки все дети свои

Далеко не все веб-студии берутся за продолжение работ, начатых другими исполнителями. Порой проще создать новый сайт, чем ковыряться в чужих разработках. Техподдержка, как правило, не капризничает. Диагностика, ремонт и ТО “автомобилей” (сайтов) клиентов — ее профиль.

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

Инструменты

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

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

Всё это позволит увеличить желание сотрудников сначала искать ответы там, а не в гугле или личках у коллег.

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

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

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

• количество алертов вообще и качество алертов в день: не должно быть бессмысленных алертов, которые тратят внимание сотрудников, но при этом не подразумевают никакой реакции на них. Также не норма, если в смену на одного сотрудника приходится более сотни алертов, которые необходимо обрабатывать: это может привести, с одной стороны, к пропуску серьёзного инцидента, с другой — к появлению у дежурного желания сбежать в тайгу и не видеть больше алертницу никогда.
• определенный порядок эскалации для алертов: кроме инструкций, к каждому алерту необходима чётко прописанная схема эскалации. Потому как в любой ситуации сотрудник ТП должен знать, к кому он может обратиться за консультацией, к кому за выдачей доступов и подтверждением своих действий при необходимости, а к кому может пойти, если всё плохо и не получается справиться с аварией самостоятельно.
• формализованный цикл жизни алерта и процесс менеджмента алертов в целом: алерт не должен появляться из ниоткуда и исчезать в никуда после резолва (подробнее об этом в разделе “Менеджмент алертов”).

• Схема бэкапов должна быть задокументирована, чтобы каждый сотрудник техподдержки имел возможность быстро найти резервные копии нужного ресурса.
• Система бэкапов должна быть обвешана инструкциями, как новогодняя елка шарами, чтобы у техподдержки не возникало вопросов “а как развернуть бэкап той базы?”
• Наличие в схеме бэкапов времени восстановления конкретного ресурса — чтоб понимать, сколько времени потребует восстановление работоспособности системы или ее частей.
• Наличие мониторинга бэкапов, чтобы видеть текущий статус конкретных резервных копий, ведь какие-то из них могут оказаться невалидными.

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

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

Сейчас на выбор есть большое количество как платных, так и опенсорсных тикетных систем; многие из них позволяют шаблонизировать задачи и процессы, строить различные диаграммы (всем известного Ганта, например) и использовать разнообразные метрики для формирования аналитики по процессам решения задач.

Доверие

“Не обманешь, не продашь” — это не про техподдержку

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

Минимальное время реакции на происшествие

МЧС для сайта

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

А теперь представьте порядок действий в том случае, если сайт не находится на поддержке:

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

б) Местный айтишник понимает, что в его зоне ответственности все работает нормально и сообщает о проблеме своему руководителю;

в) Руководитель звонит хостеру, а там ему говорят: “У нас проблем нет”;

г) Далее руководитель звонит разработчикам сайта и там ему говорят: “Когда сдавали сайт, его сто раз тестировали” или “Надо разбираться, решим проблему за пару дней. Но это не точно”. Ситуация как у Райкина — “Кто сшил костюм?”

А дальше начинается игра с фразой “А если”:

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

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

В том случае, если же сайт находится на поддержке, то среднее время его восстановления составляет один час. Если же говорить не о восстановлении сайта, а о времени реакции на запрос, то в контракте на техподдержку в разделе SLA обычно прописывается время реакции — не более 2 часов в рабочее время.

Бесценные (неценовые) услуги

Безопасность — трудно оцениваемый, но важный бонус

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

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

Плюсы техподдержки, имеющей свой дата-центр

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

Оптимизация сайта

Задача техподдержки — довести сайт до ума

В зону ответственности техподдержки входит и оптимизация сайта, а именно, решение задач, связанных с увеличением скорости загрузки страниц. Если страница сайта загружается более 3 секунд, то около половины пользователей с сайта уходят. Техподдержка оптимизирует размер и вес изображений, скрипты и прочее. Проверяет на наличие битых ссылок, неработающих страниц, неоткрывающихся имиджей и видео. Логичный вопрос: почему этого не было сделано на этапе сдачи сайта? Ответ: “свежий” сайт всегда быстрее. Меньше контента, минимальная посещаемость, возможно, даже метрики еще не установлены, а значит, показатели будут выше. Конечно, эту задачу можно спрогнозировать и заложить в смету на разработку, но часто ли вы так делаете?

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

Стоимость поддержки сайта

С доверием и честностью, о которых мы говорили выше связаны и финансы. Компания, которая заинтересована в долгосрочном сотрудничестве, не будет ловить рыбку в мутной воде и не станет химичить с оценкой работ по времени и по стоимости. Более того, все операции фиксируются, и заказчик в любой момент может попросить отчет о выполненной работе с “раскадровкой” по времени и задачам. Например, некая задача занимает час квалифицированной техподдержки, который стоит, допустим, 3 тыс. рублей. Сторонний разработчик предложит 1,5 тыс. рублей за час, но выставит счет за 3 часа. В итоге та же работа обойдется в 4,5 тыс. рублей. Или поставит минимальную планку работ по техподдержке, допустим 25 или 50 тыс. рублей в месяц и за меньшие деньги за работы не возьмется, что вполне объяснимо. (Верхняя граница техподдержки корпоративного сайта перешагивает рубеж 100 тыс. рублей в месяц).

Еще пару слов про квалификацию. Не говорим, что всегда, но часто можно увидеть следующую картину ценообразования:

• 1000 рублей в час — за эти деньги часто работают фрилансеры, которые могут пропасть или не очень внимательно отнестись к заказу;
• 1500-2000 рублей в час — над проектом вероятно будут работать специалисты начального уровня. Для выполнения работ им требуется больше времени и они могут допускать ошибки. (Кто-то может слукавить и отдать проект более опытным сотрудникам, но завысит время работ, о чем мы говорили выше);
• 2000-3000 рублей в час — проект вероятнее всего будет поручен высококвалифицированным специалистам, работающим на полной ставке в компании с полностью укомплектованным штатом.

Какой ценник за рубежом? Поддерживать сайты можно не только в России, но и за ее пределами. Не нужно особо пояснять, что в этом случае исполнителю нужно владеть английским и тогда откроется международный рынок, где расценки существенно выше — $80 – 110 в час.

Если говорить о ежемесячных затратах, то поддержка корпоративного сайта или блога по оценкам зарубежных аналитиков может обходиться от $50 до $300 в месяц, а крупного сайта электронной коммерции от $300 до $1000 в месяц. Никого не хотим пугать, но есть и такие расценки — от $1500 до $3000 в месяц.

Менеджмент инцидентов

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

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

Также хорошей практикой является на регулярной основе анализировать статистику срабатывания алертов и на основе этого вносить корректировки в систему мониторинга.

Автоматизация поддержки

Со временем у компании появляется больше клиентов и, соответственно, обращений. Если процессы не автоматизированы, работа будет замедляться, заявки теряться, а удовлетворённость клиентов падать.

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

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

Например, программа получит обращение от клиента по электронной почте. Она автоматически назначит ответственного за выполнение и укажет крайний срок.

Кто есть кто

Вопросы, которые мы решили поднять, достаточно избиты в мире технической поддержки – они обсуждались еще 40 лет назад. Тогда старые добрые «британские ученые» начали выяснять, как эффективно организовать и проконтролировать работу технической поддержки в IT сфере. По итогу ребята выпустили 30 томов с рекомендациями. К счастью, со временем они были сокращены до 5 и получили название «методология ITIL». Суть этой методологии заключается в закреплении узких зон ответственности за каждым специалистом. Так, в компании должно быть разделение как минимум на 1-ю, 2-ю и 3-ю линию поддержки – такая узкая специализация значительно повышает эффективность сотрудников и упрощает коммуникацию с пользователем, ну и, конечно же, между собой. Чтобы этот конвейер входящих вопросов работал, нужно связующее звено – Service Desk. Оно и помогает контролировать весь процесс и эффективность его участников. 

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

1. Самоходы 

Самоходы – это чаще всего разработчики, частные лица, которые (сюрприз-сюрприз) самостоятельно пришли к нам на сайт и увидели технологии, документацию или статью, которые показались им интересными, взяли этот функционал и использовали его в своей разработке. Работать с самоходами одновременно легко и сложно. Дело в том, что эта категория не всегда состоит из квалифицированных кадров, впрочем, как и техническая поддержка – сотрудники не обязаны быть экспертами в языках программирования или в кейсах, отличающихся от базовых. Базовый кейс – это в 90% случаев телеком, то есть проблемы со связью. В этом случае перед сотрудниками поддержки стоит задача деликатно доказать самоходу, что ему необходимо либо подтянуть матчасть, либо внимательнее прочитать документацию. 

Особенность общения технической поддержки с каждым обратившимся в первую очередь состоит в том, чтобы погрузить клиента в процесс и за руку провести его из пункта А – идентификация проблемы – в пункт Б – ее решение. Чем лучше пользователи разбираются в матчасти, тем больше возникших проблем он может решить самостоятельно. Поэтому часто техподдержка выполняет некоторую функцию наставничества. Мы стараемся не столько решать проблему за клиента, сколько помочь ему самостоятельно дойти до решения проблемы.

2. Партнеры 

Партнеры – это те, кто собрал свой продукт, используя инструменты Voximplant, и предлагают его своим клиентам. Типичный пример – onlinePBX – виртуальная АТС для бизнеса. Мы предоставляем компании телефонные номера в аренду, взяв всю операторскую часть на себя, это дает onlinePBX возможность не заморачиваться с лицензиями, регуляторами и другими скучными вопросами. Несложно догадаться, что в этом случае в техподдержку приходят вопросы по тем самым классическим кейсам, про которые мы говорили выше, – проблемы со связью.

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

3. Клиенты-проекты 

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

В этом случае мы не ждем от клиента никакого понимания и компетенций, ведь мы по сути продали им черный ящик, который автоматизирует какие-то процессы внутри компании. Да, ящик он видит, но как именно он работает – не знает. Поэтому в этом случае важно найти точки соприкосновения, а не твердолобо доказывать, что клиент не прав, используя весь набор технических терминов. 

50 оттенков и 100 нюансов.

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

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