Для чего нужна техническая поддержка
Зачем нужна техническая поддержка?
Поиск и устранение неисправностей
Большинство сайтов создаются с целью извлечения дохода, который можно измерить на основании статистических данных. Например, если есть интернет-магазин, где в среднем в час совершается покупок на 5000 рублей, то в случае прекращения его работы по техническим причинам или приостановки поискового продвижения сайта, поисковой оптимизации сайта или контекстной рекламы можно легко оценить упущенную выгоду.
Можно перечислить основные проблемы, вызывающие остановку сервисов и требующие вмешательства технических специалистов:
Проблема
Задачи службы поддержки
поломки в оборудовании у хостинг провайдера
создание резервной системы, способной в кратчайшие сроки заменить вышедшую из строя систему и возобновить работу наиболее критичных сервисов или системы целиком
увеличение посетителей и транзакций до критических значений для имеющихся мощностей
поиск узких мест в алгоритмах и системах хранения данных, масштабирование интернет-проекта за счет увеличения количества серверов
увеличение времени на синхронизацию каталога товаров и заказов
модернизация алгоритмов синхронизации
появление информации об уязвимости в программном обеспечении
обновление программного обеспечения до последней версии
появление любой другой проблемы
ее поиск и устранение
Постоянное развитие интернет-проекта
Чем крупнее проект, тем большую роль играет техническая поддержка интернет-проекта и тем дороже она обходится. Но кроме постоянного мониторинга и исправления появляющихся проблем, специалисты технической поддержки занимаются развитием проекта:
Преимущества технической поддержки
Также проходят различные тестирования ресурса на совместимость с браузерами и корректное отображение:
Техподдержка, за которую не стыдно
Никита Лялин до основания Еадеска был управляющим партнёром в OnlinePBX — про этот период и написана статья.
Почему мы крутые
У нас крутая техподдержка, о которой клиенты рассказывают друг другу. Последний опрос показал, что 91,1% клиентов готовы нас рекомендовать. Есть нюанс — готовы рекомендовать те, кто ответил на опрос.
Поэтому мы замеряем ещё один показатель — удовлетворённость обслуживанием, то есть на сколько баллов из 10 клиенты довольны взаимодействием с нашей техподдержкой. Сейчас этот показатель — 93,8%, в девяти случаях из десяти клиентам всё нравится. По мне это крутой результат, если вам недостаточно — ещё показатель на скрине ниже.
Может сложиться впечатление, что всё идеально и мы не косячим — это не так. У меня много историй, когда техподдержка облажалась, вот две: с хорошим концом и не очень.
Стажер предложил плохое решение и клиенту не понравилось, но дальше вместо помощи сотрудник спорил и что-то доказывал. Тогда клиент написал негативный отзыв в фейсбуке и меня с партнёром пригласили ответить. Мы признали ошибку, исправились и даже осадочка не осталось, подробности истории будут в отдельной статье.
Во второй истории мы потеряли сотрудника и клиента. Сотрудник в конце рабочего дня продержал клиента пять минут на линии, по возвращении сказал, что рабочий день закончился, попрощался и положил трубку. Клиента два дня уговаривали остаться три человека, но он не дал нам второго шанса. И с сотрудником расстались — он не хотел учиться на своих ошибках.
Идеология отличного обслуживания
Идеология и корпоративная культура нужны, если играете вдолгую. Их сложно, дорого и долго строить, но и эффект от них масштабнее. Если с культурой всё в порядке или ищите инструменты с быстрым эффектом — переходите к главе «Практика».
Нет такого документа, который бы описывал идеологию и принципы компании, поэтому мы создали его и назвали «Книга компании». Полистайте ПДФ-файл хотя бы ради клёвых картинок.
Ценности компании
Подробнее ценности описаны в презентации выше, начиная со слайда №8. Скачайте «Книгу компании», чтобы посмотреть попозже.
Портрет идеального сотрудника
Носители качественного сервиса — ваши сотрудники, а не книги, регламенты или сайт. Поэтому и сотрудники должны быть «качественными», мы для этого разработали портрет идеального сотрудника — с какими людьми хотим работать в компании.
Идеальный сотрудник — профессионал, разделяющий ценности компании. Его профессиональные цели совпадают с целями компании. Он любит свою работу и всегда делает её с высоким качеством. Ему не нужен контроль — он сделает в срок, потому что ответственный и дисциплинированный. Он постоянно учится и развивается, ищет новые технологии и пути решения, готов обучать коллег. Умеет и готов работать самостоятельно и в команде.
Мы специально установили высокую планку — идеалы должны быть высокими.
Принципы отличного обслуживания
В «Книге компании» эта тема почти не раскрыта, поэтому исправляюсь.
Над этими пятью элементами мы думали всей командой: поставили себя на место клиентов и формулировали, что важно для нас, вспоминали хорошее и плохое обслуживание.
Практика
Для качественного сервиса недостаточно только идеологии и хорошей корпоративной культуры, нужно найти правильных людей и выстроить процессы. Все ключевые процессы на картинке, описание под ней.
В техподдержку мы берём два типа людей. Первые стремятся быстро чего-то достичь, от них много обратной связи, они двигают компанию вперёд. Вторым важнее комфорт и стабильность — они дольше работают, надёжнее, развиваются планомерно и не дают компании развалиться.
Нельзя сказать, что одни важнее других — в компании нужны оба типа. Соотношение типов зависит от целей компании: если быстро растёте — нужен первый тип, если компания уже стабильная — второй.
Обучение
У нас каждый новый сотрудник проходит обучение в техподдержке, где две основные роли — тренер и наставник. Тренер даёт теорию: ценности и принципы обслуживания, предметную область — телефония, оборудование, интеграции, а также стандарты и инструкции. Задача наставника — научить применять знания на практике, передать связи, научить решать нетиповые ситуации.
Обучение — самая важная часть в системе, оно задаёт стандарты обслуживания и несёт «ДНК компании» новым сотрудникам.
Управление знаниями
В википедии большая статья на тему управления знаниями, у меня проще. В техподдержке знания делятся на общедоступные и для внутреннего использования, оба типа подчиняются общим принципам. Для управления знаниями используются инструменты: от бумаги с распечатанным регламентом до навороченных систем управления обучением.
Неважно какими знаниями и в каком инструменте управлять, надо следовать трём принципам: актуальность, оповещение об изменениях и обратная связь. При изменении в услугах, товарах и продуктах — обновите базу знаний. Обновили — расскажите сотрудникам и клиентам, и обязательно собирайте обратную связь: комментарии, письма, замечания.
Контроль качества
Контроль нужен всегда, даже если вы абсолютно уверены в сотрудниках и выстроили правильную корпоративную культуру, обучение и следуете высоким стандартам обслуживания. Во-первых, контроль качества выявляет пробелы в знаниях и помогает дообучить сотрудника — сделать обслуживание ещё лучше. Во-вторых, это источник обратной связи, откуда можно узнать проблемы клиентов. В-третьих, контроль напоминает сотрудникам, что они делают важную работу.
В контроле главное регулярность, это как замерять температуру у больного на утреннем и вечернем обходе. Регулярность даёт динамику — пациент оживает, стабилен или умирает. Регулярность дисциплинирует отдел на обслуживание с постоянно высоким качеством.
Каждую неделю мы слушаем звонки, проверяем тикеты и просматриваем чаты. Также оперативно обрабатываем жалобы и плохие оценки клиентов. Полученные оценки влияют на ежемесячные KPI отдела и сотрудника, из которых складывает зарплата. А раз в полгода сотрудники обязательно проходят переаттестацию, на которой проверяем теоретические знания.
Развитие отдела и сотрудников
Идеальная техподдержка — не результат, а процесс, который требует постоянных улучшений. Развивать нужно отдел и людей в нём.
С отделом достаточно просто: ставите цели на год-полгода-квартал, составляете план изменений и действуете. Мы не внедрили, но здесь отлично подойдут методики с цикличным подходом вроде PDCA или HADI. Изменять можно всё: каналы поддержки, структуру отдела, используемые инструменты, регламент и стандарты, процессы и процедуры.
С людьми сложнее: развитие понимают по-разному и не все хотят развиваться. Поэтому мы предлагаем разные варианты: нагружаем дополнительными задачами, привлекаем в проекты компании, отправляем на ротацию в другие отделы, повышаем в должности. Кто не хочет развиваться, обычно надолго не задерживается — уходит сам, так как среда заставляет двигаться.
Инструментарий
Идеологию, корпоративную культуру, правильных людей и процессы дополняют инструменты. Они дают делать больше и быстрее с теми же сотрудниками, или делать столько же и тратить меньше. Основной инструмент в нашей техподдержке — хелпдеск, в нём фиксируются все заявки, запросы и консультации.
Мы искали подходящие решение, не нашли и разработали свой хелпдеск — Еадеск. Он объединяет заявки из разных источников, упрощает работу пользователям и автоматически ведёт базу клиентов. Подробнее на сайте.
Техподдержка, за которую не стыдно
Мы строили корпоративную культуру, чтобы в длинной перспективе не было стыдно за техподдержку. Много говорили и говорим с людьми, объясняем принципы и ценности. Если сотрудник не принимает их — расстаёмся. Всё описано в Книге компании.
Параллельно выстраивали системы: поиск и наём сотрудников техподдержки, их обучение, управление знаниями, контроль качества. Учились работать по целям, удерживать и развивать сотрудников. Как всё организовано, смотрите на схеме идеальной техподдержки.
Невозможно идеально обслуживать каждый раз, но всегда можно сделать лучше, сделать не стыдно.
Описание обязанностей и требований к специалисту техподдержки
Содержание
Описание и что значит техническая поддержка
Техническая поддержка (technical support) — это служба, в которую пользователи продукта или услуги могут обратиться за оказанием технической поддержки по решению возникшей проблемы, а также за получением дополнительной информации по интересующему вопросу.
Стоит также отметить, что служба технической поддержки может быть организована и для обслуживания сотрудников компании внутри организации, например, если сотрудникам нужна техническая помощь с компьютерной техникой (сломался компьютер/принтер) или неработающим программным обеспечением.
Отдельно можно выделить техническую поддержку клиентов (или клиентская поддержка). Такой вид поддержки имеет стратегическую направленность и нацелен на выстраивание долгосрочных отношений с клиентами.
Насколько легко освоить профессию?
Часто на начальном этапе (первая линия поддержки) работодатели не требуют наличие глубоких технических знаний. Главное, это умение работать с ПК, с технической документацией и специализированным программным обеспечение. Поэтому, очень часто, студенты и начинающие IT специалисты начинают свой карьерный путь именно с работы специалистом технической службы. В последнее время все чаще компании требуют хороший уровень английского языка.
Чтобы начать работать специалистом технической поддержки второго уровня, необходим запас технических знаний (например часто в описаниях вакансий можно встретить требование опыта системного администратора Linux или Windows от года).
Уровень зарплат
Плюсы и минусы работы специалистом технической поддержке
Обязанности и задачи технической поддержки
Навыки и требования к специалисту технической поддержки
Карьерный рост специалиста технической поддержки
Как и практически во всех IT специальностях, градация у Technical support следующая:
— junior (первая линия технической поддержки или technical support level 1)
— middle (вторая линия технической поддержки или technical support level 2)
— senior (третья линия технической поддержки или technical support level 3)
Основное отличие между градациями карьерного роста специалистов техподдержки — сложность решения задач.
Как правило, первый уровень — уровень для молодых и начинающих специалистов, в обязанности которых входит решение совсем простых задач, составление тикетов, ответы по телефону клиентам;
Уровень 2 — на этом уровне работают более опытные специалисты, которые способны решать более менее сложные задачи;
Уровень 3 — здесь работают специалисты с высшей категорией квалификации. В круг их обязанностей входит решение задач, с которыми не справился 2 уровень технической поддержки.
Виды технической поддержки
Техподдержку можно разделить на 3 направления:
Оказание услуг технической поддержки может быть предоставлена как на бесплатной, так и на платной основе. Платная техническая поддержка предоставляется на определенный срок по определенной цене и может включать в себя следующие услуги:
Наиболее часто за оказанием технической поддержки можно обратиться через чат, электронную почту, форму “обратной связи”, телефон, панель управления, и как правило, по рабочим дням.
В случае, обращения пользователя, специалисты из техподдержки обязаны выяснить нюансы проблемы, найти и предложить способы решения этой проблемы, а также дать рекомендации по дальнейшему предотвращению подобной проблемы.
Обработка обращений пользователей и клиентов происходит с помощью программного обеспечения, например, Helpdesk и Salesforce.
Цели технической поддержки
Проблемы технической поддержки
Не смотря на все основные преимущества работы специалистов в службе технической поддержки, существует ряд определенных проблем. К наиболее частым проблемам относятся:
Курсы для специалистов технической поддержки
Онлайн портал Linux Training Center предлагает набор курсов по изучению Linux, прохождение которых поможет людям без опыта и новичкам в IT уже через 1,5-2 месяца обучения устроится на работу в службу технической поддержки. Работающие специалисты технической поддержки могут существенно расширить свое понимание IT мира и прокачать свои знания. Кроме того, изучение Linux на глубоком уровне даст возможность перехода в более разносторонние IT специальности, такие как “системный администратор” или “DevOps инженер”.
«Поддержка», как много в этом слове…
Итак, продолжаю серию статей «из творческого отпуска», на сей раз мы рассмотрим такие «страшные» вещи, как «сопровождение продуктов», «техническая поддержка», «служба поддержки» и т.д.
В данной статье не будут рассматриваться вопросы управления коллективом, развертывания системы администрирования обращений и детали работы начальников отделов поддержки. Статья скорее является своеобразным введением в проблематику «поддержки IT продуктов»
С чего все начинается
что есть служба поддержки и для чего она нужна?
Хотя вопрос звучит просто, но ответ на него дать не так то и просто. И причиной этому является далеко не сложность этой сферы деятельность. Причина в том, что тут присутствует маленькая особенность — «служба поддержки», равно как и «поддержка» вообще, не являются универсальными понятиями. Их значения очень сильно зависят от конкретной ситуации, которую мы рассматриваем. И чтобы это показать, я приведу один, очень схематичный пример.
Допустим, у нас есть компания — производитель автобусов, в которой наличествуют отделы «разработки и производства» и отдел «технического обслуживания», который осуществляет гарантийное обслуживание проданных автобусов. Есть также вторая компания — потребитель, которая купила один из автобусов, чтобы возить своих сотрудников по некому маршруту внутри кампуса/офисного городка. Так вот, в данном конкретном примере мы получаем следующую картину:
Но это хорошо видно на примере с автобусами, но, почему-то, совсем не очевидно в случае IT.
Давайте попробуем разобраться несколько подробнее.
Формально, службы поддержки и сопровождения программных продуктов находятся на стыке направлений ITSM и CRM. И, как это обычно бывает, у нескольких нянек — дитя без присмотра. При этом, с организацией работ администраторов, выдачи и обслуживания IT оборудования – сложностей зачастую не возникает. Получается некий парадокс, вроде бы и там и тут – IT сфера, и там и тут вполне себе грамотные сотрудники и руководители, но в одном случае все в принципе работает вполне себе даже приемлемо, а в другом – как получится. В чем же разница? Почему мы можем обеспечить поддержку оборудования, ОС, вебсервисов, но при этом с поддержкой бизнес-платформ, таких как учетные системы, системы анализа данных, документооборота, управления бизнес-процессов и прочих – зачастую возникают сложности? В чем может быть загвоздка?
Возьмем другой пример, чуть более приближенный к нашей тематике. Итак, у нас есть компания, которая использует некую «стандартную» конфигурацию учетной системы (неважно какой). Поскольку конфигурация стандартная, то компания не имеет в штате разработчиков для внесения исправлений и изменений в используемую систему. Вполне очевидно, что у пользователей возникают разного рода проблемы и вопросы с применением данной системы. Пользователи, это люди несколько далекие от IT («продажники», бухгалтера, начальники и т.д.) и вникать в детали, как оно собственно работает внутри, им нелегко, да и просто некогда.
На этом моменте давайте остановимся чуть подробнее. Итак, у нас это чистая компания – потребитель. То есть сама компания не производит продукт, которым пользуется, а покупает его на стороне. В этом случае, если нет своей «службы поддержки», то конечные пользователи сами пытаются решать возникающие проблемы. В результате теряется много времени, нервов, начинаются чудеса с данными и т.д. В общем, все как всегда.
И руководитель вновь организуемой «службы поддержки», задает себе два главных вопроса:
— какова цель работы «службы поддержки»? Для кого они работают?
— каким должен быть идеальный сотрудник этой службы?
С ответами сложностей быть не должно. Данная служба создается, чтобы взять на себя работу с производителем/поставщиком и избавить конечных пользователей от ненужных им технических манипуляций. То есть заказчиком (потребителем) результатов работы «службы поддержки» являются конечные пользователи.
Едем дальше, а как же оценивать работу сотрудников этой службы? Скоростью решения проблемы? Скорее нет, чем да, поскольку они не могут, да и не должны лезть вовнутрь конфигурации или платформы учетной системы. Поэтому немного утрируем, и получается, что их задачи тоже вполне очевидны — удостовериться, что:
Итак, на текущий момент мы, в общем, двигаемся в верном направлении. Примерно об этом нам говорят книжки из ITIL, множество прочитанных статей, да и логика тоже это подтверждает. И на самом деле, тут откровений нет. Но они будут дальше.
Итак, у нашего руководителя все получилось хорошо, все счастливы, и уже компания – производитель этой самой учетной системы, пригласила его/ее наладить их «службу поддержки». И вот тут начинаются чудеса. На новом месте он/она вновь задается теми же самыми вопросами, что и ранее:
— какова цель работы «службы поддержки»? Для кого они работают?
— каким должен быть идеальный сотрудник этой службы?
И вот в этом случае, ответы уже будут очень сильно отличаться от того, что мы видели ранее. Итак, мы имеем дело с компанией – производителем. То есть компания имеет штат разработчиков, которые придумывают и воплощают в жизнь свои идеи в некоем продукте, которым пользуются другие компании. И получается, что при отсутствии «службы поддержки», именно разработчики вынуждены отвлекаться от своей основной работы и заниматься пустяковыми (по их мнению) проблемами, в то время, когда «вселенная нуждается в идеальной учетной системе». 
Иными словами, в данном случае, заказчиком услуг «службы поддержки» являются уже не пользователи, а разработчики. И им уже не нужно требовать, чтобы сотрудник отдела что-то там собирал и отдавал им, тут уже необходимо, чтобы эта служба была в состоянии сама решать большинство проблем. Понимаете разницу?
Получается, что при похожем названии, и вроде бы, как одной функции, у отделов совершенно разные требования к их работе. То есть мы имеем два полюса, два чистых и совершенно противоположных подхода к организации работы «службы поддержки». К большему сожалению, эту разницу мало кто видит, а из тех, кто видит, ее часто игнорируют.
Ведь тот же ITIL эту разницу не обозначает и подавляющее большинство интерпретаций основаны именно на подходе для компаний – потребителей. По этой причине я предпочитаю вариант «службы поддержки» для компаний – производителей именовать «техническая поддержка», чтобы отличать от «службы поддержки пользователей», «отдела сопровождения ПО» и прочих «service desk» в компаниях-потребителях.
Резюмируя, мы получаем следующую картину:
Очевидно, что в реальной жизни нам приходится использовать некий компромисс и смешение этих двух противоположностей, но, тем не менее, зная эти «ингредиенты» руководитель уже сможет подготовить свой собственный рецепт, наиболее полно соответствующий условиям конкретной организации, выстроить соответствующие процессы и подготовить SLA, которые будет отвечать интересам всех заинтересованных сторон (включая отдел поддержки/сопровождения).
К чему обычно приходим
Ну и в качестве бонуса, небольшой список неудачных подходов к организации работы службы поддержки.
С другой же стороны, когда к Вам обращается некий «Федор», это далеко не всегда комфортно, поскольку Вы не знаете этого человека, его никто не представлял, чтобы разводить «панибратство» и вообще, как Вы можете быть уверены, что «Федор» это его реальное имя?
Поэтому всегда, при любом ответе компании в подписи должны быть, как минимум, фамилия и имя человека, отправившего сообщение. Даже если данное письмо/сообщение идет от коллектива в целом. Кроме того, если обращение начал обрабатывать один сотрудник, то он и ведет работу по данному конкретному инциденту до конца, без постоянного переключения участников со стороны компании. Смена допускается лишь при необходимости (например, заболел, или перегружен более важными запросами, или же работу «подхватили» сотрудники «технической поддержки») и новый ответственный сотрудник всегда должен представиться и указать будет ли он до конца работать по заявке, или же только временно ее обрабатывает. Вообще, все это очень странно и создается впечатление, что основами административной работы многие менеджеры просто не владеют.
Но чаще всего создание CMDB просто игнорируют, храня информацию в разрозненных файликах, письмах и даже на бумажках. Сложность в том, что критериев выбора конфигурационных/изменяемых параметров не приводится в руководствах ITIL (например, в той же третьей книге «ITIL Service Transition»). Есть только классификация и некие примеры, взятые для случаев администраторской работы. Поэтому от квалификации, опыта и чутья архитектора внедрения ITIL — зависит буквально все.
Надеюсь, это хоть немного пролило свет на то, что «знание ITIL/ITSM» само по себе ничего не гарантирует и требует в первую очередь понимания, что есть поддержка, для чего она нужна в данном конкретном случае и что является признаком успешности ее работы.
Кроме этого, анализ работы служб поддержки позволяют оценить и качество работ внешних поставщиков услуг и/или отдела разработки. Эту часть анализа деятельности зачастую вообще игнорируют.
На этом у меня все. Ваши комментарии и аргументированные замечания – всячески приветствуются.
Всем удачи и успехов.
1. «Мерзлый» песик — отсюда
2. «Суровый» пес отсюда
3. Call-центр: отсюда
4. Автобусный сервис отсюда