Мы в «Латере» занимаемся разработкой биллинга для операторов связи (провайдеры проводного и беспроводного интернета, ТВ и телефонии, магистральные и спутниковые провайдеры) уже 8 лет, и за это время поучаствовали более чем в 80 проектах внедрения.

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

Бизнес на поддержке

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

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

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

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

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

За что платят и за что не платят клиенты

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

Также к неоплачиваемому времени относится время, потраченное сотрудниками на собственное обучение (или передачу знаний коллегам). Также плата с клиента не берется, например, за время, потраченное на передачу заявки между сотрудниками отдела поддержки.

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

• DEVBUG — работы по дефекту разработчиков системы. Например: «Устранение проблемы совместно с разработчиками. DEVBUG».
• SUPBUG — работы по дефекту внедрения и техподдержки. Например: «Добавление недостающих сервисов в автозагрузку. SUPBUG».
• STUDY — получение помощи (в свою сторону). Например: «Консультация коллег, чтение документации. STUDY».
• HELP — оказание помощи (в сторону коллег). Например: «Консультация для проработки решения. HELP».
• ORG — решение организационных вопросов с менеджером и перенимание знаний по ранее выполненным работам. Например: «Получение информации у менеджера. ORG».

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

Используемые инструменты

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

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

Ей стал сервис Freshdesk — он похож на Zendesk, но обладает более дружелюбным интерфейсом и довольно активно развивается. Разработчики оперативно реагируют на запросы, в их системе реализован и API-интерфейс (надо признать, он уступает API Zendesk).

Для управления проектами внедрения мы используем ирландский PM-сервис Teamwork, также для некоторых задач до сих пор используется Jira (ведение задач, которые не подходят по назначению ни в одну из других систем управления).

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

Как все устроено

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

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

Информация из хранилища используется для построения графиков загрузки сотрудников (заявки, их состояние, прогресс выполнения задачи). Повышенное внимание мы уделяем анализу того, как изменяются основные показатели.

Контроль

Для платной услуги корректное логирование затраченного времени очень важно.

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



Для сбора обратной связи об удовлетворенности после каждого обращения клиенту предлагается оценить свой опыт взаимодействия со службой поддержки.

Оценками служат смайлики — зеленый, желтый и красный. Клиент выбирает подходящий смайлик одним кликом мышки. Из-за простоты этой системы оценок поступает много, обратная связь надежная. Существует «внутренний SLA», согласно которому из 100 последних оценок как минимум 96 должно приходиться на зеленые смайлы. Информация по удовлетворенности пользователей «Гидры» открыта и доступна на специальной странице, а сотрудникам техподдержки она видна постоянно на специальном настенном экране.

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

Бонусная программа

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

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

Вот за что сотрудник может получить пойнты:

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

Регламенты и работа с клиентами

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

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

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

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

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

Взаимодействие с разработчиками

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

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

Заключение

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

К примеру, среднее время реакции на заявку клиента снизилось с 7,5 рабочих часов до 5, а ответы на комментарии клиента по заявки поступают, в среднем, за 6 рабочих часов — раньше за 11. Время реагирования на критические запросы стабильно держится на уровне 10 минут.

Более чем в два раза сократилось число взаимодействий с клиентом по одной заявке — со среднего показателя в 10,5 взаимодействий до 4,5. Удовлетворенность клиентов выросла с 87% и наличия 4% красных смайлов до 97%. Кроме того доля оплачиваемого времени поддержки выросла в 1,5 раза за счёт более эффективного расхода рабочего времени сотрудниками.