Потери эффективности внутренней техподдержки против внешней
Повсеместно принято считать, что для компании необходимо организовывать внутреннюю техподдержку продукта, так как это:
— легче, чем обращаться к сторонним организациям;
— эффективнее, так как действия своих сотрудников проще отслеживать и люди, преданные компании, обязательно будут работать на износ;
— сотрудник точно будет знать продукт на все 100%, будет технически подкован, все вопросы будет решать самостоятельно и не нужно будет привлекать разработчиков к процессу;
— внутренняя поддержка будет быстро реагировать на изменения, быстро отвечать пользователю.
Сейчас мы с вами исследуем вопрос и проверим что из этого является правдой, а что мифом. По началу, может показаться, что такая поддержка будет обладать высочайшим уровнем экспертности и решать возникающие проблемы в максимально сжатые сроки. Но так ли это на самом деле?
документация и ответственность
Основными инструментами технической поддержки являются даже не программы администрирования и языки программирования, а знание ответственных лиц продукта, к каким разработчикам своевременно нужно обратится в случае той или иной проблемы, наличие задокументированных бизнес-процессов, происходящих в системе, схемы этих процессов, дополнительная документация, описание проекта, зафиксированные в базе знаний найденные решения вопросов пользователей и инструкции, регламент обслуживания, обозначение критичности инцидентов и сроки реагирования.
При создании собственной технической поддержки, когда процессы еще не налажены, с документацией возникают сложности. Все вопросы безостановочно эскалируются на разработчиков и вопросы решаются очень долго. Может ли быть легче сформировать компетентную группу сотрудников, которые умеют:
— правильно, без удара по репутации компании, ответить пользователю о длительных сроках решения вопроса;
— безэмоционально и спокойно ответить на негативную реакцию клиентов на сбой в системе;
— проверить логи программы и увидеть в них ошибку;
— правильно использовать системы мониторинга и хранения информации;
— быстро искать нужную информацию среди узкоспециализированной по системе;
Обычно в компаниях с внутренней линией поддержки нет жесткого регламента обслуживания. Как правило, эти «соглашения» и «назначения» носят формальный характер в виде устного диалога или переписки в чате. В таких случаях тяжело отслеживать историю обращений пользователя, клиента или сотрудника внутреннего подразделения, найти ответственного при возникновении чрезвычайных ситуаций, отследить изменения по системе, заметить нарушение сроков устранения инцидента. Все это негативно сказывается на использовании системы, усложняет анализ, оценку эффективности внедрения продукта и планирования рисков.
Уровень знаний и навыков
От внутренней поддержки также обычно ожидается высокий уровень вовлеченности в процесс, значимый уровень знаний и технические компетентности в обслуживаемом продукте. Но часто это оборачивается нежеланием разбираться в протекающих внутри системы процессах и эскалацией на группу разработчиков или проектного менеджера, отвлекая их от текущих задач по доработке и улучшению работы системы, с позицией “они же лучше знают и быстрее разберутся в проблеме, зачем мне тратить на это время”.
Такие сотрудники не вникают в суть проблемы конечного пользователя. Им проще подойти в соседний отдел или кабинет и задать вопрос, чтобы получить уже готовый ответ, даже если этим самым будут отвлекаться другие сотрудники. Принимая данное решение, они не учитывают, что срок ответа для пользователя может увеличиться вплоть до нескольких недель. Конечно всё зависит от нагрузки сотрудников, на которых эскалируется задача, они действительно могут найти оптимальное решение в достаточно короткие сроки, которое в последствии будет является постоянным решением проблемы пользователя. Но время разработчиков очень ценно для улучшения работы продукта, это время лучше посвятить более приоритетным задачам.
Наиболее ценным является специалист технической поддержки имеющий более высокую квалификацию и опыт в решении такого рода вопросов. Потратив немного больше времени на анализ вопроса, срок предоставления ответа пользователю и решению его вопроса сокращается до нескольких минут.
Такая оперативность куда ценнее для пользователя и вызывает его лояльность к бренду, чем длительное ожидание не всегда понятного штатному пользователю ответа от разработчиков.
боль разработчика
Также очень важно как относятся сами разработчики к устранению багов системы, к восстановлению работы серверов или задачам на улучшение процессов. Девопсы очень не любят чинить процессы и отвлекаться на доработку системы. Они накапливаются в стопке задач и давят на сотрудника тяжелым грузом ответственности.
Последствия постоянного отрыва от работы и отсутствие рабочего настроя часто проявляется в психических расстройствах вплоть до депрессии, а это напрямую влияет на скорость разработки и качество продукта.
При наличии группы сотрудников, обрабатывающих запросы до эскалации и фиксирующих успешные решения по тем или иным задачам, уровень отвлечения разработчиков от своей основной деятельности сильно падает и освобождает время на важные вопросы.
Внешняя поддержка, чем она отличается
Внешняя техническая поддержка может выполнять примерно те же функции, что и внутренняя. За исключением того, что за каждую отработанную заявку и ошибку они несут ответственность, часто не только репутационную, но и материальную. Эта ответственность обычно прописывается в соглашении SLA. Там же прописываются различные критерии качества и ответственные, уровни эскалации и сроки решения задачи.
Иногда говорят, что внешняя служба поддержки не отличается высоким уровнем качества, и может похвастаться лишь высокой скоростью реакции на инциденты. Возможно, так было раньше, но в последнее время службу поддержки строят вокруг команды профессионалов, которые погружаются в продукт и проблему пользователя, предоставляя отличный уровень сервиса. К тому же, стоимость внешней линии поддержки может обходиться дешевле, чем обслуживание и содержание команды внутри компании.