Покупателям сложных программных продуктов — таких, как биллинг — почти всегда требуется техподдержка. Мало кто может справиться со всеми возможными проблемами без помощи разработчиков. А это значит, что в таких случаях техподдержку можно делать платной — но для этого нужно обеспечить высокий уровень качества предлагаемой услуги и корректно учитывать время, за которое берется плата. Сегодня мы поговорим о том, как этого можно добиться.
Нужно наладить качественный учет оплачиваемого времени
Очевидно, что даже в случае платной поддержки могут быть ситуации, в которых брать плату с клиента не стоит — например, исправление багов, возникших на этапе разработки или внедрения продукта. Если система работает некорректно из-за ошибки, то покупатель продукта не должен платить за ее исправление.
Это означает, что есть два типа времени — оплачиваемое и неоплачиваемое, и их необходимо корректно определять и учитывать.
Мы в «Латере» используем в системе обработки заявок для корректного логирования времени различные теги. К примеру, если сотрудник устраняет какой-то баг, то помечает это время тегом DEVBUG («баг разработки»). Если же ему для решения проблемы нужно, например, изучить документацию или попросить помощи у коллег, то здесь применяется тег STUDY. В случае недостатка знаний у сотрудника, клиент не платит за его обучение. Однако, если для решения проблемы нужны какие-то узкоспециализированные знания, не входящие в стандартную норму, потраченное на это время уже будет залогировано, как оплачиваемое.
Необходимо внимательно следить за тем, чтобы работники не забывали корректно отмечать потраченное время — если они этого не сделают, то компания просто потеряет возможную прибыль. Источником финансирования сотрудников отдела поддержки является оплаченное время их работы. Это нужно четко донести до команды, что позволит снять возможное недовольство повышенным контролем со стороны начальства.
Важно постоянно повышать уровень удовлетворенности клиентов
В случае бесплатной поддержки компании, обычно, стараются всеми силами снизить свои затраты на нее, и тут уж не до работы по повышению удовлетворенности. Другое дело платная поддержка — здесь клиент всегда должен быть доволен, иначе он не захочет платить.
Это значит, что сбор информации об уровне удовлетворенности — это необходимость. Для этого можно после каждого обращения в службу поддержки предлагать оценить работу ее сотрудников. Мы используем для этого простую систему смайлов — зеленый, желтый и красный. Простота этой системы гарантирует большое количество отзывов — клик на смайл не требует особых усилий.
Необходимо иметь внутренний стандарт, описывающий удовлетворительное количество зеленых смайлов. Например, у нас из 100 последних оценок как минимум 96 должны приходиться на зеленые смайлики, а остальные — на желтые. Красные смайлы не допускаются вообще, по каждой негативной и даже «не отличной оценке» должны проводиться разборы с получившим ее сотрудником.
Мы не скрываем информацию по удовлетворенности пользователей нашего продукта — она доступна на специальной странице, а сотрудникам техподдержки она видна постоянно на специальном настенном экране.
Сотрудников нужно мотивировать
В случае организации платной поддержки контролировать сотрудников необходимо. Однако для того, чтобы добиваться хороших результатов, этого мало — нельзя забывать и о мотивации работников. Хорошим инструментом для этого является бонусная программа — за выполнение задач сотрудникам можно начислять баллы, которые представляют определенный процент от зарплаты.
В конце месяца заработанные баллы (у нас они называются пойнтами) выплачиваются в виде премии, которая может быть существенной. Конечно, должны быть и штрафные очки, которые из премии, наоборот, вычитаются.
Вот за что наши сотрудники могут получить «пойнты»:
- За зеленый смайл, оставленный клиентом (за желтый или красный — штраф).
- За каждый оплачиваемый (залогированный) час работы по поддержке.
- За быстрое решение срочной заявки.
- Решение проблемы дежурным сотрудником не в основное рабочее время.
- За большое количество времени, потраченное на «обучение» (сбор информации по заявке, изучения нужных для ее решения систем и т.п.) также начисляются штрафы — в итоге у новых сотрудников сразу премия обычно невелика, что мотивирует их быстрее входить в курс дела.
Клиент должен знать, за что он платит
Полная прозрачность помогает предотвратить возможное недопонимание. Клиент должен всегда иметь возможность просмотреть детализацию использованного времени поддержки. Это позволяет видеть, сколько оплаченных часов еще остается и заранее спланировать свои обращения или выделить дополнительный бюджет для оплаты работ после исчерпания лимита.
Мы также автоматически рассылаем сообщения при приближении и после преодоления этого порога. Наличие подробной детализации дает клиентам возможность оспорить то, как именно было «залогировано» время — если их доводы подтверждаются, то время переквалифицируется из оплачиваемого в неоплачиваемое.
Также стоит дать клиентам возможность попытаться решить свои проблемы и без непосредственного обращения в поддержку. К примеру, часто подсказать ответ на вопрос могут другие клиенты, которые уже столкнулись с такой проблемой — так что разработчикам продукта полезно организовать и открытый форум. Общение на форуме не просто помогает решать возникающие вопросы, но и способствует формированию сплоченного сообщества пользователей. Также на нашем форуме клиенты могут оставлять свои предложения по доработкам — это позволяет определить востребованность той или иной «фичи».
Разработчики должны оперативно реагировать на запросы отдела поддержки
Очень часто в разных компаниях отношения между сотрудниками отдела поддержки с разработчиками оставляют желать лучшего — в конце концов, именно программисты и оставленные ими баги часто становятся причиной обращения в поддержку. Решить же проблему окончательно зачастую способны только разработчики, которым «некогда». В итоге сотрудник поддержки оказывается в подвешенном состоянии — клиент недоволен, но решить проблему самостоятельно нельзя.
Чтобы избежать подобных ситуаций мы ввели должность дежурного разработчика, который непосредственно «приставлен» к отделу поддержки. Он общается с его сотрудниками на специальном внутреннем форуме или по другим каналам. Дежурный разработчик занимается срочными доработками, помогает коллегам разобраться в сложных ситуациях — отличить баг от «фичи» не всегда просто —, проясняет плохо документированные моменты и курирует оценку просьб от доработках от клиентов.
Заключение
При работе со сложными системами, к числу которых относится и биллинг, обойтись совсем без проблем невозможно. Однако даже несмотря на то, что у нас техподдержка платная, за последние несколько лет нам удалось добиться серьезного улучшения уровня сервиса и снизить количество времени, которое бесплатно тратится на решение проблем, возникших из-за наших собственных ошибок.
К примеру, среднее время реакции на заявку клиента снизилось с 7,5 рабочих часов до 5, а ответы на комментарии клиента по заявки поступают, в среднем, за 6 рабочих часов — раньше за 11. Время реагирования на критические запросы стабильно держится на уровне 10 минут.
Более чем в два раза сократилось число взаимодействий с клиентом по одной заявке — со среднего показателя в 10,5 взаимодействий до 4,5. Удовлетворенность клиентов выросла с 87% и наличия 4% красных смайлов до 97% (оставшиеся 3% только желтые). Кроме того доля оплачиваемого времени поддержки выросла в 1,5 раза за счёт более эффективного расхода рабочего времени сотрудниками.
