Миллион на техподдержке. Правильная организация процессов внутри отдела

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

Пара слов о компании. ГК «Гильдия консультантов»:

• Мы – обычная региональная франчайзи из Тулы. Поддерживаем конфигурации 1С, CRM-системы, еcommerce-проекты и, самое главное, – интеграции между ними.

• Сейчас у нас две тысячи активных договоров.

• В 2021 году компании исполнилось 20 лет. Мы очень давно на рынке: начинали с 1С, сейчас расширились на все остальное.

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

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

2. Мы отгружаем часы. Для нас это основа производства. Мы оперируем понятием «стоимость часа», но это понятие входит в некий дисбаланс с термином «тариф». Об этом я чуть позже скажу подробнее.

3. Решения, о которых я буду рассказывать – это не таблетка или панацея. Они появились в условиях, когда не хватало ресурсов: финансовых, кадровых, временных.

4. Важна система ServiceDesk – место, где будут собираться все обращения. Мы сейчас не будем говорить о программном обеспечении, но вы должны понимать, что ServiceDesk должен быть.

Изначально система ServiceDesk у нас была на базе 1С, но мы от нее ушли. Нам захотелось вкусных сладких интерфейсов, где клиенты могли бы все лучше делать.

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

Плюсы техподдержки

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

• Модель Time&Materials. Это значит, что нам платят не за результат, а за время. На мой взгляд, это самая вкусная методология. Она не бесспорная, но ее можно внедрить только в техподдержке. Она самая, скажем так, продаваемая, потому что, когда нам платят за время, все счастливы и довольны.

• Отчетный период. Мы получаем от клиента платежи на три месяца. При этом отчетный период, в подавляющем числе случаев – это один месяц. Из-за того, что у нас постоплата, мы первый месяц, условно, зарабатываем миллион. Во второй, собираем этот миллион (потому что отгрузить часы и собрать деньги за часы – две разные задачи). И на третий месяц – живем на заработанное.

• Планирование ресурсов. В техподдержке можно планировать ресурсы на небольшой срок, например, на спринт, – это удобно и меньше риска ошибиться.

• Рост LTV (Lifetime Value). Ценность каждого клиента постоянно увеличивается – накапливается сумма всех полученных от него денег (между первым и последним платежом). Для сервисов по подписке LTV – это очень важный показатель. Даже если в вашей экономике LTV никак не используется, при техподдержке LTV хорошо растет.

Тикетогенерация

Вернемся к моменту, который я недорассказал – про «стоимость часа» и тарифы.

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

• к подпискам все привыкли, по сути, платежи за техподдержку – это та же подписка;

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

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

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

• письма;

• телефонные звонки;

• чаты;

• социальные сети;

• саппорт.

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

Как этого достичь?

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

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

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

Почему деньги – самое важное в техподдержке

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

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

Для наших клиентов мы ввели сущность «баланс», который он видит в режиме онлайн.

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

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

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

• 20 минут я делал это;

• час я делал это;

• 5 часов я делал это.

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

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

Как увеличить стоимость часа

Прежде чем мы перейдем к самому вкусному, немного расскажу про увеличение стоимости часа.

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

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

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

• Рынок 1С очень многообразный и заходит на другие сферы. Так как 1С везде в нашей экономике, то за задачи берутся слишком разные компании.

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

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

На стоимость часа глобально влияет позиционирование.

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

Там стоимость стрижки – 1500 рублей. Почему так? Потому что они говорят: «Мы не стрижем – у нас клуб. К нам приходят мужики. Мы им нальем, они поиграют в приставку, мы с ними пообщаемся. А еще мы их подстрижем. И за это они заплатят 1500 рублей».

Ровно такая же услуга в парикмахерской «У Светланы» – стоит 350 рублей.

Чтобы себя правильно позиционировать на рынке, нужно УТП – уникальное торговое предложение.

Яркий пример – на слайде изображен плакат Владимира Маяковского, изображающий УТП для ГУМа. Он сделал упор на то, что людям, которые приезжают в Москву, не нужно ходить по всему городу, а лучше сразу идти в ГУМ, и все там будет.

Как мы нашли свое позиционирование, и какое у нас УТП.

Мы нашли боль у клиента – интеграция 1С с интернет-магазинами и CRM-системами.

Мы сказали: «Мы одинаково хорошо понимаем в 1С и в e-commerce. У нас не будет никакого пинг-понга – мы не отфутболим проблему к 1С-никам или к веб-программистам. Мы сами лучше всех разбираемся в интеграции с двух сторон».

Это очень сильно нам помогло найти себя на рынке.

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

На слайде изображена методика HADI-цикла.

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

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

Это было небольшое лирическое отступление о том, что стоимость часа важно повышать через позиционирование.

Проблемы трекинга и способы решения

Вернемся к техподдержке и поговорим про трекинг.

• У руководителей есть моменты, когда при Time&Material не все время идет в оплату. В нашей компании придумали, что полезный рабочий день у программиста не восемь часов, а шесть. Так решили, потому что нужно переключиться с задачи на задачу, попить кофе, пообщаться с коллегами, сходить к кулеру. Все это отнимает время. Мы решили, что для мелких задач достаточно 6 часов, а для одной большой задачи – 7 часов.

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

• С моей точки зрения, руководитель платит программисту за время, а не за то, что его чуть-чуть «взяли в аренду».

• Соответственно, если программист затрекал всего 3 часа, это очень сильно влияет на экономику.

Возьмем программиста, который может закрыть 30 часов в неделю.

Допустим, у нас есть крутая задача – как раз на 30 часов. Итого: при стоимости часа в 2000 рублей программист может нам принести 60 000 рублей.

У этого программиста есть тимлид. Без помощи тимлида программисту не продвинуться – он будет делать задачу дольше. Этот тимлид решает тратить на программиста по 20 минут в день – чтобы что-то проверить, куда-то направить и тому подобное. По итогам недели у тимлида на работу с этим программистом уже набегает час.

Соответственно, у нас оплата 60 000 рублей, а фактически затраченное время – 31 час. Стоимость часа падает до 1935 рублей.

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

Он 3 часа потратил на изучение и эти три часа затрекал бесплатно. Значит мы получим уже не 30 часов в оплату, а 27. А фактических остается 31 час. Итого: стоимость часа падает до 1740 рублей.

Если это новый клиент, нам, чтобы начать реализацию, нужно раскатать инфраструктуру для стенда и выделить копии отдельным программистам. Все это – некие инфраструктурные задачи, которые, допустим, занимают час. Значит потрачено уже 32 фактических часа. Итого: стоимость падает до 1690 рублей.

Задача выполнена. Сотрудник хочет все проверить и проводит пользовательское тестирование, которое занимает еще один час. Мы называем это проведением контрольного примера. В принципе, его можно поставить в оплату. У нас получается 28 часов в оплату, а потрачено 33 фактических часа. Итого: стоимость часа – 1690 рублей.

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

С одной стороны, этот пример утрированный и гиперболизированный, но с другой стороны – это реальная жизнь.

На этом примере из стоимости часа в 2000 рублей за неделю в обычной жизни потерялись 16% стоимости часа. Мы кичимся, что у нас час стоит 2000, а на самом деле мы работаем по стоимости 1680 рублей в час.

Это сильно влияет на экономику – особенно, если мы прибыль с одного-двух программистов разобьем на весь отдел.

Чтобы этого не допустить, нужно трекать все, что только можно:

• часы в оплату;

• помощь друг другу;

• изучение функциональности;

• инфраструктурные задачи;

• работу по реквестам;

• закрытие бесплатных часов, потому что ошиблись в проектировании или реализации трекать с пометкой – «Мы ошиблись, наш косяк»;

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

Трекать нужно ради денег. На конференции очень много говорили о нематериальной мотивации, но я про другое – я про деньги.

Трекать нужно, чтобы:

• вы могли видеть и непосредственно влиять на ежедневную и еженедельную выручку;

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

Чтобы грамотно управлять стоимостью часа, вы должны:

• размазывать бесплатные задачи по платным – тогда ничего не сломается, и вы не выйдете за определенный вами процент;

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

Что получает руководитель от трекинга

С точки зрения бизнеса руководитель с помощью трекинга может понять:

• сколько денег зарабатывает сотрудник за один день;

• сколько зарабатывает весь отдел за отчетный период;

• понимание, почему не выполняется план;

• появляется четкое планирование;

• четкое понимание того, как достичь поставленных финансовых показателей;

• видение картины, какие задачи тянут вниз;

• четкое видение по отчетам и цифрам, как и где недорабатывает сотрудник;

• какова на самом деле стоимость часа компании – хотя бы чтобы эту экономику использовать внутри.

Но этого мало. С профессиональной точки зрения:

• руководитель видит, насколько быстро сотрудник изучает новую функциональность;

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

• понимание, насколько нужно тратить времени тимлиду на молодых (его время – самое дорогое, и его тоже нужно планировать);

• понимание того, насколько соответствует разработка протоколам, и пришлось ли сотруднику переделывать эту работу – сразу видно, что сотрудник сначала сделал задачу, а потом затрекал ровно такое же количество часов не в оплату, переделывая эту задачу;

• понимание того, куда уходит время у сотрудника с точки зрения задач.

Зачем нужен SLA

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

Сервис должен быть для клиента предсказуемым, поэтому SLA нужен, чтобы росла лояльность и LTV. Значит нам нужно что-то задекларировать и выдерживать задекларированный минимум.

Стандартные моменты.

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

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

• Время ответа. Не в продакшене, но при консультации можно поставить примерное время ответа. Например, «на консультацию мы потратим не более часа и дадим вам ответ».

Мы рекомендуем обратить внимание на настройку помощников, чтобы они отлавливали статусы тикета.

Помощники могут напоминать:

• что статус «В работе», а по задаче давно не было транзакций – очень часто встречается, когда задача стоит «В работе», а сотрудник ею не занимается;

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

• о том, что последним в тикет писал клиент – т.е. ему нужно дать обратную связь;

• о неверном статусе;

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

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

SLA нужен ради денег:

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

2. Предсказуемость = лояльность.

3. Больше часов в оплату.

Почему важны загрузка производства и финансовое планирование

Немного расскажу про загрузку производства и финансовое планирование. Для нас это два разных вида планирования.

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

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

В финансовом планировании все просто – должно быть максимальное количество часов в оплату.

Лучше выбирать короткий спринт – неделю.

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

Если у нас план – закрыть 60 часов в день на 10 сотрудников.

Вычитаем 15% часов в неоплату.

Итого: мы должны зарабатывать 510 000 рублей в неделю.

Ведение базы знаний в ServiceDesk

База знаний особенно важна в саппорте, потому что:

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

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

• Все выливается в деньги. Меньше часов трекается в неоплату, и все счастливы.

У базы знаний есть сложности.

1. Базой знаний неудобно пользоваться. Мы пробовали гуглдокс, чаты и еще много чего, но у нас не получалось нормально ее вести.

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

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

Еще в карточке проекта сделали вкладку Wiki.

Задача присваивается какому-то проекту, и в его Wiki отображаются все задачи, которые были по этому проекту.

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

Пусть это не крутая структурированная документация, но это заработало.

Тестирование. Как организовать без QA

Конечно, лучше иметь для тестирования отдельного специалиста. Но часто его нет:

• Потому что иногда очень сложно придумать мотивацию для привлечения такого человека в команду.

• К тому же тестирование всегда сложно продавать. Клиент может сказать: «А что, я вам должен за тестирование платить? Вы же профессионалы. Я вам плачу, чтобы вы сразу все сделали хорошо».

• Кроме этого, исторически сложилось, что в большинстве команд 1С, QA – так себе тема.

Мы придумали, как решить проблемы с тестированием:

• добавили два дополнительных статуса к задаче: «требуется тестирование» и «на тестировании»;

• определили, что тест-кейс пишет сам разработчик – сделал маленькую задачку и описал, как ее выполнить.

• Из-за этого 90% глупых ошибок ушли, потому что второй программист подчищает за первым.

Для чего все это на самом деле

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

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

Какие встречаются сложности:

• клиент расстраивается, когда видит, как баланс моментально уходит в отрицательную сторону;

• роль менеджера или руководителя ТП становится крайне важна, чтобы все разруливать. Он должен быть компетентен в технических вопросах;

• выстраивание системы доверия занимает много времени.

Выбор системы для организации ServiceDesk

Есть куча вариантов создания ServiceDesk:

• конфигурация 1С;

• корпоративный портал;

• облачные сервисы и так далее.

Сравнивать их – это отдельный доклад.

• Если у вас до сих пор нет ServiceDesk, начните с базовых возможностей – сделайте место, где будет генерироваться абсолютно все.

• Если вы уже прошли этот период, выстраивайте хороший сервис, внедряйте SLA и трекинг, начинайте строить экономику компании.

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

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

Попробуйте сделать в качестве эксперимента ServiceDesk в Гуглдоксе. Может вам это будет не нужно.

Мы сначала себе распланировали много всего. Потом ушли в гуглдокс, поработали в нем полгода и поняли, какое что нам нужно. Так мы сэкономили 200 часов разработки.

Договор на техподдержку

В договоре на техподдержку важны:

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

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

• Указать стоимость часа и оплату.

• Порядок приемки.

• Регламент техподдержки также должен быть в договоре прописан.

Бюрократия 2.0

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

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

Т.е. в результате мы пришли к такой «Бюрократии 2.0». Но я считаю, в этом наша сила, потому что теперь я могу этим управлять.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2021 Post-Apocalypse.