Техническая поддержка. Что это такое? Как ее организовать? Как не терять заявки? Как быть лучше конкурентов?

Техническая поддержка. Что это такое? Как ее организовать? Как не терять заявки? Как быть лучше конкурентов?

С чего все начинается

Итак, традиционно, начнем с основ. Попробуем ответить на вопрос:

что есть служба поддержки и для чего она нужна?

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

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

Call-центр

  • пользователей – это пассажиры автобуса
  • «службу поддержки» — это диспетчер, или справочная, и кондукторы в самом автобусе,

которые позволяют пассажирам решать возникающие сложности.

А в компании – производителе мы имеем:

  • разработчиков – это отдел «разработки и производства»
  • и тоже, «службу поддержки» – в данном случае, это уже отдел «технического обслуживания»


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

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

Формально, службы поддержки и сопровождения программных продуктов находятся на стыке направлений ITSM и CRM. И, как это обычно бывает, у нескольких нянек — дитя без присмотра. При этом, с организацией работ администраторов, выдачи и обслуживания IT оборудования – сложностей зачастую не возникает.

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

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

Вполне очевидно, что у пользователей возникают разного рода проблемы и вопросы с применением данной системы. Пользователи, это люди несколько далекие от IT («продажники», бухгалтера, начальники и т.д.) и вникать в детали, как оно собственно работает внутри, им нелегко, да и просто некогда.

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

И руководитель вновь организуемой «службы поддержки», задает себе два главных вопроса:

— какова цель работы «службы поддержки»? Для кого они работают?
— каким должен быть идеальный сотрудник этой службы?

С ответами сложностей быть не должно. Данная служба создается, чтобы взять на себя работу с производителем/поставщиком и избавить конечных пользователей от ненужных им технических манипуляций. То есть заказчиком (потребителем) результатов работы «службы поддержки» являются конечные пользователи.

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

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


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

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

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

— какова цель работы «службы поддержки»? Для кого они работают?
— каким должен быть идеальный сотрудник этой службы?

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

ремонт автобусов

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

сама решать

большинство проблем. Понимаете разницу?

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

Ведь тот же ITIL эту разницу не обозначает и подавляющее большинство интерпретаций основаны именно на подходе для компаний – потребителей. По этой причине я предпочитаю вариант «службы поддержки» для компаний – производителей именовать «техническая поддержка», чтобы отличать от «службы поддержки пользователей», «отдела сопровождения ПО» и прочих «service desk» в компаниях-потребителях.Резюмируя, мы получаем следующую картину:

Служба поддержки пользователей

Служба технической поддержки

Заказчик (потребитель услуг отдела)

Конечные пользователи

Отдел разработки/тестирования

Задачи сотрудника

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

Требования к сотруднику

  • хорошо знать предметную область и говорить с пользователями на одном языке;
  • хорошо знать терминологию и функционал системы;
  • быть психологически устойчивым и доброжелательным;
  • не бояться задавать вопросы;
  • уметь объяснять;
  • хорошо знать терминологию и функционал системы;
  • желательно иметь представление о предметной области/бизнесе заказчиков;
  • иметь опыт и знания в разработке ПО и говорить с разработчиками на одном языке;
  • не бояться задавать вопросы;
  • уметь объяснять;
  • иметь желание и настойчивость докапываться до сути проблем;

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

Аутсорсинг технической поддержки

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

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

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

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

В то же время аутсорсинг услуг техподдержки может приводить к мошенничеству[en]: крупная компания удалённой технической поддержки iYogi стала фигурантом нескольких судебных исков.

Заказ материалов, доставка и хранение

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

Техническая поддержка. Что это такое? Как ее организовать? Как не терять заявки? Как быть лучше конкурентов?
Источник

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

Используемый сленг

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

Например, траблы (от англ. trouble – беда) или трабл тикеты (также известны как тт или ттшка; от англ. trouble ticket) — заявки и «проблемы» как структурные единицы, в форме которых, как правило, происходит работа над возникшими у клиента проблемами и их учёт, как инцидентов.

Траблшутинг (англ. troubleshooting) — устранение неполадок, работа над траблом.

К чему обычно приходим

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

  1. Использование чат-ботов. Последнее время эта тенденция набирает силу и многим кажется, что это отличный способ сэкономить на количестве сотрудников. При этом никто даже не задумывается о том, с какой целью люди обращаются в отдел поддержки и сопровождения. Так вот, чат-боты и прочие поисковые возможности строго необходимы, когда пользователь не может (при плохо структурированной или сложной и запутанной организации так называемой «базы знаний») или не хочет (в силу чрезмерной занятости или лени) искать информацию самостоятельно. Иными словами, только в случае, если пользователь не понимает или не может найти нужную информацию в онлайн-документации достаточно быстро, то ему в этом поможет расширенное средство поиска или чат-бот. Никаких нестандартных или технических проблем чат-бот касаться не должен. Этого, к сожалению, мало кто понимает. Конечно, есть огромное желание заставить пользователей, наконец, пользоваться документацией и статьями, размещенными на соответствующем портале, а не обращаться к сотрудникам отдела по уже расписанным и простым вопросам. Однако правильнее и проще это решается административными методами, а не попыткой все ухудшить. И второй момент, подключение службы поддержки на помощь «по каждому чиху» пользователям не самое коммерчески выгодное решение. С одной стороны, компания берет на себя ответственность за предоставляемые решения, а с другой – это ни как не компенсируется. Иными словами, такой подход отбирает хлеб у отделов внедрения/professional service.
  2. Экономия на сотрудниках. Очень популярно разделение сотрудников по квалификациям на уровни поддержки, и набор «самых тупых» (то есть самых дешевых) на первые линии поддержки. Хотя изначально подразумевалось, что деление на уровни поддержки носит функциональный а не квалификационный характер. Получается как вариант предыдущего пункта с чат-ботами. Управляющий персонал просто не в состоянии правильно организовать взаимодействие сотрудников отдела с пользователями, и пытается решить проблемы в лоб – набором большего количество сотрудников за цену, которая имеется в распоряжении. В результате качество обслуживание просто падает, и, к полной неожиданности менеджеров, нагрузка на «квалифицированных» сотрудников только возрастает.
    Я уже молчу про специальное обучение сотрудников поддержки.
  3. Использование телефона как основного способа обращения за поддержкой. Вообще, довольно странно видеть, что зачастую при организации отделов поддержки/сопровождения отдается предпочтение созданию call-центров. Если мы говорим про поддержку IT систем, то один телефонный звонок требует примерно столько же ресурсов, сколько обработка 2-3 инцидентов, поданных через портал, форум или email. Звонки иногда нужны и важны, но далеко не всегда такой дорогой (для отдела) вид коммуникации рационален и удобен именно с точки зрения организации поддержки пользователей и/или заказчиков. Даже если не вдаваться в подробности мониторинга качества продукта и/или услуг, организации комфортной коммуникации с пользователями/заказчиком, то даже вопросы доступности и распространения опыта и знаний внутри коллектива, при телефонных коммуникациях, требуют дополнительных усилий и затрат.
  4. Использование службы поддержки в роли секретариата. Иными словами, когда первая линия поддержки играет роль своего рода отдела диспетчеризации и направляет пользователей к нужным сотрудникам, в зависимости от имеющихся вопросов и возникших проблем. На самом деле это тревожный «звоночек», что в компании «что-то пошло не так». Служба поддержки хоть и является составной частью CRM (Customer Relationship Management) — системы управления взаимоотношениями с заказчиком, но является именно ее частью, а не ее подменой. Поэтому, когда заказчик обращается в службу поддержки с проблемой, что у него закончился период действия лицензии на продукт, то это значит что аббревиатура CRM в компании для галочки, а профильные отделы (в данном случае, отдел продаж) занимаются чем угодно, кроме своей прямой работы. И поэтому сотрудники поддержки/сопровождения будут работать «передастами» между заказчиком с одной стороны и коммерческим отделом, отделом лицензирования, fulfillment департаментом – с другой.
  5. Имитация «персонального» сопровождения, когда сотрудники отделов поддержки подписываются только именем, например «Мария», «Иван» и т.д. Я, конечно, понимаю, что за рубежом это рядовое явления и, с одной стороны, намекает на «теплые дружеские отношения», а с другой — несколько тешит самолюбие западных пользователей (слуги не имели фамилий), но даже там это имеет смысл только в очень редких случаях. В практике IT поддержки это создает только трудности. Простейшая ситуация: в отделе четыре человека носят имя «Алексей» (реальный случай), при этом в силу обстоятельств в офисе присутствует только один из них (второй — в отпуске, третий — заболел, четвертый — в командировке) и возникает проблема по одному из инцидентов, который обслуживался неким «Алексеем». Как положено, тот, кто в офисе, понятия не имеет о чем идет речь. Что делать супервайзеру/лидеру или начальнику отдела, если заказчик ссылается на некие устные рекомендации, полученные от «Алексея»?

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

  6. Создание отделов «Customer Success», «Technical Enablement» и прочих «Fulfillment». Опять же, это мода последнего времени, в основном связанная с восторгом от «Agile» методов ведения разработки и является попыткой наладить обратную связь, что называется, «в лоб». К сожалению, в реальности это обычно является показателем того, что потерпев неудачу в организации нормальной работы как отделов внедрения, обучения, сопровождения/поддержки пользователей в частности, так и во внедрении CRM методов – вообще, люди начали лепить рядом с кое-как уже работающими отделами, новую дублирующую службу. Увы, довольно часто с тем же успехом.
  7. «Карго-культ» ITIL/ITSM. По факту — это самая большая проблема организации работы служб поддержки. Артефакты фреймворка требуют достаточно глубокого анализа перед их внедрением и четкого понимания, что мы делаем, ради чего, как и почему именно так. Для примера, возьмем CMDB – базу данных конфигурации/настроек и истории их изменений. Рассмотрим простой вопрос: какую информацию/атрибуты и их изменения нам нужны в случае, если мы осуществляем поддержку некой бизнес-платформы (допустим, учетной системы)? Есть соблазн туда добавить все, что только можно, но для компаний уровня «1С», с десятками тысяч заказчиков – это превратит систему в могильник никому ненужных деталей.

    Но чаще всего создание CMDB просто игнорируют, храня информацию в разрозненных файликах, письмах и даже на бумажках. Сложность в том, что критериев выбора конфигурационных/изменяемых параметров не приводится в руководствах ITIL (например, в той же третьей книге «ITIL Service Transition»). Есть только классификация и некие примеры, взятые для случаев администраторской работы. Поэтому от квалификации, опыта и чутья архитектора внедрения ITIL — зависит буквально все.

    Надеюсь, это хоть немного пролило свет на то, что «знание ITIL/ITSM» само по себе ничего не гарантирует и требует в первую очередь понимания, что есть поддержка, для чего она нужна в данном конкретном случае и что является признаком успешности ее работы.

  8. «Кривые» KPI. Этот пункт идет «вне конкурса», как и все метрики эффективности вообще. То, что они нужны – теперь уже понимают все. Но вот вопросы: «для чего?» и «какие именно?» – являются уже «вопросами на засыпку» для подавляющего числа управленцев. Так же обстоит дело и в случае оценки эффективности работы отделов поддержки/сопровождения. Простейший пример: как оценить полезность отдельно взятого сотрудника отдела? Количеством обработанных инцидентов? Если да, то значит ли это, что 100 решенных проблем за неделю лучше, чем 10? В реальной жизни – далеко не значит. Эти 10 инцидентов могут быть настолько сложными и важными, а та сотня – просто самыми легкими, что сравнивать в лоб количества – просто бессмысленно. К огорчению, мало кто вспоминает, что сутью KPI является численная характеристика для рутинных, повторяющихся и однотипных работ/процессов. Поэтому в числах отобразить вклад сотрудников поддержки не так уж и легко, как кажется на первый взгляд и он будет выражаться некой интегральной метрикой.

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

Какие еще вопросы волнуют компании, когда они рассматривают вариант аутсорсинга

Возможное повышение стоимости услуг.

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

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

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

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

Вот такая получается картина.

Считайте, анализируйте, выбирайте. Как организовывать поддержку пользователей – решать вам. И меньше вам «пожаров» в ИТ-инфраструктуре!

Техническая поддержка. Что это такое? Как ее организовать? Как не терять заявки? Как быть лучше конкурентов?
Источник

Краудсорсинг как модель организации технической поддержки

Многие компании и организации, например, такие как Apple[2] и Mozilla[3] предоставляют дискуссионные площадки в интернете пользователям своих продуктов; организация таких форумов позволяет компаниям сократить свои расходы на осуществление технической поддержки[4] без потери выгоды, получаемой от обратной связи. Кроме того, в интернете много независимых веб-сайтов, посвящённых обсуждениям пользователями продуктов и услуг.

Литература

  • Sanchez, Andrew. Technical Support Essentials: Advice to Succeed in Technical Support. — Apress, 2020. — 260 p. — ISBN 1430225475, ISBN 9781430225478.
  • Afable, Jose D. A Beginner’s Guide to Understanding Technical Support. — iUniverse, 2002. — 83 p. — ISBN 0595225748, ISBN 9780595225743.
  • Khandpur, Navtej, Laub, Lori. Delivering world-class technical support. Wiley, 1997. — 322 p. — ISBN 0471155349, ISBN 9780471155348.
  • Czegel, Barbara. Technical support on the Web: designing and maintaining an effective e-support site. — Wiley, 2001. — 376 p.- ISBN 0471391875, ISBN 9780471391876.
  • Rich, Willie. Technical Support 38 Success Secrets — 38 Most Asked Questions on Technical Support — What You Need to Know. — History Ink Books, 2020. — 18 p. — ISBN 1488853878, ISBN 9781488853876

Методология организации службы технической поддержки

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

В описании концепции ITIL, построенной на процессном подходе, Service Desk является единой точкой контакта для пользователей ИТ-Услуг. Это исключение сделано ввиду большой важности подразделения техподдержки и при внедрении практическом использовании современных ИТ-подходов и методик.

Правильно организованная техподдержка (Service Desk) всегда начинается с регистрации всех обращений конечных пользователей, служит единой точкой для общения пользователя с ИТ-службой. Наиболее популярные решения по практической организации техподдержки часто строятся на базе Call-center (простые пользователи иногда их даже отождествляют).

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

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

  • Пользователь — обращается с вопросом в службу поддержки по телефону или с помощью электронной заявки (электронная почта, или специальные сервисы подачи заявок).
  • Оператор (1-я линия поддержки, Call-center) — регистрирует обращение, при возможности помогает пользователю самостоятельно, либо эскалирует (передаёт и контролирует выполнение) заявку на вторую линию поддержки.
  • Вторая линия поддержки — получает заявки от первой линии, работает по ним, при необходимости привлекая к решению проблемы специалистов из смежных отделов (например, системные администраторы, поддержка POS-терминалов, поддержка специального ПО, поддержка специального оборудования, администраторы биллинговой системы и т. д.).

Многоуровневая структура технической поддержки

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

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

Примечания

  1. Technical support for the neighbours (неопр.). BBC News (28 марта 2005). Дата обращения: 6 марта 2008.
  2. Apple Support Communities (неопр.). Apple. Дата обращения: 28 мая 2020.
  3. Mozilla Support (неопр.). Mozilla. Дата обращения: 28 мая 2020.
  4. How to Use Online Forums (неопр.). Inc..
  5. Berkley, SusanCall Centre Trends (неопр.). The Great Voice Company. Дата обращения: 2 мая 2008.
  6. Freeman, ShawnTWT Group (неопр.). TWT Group. Дата обращения: 17 февраля 2020.
  7. 12Walker, Gary. IT Problem Management (Harris Kern’s Enterprise Computing Institute Series) (англ.). — Upper Saddle River: Prentice Hall, 2001. — P. 85—113. — ISBN 0-13-030770-X.
  8. Windley, Phillip J.. Delivering High Availability Services Using a Multi-Tiered Support Model (PDF), Windley’s Technometria. Дата обращения 3 мая 2008.
  9. 12345Kajko-Mattsson, Mira. Problems within front-end support (англ.) // Journal of Software Maintenance and Evolution: Research and Practice (англ.) : journal. — Vol. 16, no. 4/5. — P. 309—329. — doi:10.1002/smr.298.
  10. Leung, Nelson K. Y.; Lau, Sim Kim. Information Technology Help Desk Survey: To Identify the Classification of Simple and Routine Enquiries (англ.) // Journal of Computer Information Systems : journal. — Vol. 47, no. 4. — P. 70—81.

Расчет стоимости поддержки пользователей

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

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

Отметим, что в варианте с собственной ИТ-службой заказчик при увеличении объемов вынужден брать в штат дополнительных специалистов, чтобы укладываться во внутренний SLA. А аутсорсинговая компания имеет возможность увеличить долю (%) занятости специалистов необходимой квалификации.

Техническая поддержка. Что это такое? Как ее организовать? Как не терять заявки? Как быть лучше конкурентов?
Источник

При сравнении своей ИТ-службы и аутсорсинга при объеме до 200 АРМов стоимость поддержки будет выгоднее для собственной ИТ-службы. Но при увеличении штата сотрудников более 400 АРМов стоимость услуг аутсорсинговой компании становится привлекательнее, чем своей ИТ-службы.

Системы техподдержки

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

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

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

Состав условий:

Три варианта поддержки по уровням:

  • Наличие выделенной линии службы приема технических запросов по телефону, email, Service Desk в круглосуточном режиме.
  • Доступ к web-сайту технической поддержки поставщика (контроль обращений, информация о ходе решения, форумы с инженерами).
  • Консультации технических специалистов заказчика по вопросам инсталляции, настройки, технических особенностей, конфигурирования, администрирования.
  • Сессии удаленного подключения для оказания поддержки.
  • Решение технических проблем с учетом моделирования IT-структуры заказчика на виртуальном стенде (по согласованию Сторон).
  • Эскалация инцидентов в службу поддержки производителя, с целью обеспечения работоспособности существующей инфраструктуры. Поддержка от производителя не включена в настоящее предложение.
  • Предоставление статистики по всем обращениям, зарегистрированным в системе Service Desk, по запросу – включено (1 раз в месяц).
  • Решение нештатных ситуаций путем выезда на площадку заказчика.
  • Профилактический визит.
  • Закрепление за заказчиком технических менеджеров компании исполнителя, осуществляющих полный цикл обслуживания в рамках договора – включено.
  • Закрепление за заказчиком технических специалистов компании исполнителя, осуществляющих полный цикл обслуживания в рамках договора.

Способ №3. клиентский портал

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

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

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

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

Способ №4. мобильное приложение для заявителей

Еще один способ обращения в техподдержку — мобильное приложение для клиентов. Такие возможности есть далеко не у всех Help Desk систем. Но наличие мобильного приложения именно для заявителей будет отличным конкурентным преимуществом вашей техподдержки и позволит оказать WOW эффект на клиентов.

Например, в мобильном приложении Okdesk (доступно на всех тарифах как на iOS, так и Android) реализованы все основные функции работы клиента с заявками (от регистрации заявки, прикладывания скриншотов и файлов до комментирования и выставления оценки).

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

WOW фичей мобильного приложения является поддержка голосовой регистрации заявок — клиент может нажать кнопку “Начать запись” и словами описать возникшую проблему. Мобильное приложение также позволяет отправлять клиентам Push-уведомления, не тратя деньги на SMS и не рассылая электронные письма.

О других современных способах регистрации заявок в техподдержку (telegram бот и т.д.) читайте во второй части нашей статьи.

Okdesk —  Help Desk для автоматизации техподдержки. Самые современные способы регистрации заявок.Быстрый старт и результаты без внедрения! Бесплатное тестирование!

Техническая поддержка. чего хочет клиент?

Как это ни банально, но начинать нужно именно с клиентских потребностей. Что нужно вашим клиентам от техподдержки?

  • возможность обратиться в техническую поддержку 24/7;
  • 100% уверенность в том, что их услышали — что обращение по любому вопросу было зафиксировано и на него отреагируют, пусть даже с небольшой временной задержкой;
  • работа через мобильные устройства;
  • простота во взаимодействии (от способов зарегистрировать тикет, до завершения коммуникаций);
  • возможность общаться через удобные каналы;
  • WOW-эффект — чтобы компания предвосхищала их ожидания (по времени реакции, лояльности, человечности и другим параметрам).

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

Техподдержка как инструмент допродаж (upsell)

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

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

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

Управляемые услуги

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

  • круглосуточный мониторинг,
  • круглосуточно-работающие «информационные службы» или «Help Desk»/Service Desk,
  • помощь, оказываемую «на месте» возникновения проблемы, подразумевающую выход технического специалиста, в том случае, когда удалённо проблема не может быть решена,
  • дополнительные услуги, например, резервное копирование и предоставление резервных каналов связи, аварийное восстановление, и др.

Уровень/линия 1

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

После идентификации основных проблем специалист первого уровня поддержки может начать перебирать возможные и предлагать уже заранее известные решения, опираясь на опыт решения типичных проблем.[8] Персонал на этом уровне располагает только основным общим пониманием продукта или услуги и может не обладать необходимыми компетенциями или инструментами, необходимыми для решения более сложных проблем.[9] Тем не менее, целью этой группы поддержки является обработка 70-80 % проблем пользователей, или же обнаружение необходимости эскалировать проблему на более высокий уровень технической поддержки.[9]
В целом ряде индустрий (таких как, банковский сектор, кредитные карты, мобильная телефония и др.), первый уровень осуществляет техническую поддержку посредством обработки звонков, поступающих в call-центр, или по другим каналам коммуникации с клиентами.

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

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

Уровень/линия 2

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

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

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

Уровень/линия 3

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

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

Сейчас ищут техподдержку:  Как обратиться в службу поддержки ВКонтакте
1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...

Оставьте комментарий

Adblock
detector