Здравствуйте, меня зовут Дмитрий Гончаренко, я директор по развитию ПланФикса. На Хабре я давно, но для Мегамозга еще ничего не писал. Вот, решил попробовать :)
Взяться за написание этой заметки меня сподвигла тема на нашем форуме "Поделитесь секретом вашей техподдержки". Нас достаточно часто хвалят за поддержку, но до появления этой темы я не смотрел на неё как на какое-то особое достижение или секрет, которым имеет смысл делиться. Честно говоря, я и сейчас, когда пишу эти строки, не уверен, что мы делаем что-то особенное. Поэтому поступлю просто: опишу всё как есть и выложу вам на обозрение — а вы сами сделаете вывод, есть в нашем опыте что-то полезное, или это просто набор банальностей.
Начать хочу с короткого дисклеймера:
Ниже по пунктам изложено всё, что я считаю значимым для описания того, как устроена служба поддержки ПланФикса.
Мы стараемся ответить на все запросы в течение 2-х бизнес-часов, но не включаем это в соглашение с пользователем и не берем на себя каких-то дополнительных обязательств по этому поводу. Обычно отвечать получается гораздо быстрее (об этом ниже), но случаются и задержки. Практика показывает, что пользователей вполне устраивает такой вариант и они воспринимают нашу поддержку как быструю.
В идеале, пользователь должен получить ответ на свое обращение в течение нескольких минут с момента его отправки. Это не обязательно полный и исчерпывающий ответ (хотя мы стремимся к этому) — но даже получив в ответ на сообщение об ошибке короткое “Спасибо, воспроизведем эту ситуацию и устраним ошибку”, клиент понимает, что мы не оставим его один на один с проблемой.
При этом мы против автоответов: они экономят время сотрудников, но не создают у пользователя ощущение защищенности — вдруг бот просто положил его обращение в кучку и никто реально им не занимается.
Мы не просим пользователей сортировать свои вопросы по полочкам — баги отдельно, запросы на функционал отдельно и так далее. Наоборот, везде при случае мы просим присылать нам любые запросы — нам внутри проще их рассортировать и подключить нужного специалиста для ответа.
Наша служба поддержки обрабатывает не только сообщения о багах и предложения по доработке функционала, но и дает развернутые консультации по настройке и наилучшим вариантам использования ПланФикса для организации бизнес-процессов клиента. Консультации тоже бесплатны, хотя могут занимать много времени.
Тут важный момент: мы воспринимаем консультации не как часть маркетинга, а как важный аспект управления продуктом. Такие консультации помогают нам познакомиться с реальными бизнес-ситуациями, увидеть как ПланФикс может их обслуживать и что нам нужно доработать для того, чтобы он справлялся с ними лучше. Значимость этой информации сложно переоценить, поэтому платить за неё своим временем мы считаем выгодной для себя сделкой.
В первую очередь я имею в виду стиль общения, а не сам язык (хотя на запросы на английском или украинском клиент получит ответ на том же языке). По умолчанию, мы придерживаемся легкого, доброжелательного, но при этом уважительного стиля: обращаемся к клиенту по имени (без отчества), но на “Вы” с большой буквы. При этом, если клиент подает сигналы, предлагая перейти на более официальный или наоборот, неформальный тон, мы его обязательно поддержим. Иногда бывает даже так (ниже — сообщение клиента, выше — мой ответ):
Мы не делаем разницы между платными и бесплатными аккаунтами в ответах на вопросы — ни в очередности, ни в объеме затраченного на ответ времени. К нам может обратиться не только администратор аккаунта компании-клиента, но и любой рядовой пользователь этого аккаунта. Даже если идет пробный период и совершенно не факт, что этот человек останется работать в ПланФиксе после его окончания хотя бы на бесплатной основе.
С нашей стороны всё это не просто альтруизм: найденная ошибка или толковое предложение, сделанное пользователем, который не платит нам денег, помогают нам улучшить продукт — а это напрямую влияет на количество и удовлетворенность платных пользователей.
Тикет в службу поддержки ПланФикса помимо сотрудников самой ТП получают наш CEO, главный разработчик и я. Это прямое нарушение общепринятой практики — дорогостоящее время топ-менеджмента расходуется на прочтение (а зачастую и ответы) пользователям.
Есть еще более страшная вещь — на сайте ПланФикса установлен JivoSite и там в чате есть только два оператора, я и наш CEO, Михаил Гошка (@ZzzZJIou). То есть, у каждого пользователя, обратившегося в ПланФикс по любому каналу, есть прямая связь с “мозгом” команды.
Минусы этого подхода понятны — отвлечение. Распределение запросов среди коллег (см. следующий пункт) помогает нам сгладить этот момент, но всё равно приходится отвлекаться. Плюсы, наверное, тоже понятны: постоянная обратная связь с окружающим миром позволяет нам развиваться быстро и в правильном направлении.
Есть в этом подходе еще одна опасная составляющая, которая может быть не очевидной с первого взгляда: запуская внешние сигналы напрямую в свой мозг, вы должны обладать стройной картиной продукта и его будущего, иначе пользователи размажут её и вы сделаете “всё для всех и ни о чем”. Мы смогли выстроить входные фильтры, основывающиеся на идеологии ПланФикса, которые позволяют нам этого не бояться. Но для массового употребления я эту практику не рекомендую — это действительно опасно.
К каждому тикету сразу подключаются все сотрудники техподдержки (их сейчас двое) + “мозг” из пункта выше. Первый сотрудник, принявший тикет, автоматически становится ответственным за него, но остальные не отключаются, а остаются тут же в роли участников — наблюдателей и советчиков.
Такой подход имеет понятные минусы (неоптимальное использование человеческих ресурсов), зато позволяет нам:
Маленькая картинка из ежедневной рутины: если я занимался другими делами и после этого переключаюсь в Хронику ПланФикса, чтобы посмотреть, что происходит в жизни, то обязательно увижу парочку задач с плашкой “Непринятая”. Скорее всего, они ждут именно меня — коллеги взяли в работу всё остальное, а эти тикеты оставили, потому что я справлюсь с ними лучше. Так работает человеческий фильтр в небольшой команде.
Когда в техподдержке появляется новый сотрудник, он сразу подключается в общий пул людей, получающих все тикеты. Поначалу он просто наблюдает за происходящим, вычитывая ответы, усваивая новую информацию и перенимая стиль общения. Затем помаленьку начинает брать на себя простые тикеты и прокачивать скиллы для ответов на более сложные. Всё это время он находится под присмотром более опытных коллег, которые готовы прийти на помощь с консультацией или поправкой.
Это позволяет нам прозрачно, без отдельных затрат на обучение и серьезных факапов с клиентами, масштабировать службу поддержки по мере роста клиентской базы.
Все критичные баги мы правим сразу после обращения, откладывая прочие дела. Критичным в нашем понимании считается баг, который прямо сейчас мешает человеку выполнять важную для него работу — даже если это только один человек в одном аккаунте. Все прочие ошибки мы откладываем на конец недели. В пятницу весь день разработчики занимаются правкой таких багов. Этот подход мы в свое время подсмотрели где-то на Хабре, попробовали и он прижился.
Неочевидный плюс этого решения: клиенты, которые сообщают о багах в пятницу, получают удивительный опыт общения с техподдержкой, которая правит неважные вроде бы вещи в течение нескольких часов (а иногда и минут). Результатом являются в том числе и такие посты:
Мы никак не регламентируем наличие либо отсутствие юмора в общении, но я, например, часто юморю. Причем далеко не всегда удачно и в тему, вот свежий пример:
Зато если шутка удалась и была понята, получается здорово. Сам я тоже питаю слабость к пользователям с чувством юмора — с ними у нас всегда устанавливаются более тесные взаимоотношения. В общем, юмор сближает — а за неудачную шутку можно и извиниться, если что. Ну или просто в продолжении общения подвинуть вверх бегунок “Серьезность”.
Неадекватные клиенты к нам заходят очень редко, но иногда случаются. В общении с ними нам помогает опыт, полученный при поддержке другого нашего проекта, приложения в Одноклассниках — там нормой является получить на входе неструктурированный поток гнева от бабушки, которая не может ничего рассказать о том, что и как она сделала, и преобразовать его в ”спасибо!” с миллионом сердечек и цветочков на выходе. После такой закалки самый неадекватный пользователь ПланФикса воспринимается чуть ли не с умилением, как шалящий карапуз.
Кстати, сам я при работе с неадекватами использую одну психологическую уловку: представляю себя главврачом психиатрической лечебницы, а неадеквата — её пациентом. Внимательно слушаю, не раздражаю возражениями, жду пока пройдет приступ и мягко, под локоток, провожаю в коечку. Всё происходит предельно корректно и вежливо, на уровень неадеквата не опускаемся — врачи отдельно, пациенты отдельно. Ну не обижаться же на него, действительно.
В ПланФиксе мне к этой уловке приходилось прибегать только 2 раза за всю историю (аудитория всё же пока достаточно адекватная), а вот с Одноклассниками и в принципе при общении в соцсетях это здорово помогает.
В качестве тикет-системы мы используем сам ПланФикс — универсальность позволяет ему вполне комфортно выполнять и эту роль. Многие наши клиенты поступают также.
Тикеты могут попадать в ПланФикс из почты, из внешних форм на сайте, посредством API — ну или прямо из ПланФикса:
В этом варианте клиент ставит задачу службе поддержки и общается в ней прямо из своего аккаунта. Это нормальная для ПланФикса практика — задачи у нас могут ставиться из одного аккаунта в другой. При этом каждый из участников задачи сам управляет комментариями — например, мы можем спокойно общаться по тикету с коллегами в своем аккаунте, клиент этого не увидит. А когда нам нужно будет отправить сообщение ему, мы просто выберем его в блоке “Уведомить об этом” и он получит новый комментарий в своей задаче.
Если клиент общается с нами по почте, мы получаем все его обращения в ПланФикс и работаем с ними как с обычными задачами — а клиент может увидеть все свои задачи и работать с ними в Личном кабинете.
Тут у нас тоже всё не как у людей — оценку выставляет не пользователь, а сам сотрудник. И это не просто количественная оценка по какой-то шкале, а набор параметров, характеризующих проведённую работу.
Для этой оценки мы используем стандартный механизм ПланФикса под названием аналитика. Мы добавили в свой аккаунт аналитику “Оценка ответа”, в которой сотрудник, закрывая тикет, оценивает проведенную им работу по нескольким параметрам. Вот так она выглядит в ленте действий по задаче:
Если кликнуть на добавленную аналитику, можно увидеть параметры оценки этого ответа:
Всё, кроме количества ссылок и скриншотов, выбирается из настроенных нами же справочников типовых оценок, поэтому заполнение аналитики занимает секунды. Результаты работы всех сотрудников собираются в отчет и тарифицируются.
Таким образом мы полностью ведем всю работу по обращениям пользователей ПланФикса в самом ПланФиксе, от момента поступления заявки, до расчета зарплаты сотрудникам службы поддержки.
Для оценки того, что получается на выходе вышеописанного подхода, можно почитать отзывы о ПланФиксе на Startpack.ru — там часто упоминается служба поддержки.
Закончу тем, с чего начал: наш способ организации техподдержки специфичен и не оптимален, к тому же работает только для небольшой компании. Но зато он даёт нам:
Вот вроде бы и всё, что можно рассказать о нашем подходе к организации службы поддержки. Наверняка я что-то забыл — готов ответить на вопросы в комментариях.
Взяться за написание этой заметки меня сподвигла тема на нашем форуме "Поделитесь секретом вашей техподдержки". Нас достаточно часто хвалят за поддержку, но до появления этой темы я не смотрел на неё как на какое-то особое достижение или секрет, которым имеет смысл делиться. Честно говоря, я и сейчас, когда пишу эти строки, не уверен, что мы делаем что-то особенное. Поэтому поступлю просто: опишу всё как есть и выложу вам на обозрение — а вы сами сделаете вывод, есть в нашем опыте что-то полезное, или это просто набор банальностей.
Начать хочу с короткого дисклеймера:
- Наш опыт получен в условиях небольшой команды (сейчас нас 9 человек), сложного продукта и искренней, а не “потому что модно”, ориентации на удовлетворенность клиента. В других условиях он может быть бесполезен.
- Даже с учетом вышесказанного, я не считаю, что мы открыли волшебный рецепт организации техподдержки и всем срочно нужно делать также.
- Некоторые вещи мы делаем вразрез с общепринятыми нормами — но это совсем не обязательно серебряная пуля, возможно эти “неправильности” как раз вредят. Просто мы привыкли делать так и не проверяли других подходов.
Ниже по пунктам изложено всё, что я считаю значимым для описания того, как устроена служба поддержки ПланФикса.
Мягкий регламент
Мы стараемся ответить на все запросы в течение 2-х бизнес-часов, но не включаем это в соглашение с пользователем и не берем на себя каких-то дополнительных обязательств по этому поводу. Обычно отвечать получается гораздо быстрее (об этом ниже), но случаются и задержки. Практика показывает, что пользователей вполне устраивает такой вариант и они воспринимают нашу поддержку как быструю.
Быстрый (но не авто) ответ
В идеале, пользователь должен получить ответ на свое обращение в течение нескольких минут с момента его отправки. Это не обязательно полный и исчерпывающий ответ (хотя мы стремимся к этому) — но даже получив в ответ на сообщение об ошибке короткое “Спасибо, воспроизведем эту ситуацию и устраним ошибку”, клиент понимает, что мы не оставим его один на один с проблемой.
При этом мы против автоответов: они экономят время сотрудников, но не создают у пользователя ощущение защищенности — вдруг бот просто положил его обращение в кучку и никто реально им не занимается.
Любые вопросы
Мы не просим пользователей сортировать свои вопросы по полочкам — баги отдельно, запросы на функционал отдельно и так далее. Наоборот, везде при случае мы просим присылать нам любые запросы — нам внутри проще их рассортировать и подключить нужного специалиста для ответа.
Наша служба поддержки обрабатывает не только сообщения о багах и предложения по доработке функционала, но и дает развернутые консультации по настройке и наилучшим вариантам использования ПланФикса для организации бизнес-процессов клиента. Консультации тоже бесплатны, хотя могут занимать много времени.
Тут важный момент: мы воспринимаем консультации не как часть маркетинга, а как важный аспект управления продуктом. Такие консультации помогают нам познакомиться с реальными бизнес-ситуациями, увидеть как ПланФикс может их обслуживать и что нам нужно доработать для того, чтобы он справлялся с ними лучше. Значимость этой информации сложно переоценить, поэтому платить за неё своим временем мы считаем выгодной для себя сделкой.
Говорим на языке клиента
В первую очередь я имею в виду стиль общения, а не сам язык (хотя на запросы на английском или украинском клиент получит ответ на том же языке). По умолчанию, мы придерживаемся легкого, доброжелательного, но при этом уважительного стиля: обращаемся к клиенту по имени (без отчества), но на “Вы” с большой буквы. При этом, если клиент подает сигналы, предлагая перейти на более официальный или наоборот, неформальный тон, мы его обязательно поддержим. Иногда бывает даже так (ниже — сообщение клиента, выше — мой ответ):
Счастье для всех, даром
Мы не делаем разницы между платными и бесплатными аккаунтами в ответах на вопросы — ни в очередности, ни в объеме затраченного на ответ времени. К нам может обратиться не только администратор аккаунта компании-клиента, но и любой рядовой пользователь этого аккаунта. Даже если идет пробный период и совершенно не факт, что этот человек останется работать в ПланФиксе после его окончания хотя бы на бесплатной основе.
С нашей стороны всё это не просто альтруизм: найденная ошибка или толковое предложение, сделанное пользователем, который не платит нам денег, помогают нам улучшить продукт — а это напрямую влияет на количество и удовлетворенность платных пользователей.
Прямая связь с мозгом (осторожно!)
Тикет в службу поддержки ПланФикса помимо сотрудников самой ТП получают наш CEO, главный разработчик и я. Это прямое нарушение общепринятой практики — дорогостоящее время топ-менеджмента расходуется на прочтение (а зачастую и ответы) пользователям.
Есть еще более страшная вещь — на сайте ПланФикса установлен JivoSite и там в чате есть только два оператора, я и наш CEO, Михаил Гошка (@ZzzZJIou). То есть, у каждого пользователя, обратившегося в ПланФикс по любому каналу, есть прямая связь с “мозгом” команды.
Минусы этого подхода понятны — отвлечение. Распределение запросов среди коллег (см. следующий пункт) помогает нам сгладить этот момент, но всё равно приходится отвлекаться. Плюсы, наверное, тоже понятны: постоянная обратная связь с окружающим миром позволяет нам развиваться быстро и в правильном направлении.
Есть в этом подходе еще одна опасная составляющая, которая может быть не очевидной с первого взгляда: запуская внешние сигналы напрямую в свой мозг, вы должны обладать стройной картиной продукта и его будущего, иначе пользователи размажут её и вы сделаете “всё для всех и ни о чем”. Мы смогли выстроить входные фильтры, основывающиеся на идеологии ПланФикса, которые позволяют нам этого не бояться. Но для массового употребления я эту практику не рекомендую — это действительно опасно.
Один за всех и все за одного
К каждому тикету сразу подключаются все сотрудники техподдержки (их сейчас двое) + “мозг” из пункта выше. Первый сотрудник, принявший тикет, автоматически становится ответственным за него, но остальные не отключаются, а остаются тут же в роли участников — наблюдателей и советчиков.
Такой подход имеет понятные минусы (неоптимальное использование человеческих ресурсов), зато позволяет нам:
- распределять задачи по специфике (каждый может брать на себя тот вопрос, за который отвечает или в котором силён);
- при необходимости обращаться к коллегам за помощью (в том числе дополнительно подключая к тикету разработчиков, ответственных за рассматриваемый функционал — для нас это нормальная практика);
- обучать новых сотрудников (ниже расскажу подробнее).
Маленькая картинка из ежедневной рутины: если я занимался другими делами и после этого переключаюсь в Хронику ПланФикса, чтобы посмотреть, что происходит в жизни, то обязательно увижу парочку задач с плашкой “Непринятая”. Скорее всего, они ждут именно меня — коллеги взяли в работу всё остальное, а эти тикеты оставили, потому что я справлюсь с ними лучше. Так работает человеческий фильтр в небольшой команде.
Делай как я
Когда в техподдержке появляется новый сотрудник, он сразу подключается в общий пул людей, получающих все тикеты. Поначалу он просто наблюдает за происходящим, вычитывая ответы, усваивая новую информацию и перенимая стиль общения. Затем помаленьку начинает брать на себя простые тикеты и прокачивать скиллы для ответов на более сложные. Всё это время он находится под присмотром более опытных коллег, которые готовы прийти на помощь с консультацией или поправкой.
Это позволяет нам прозрачно, без отдельных затрат на обучение и серьезных факапов с клиентами, масштабировать службу поддержки по мере роста клиентской базы.
Пятница — день багов
Все критичные баги мы правим сразу после обращения, откладывая прочие дела. Критичным в нашем понимании считается баг, который прямо сейчас мешает человеку выполнять важную для него работу — даже если это только один человек в одном аккаунте. Все прочие ошибки мы откладываем на конец недели. В пятницу весь день разработчики занимаются правкой таких багов. Этот подход мы в свое время подсмотрели где-то на Хабре, попробовали и он прижился.
Неочевидный плюс этого решения: клиенты, которые сообщают о багах в пятницу, получают удивительный опыт общения с техподдержкой, которая правит неважные вроде бы вещи в течение нескольких часов (а иногда и минут). Результатом являются в том числе и такие посты:
Юмор
Мы никак не регламентируем наличие либо отсутствие юмора в общении, но я, например, часто юморю. Причем далеко не всегда удачно и в тему, вот свежий пример:
Зато если шутка удалась и была понята, получается здорово. Сам я тоже питаю слабость к пользователям с чувством юмора — с ними у нас всегда устанавливаются более тесные взаимоотношения. В общем, юмор сближает — а за неудачную шутку можно и извиниться, если что. Ну или просто в продолжении общения подвинуть вверх бегунок “Серьезность”.
То, что доктор прописал
Неадекватные клиенты к нам заходят очень редко, но иногда случаются. В общении с ними нам помогает опыт, полученный при поддержке другого нашего проекта, приложения в Одноклассниках — там нормой является получить на входе неструктурированный поток гнева от бабушки, которая не может ничего рассказать о том, что и как она сделала, и преобразовать его в ”спасибо!” с миллионом сердечек и цветочков на выходе. После такой закалки самый неадекватный пользователь ПланФикса воспринимается чуть ли не с умилением, как шалящий карапуз.
Кстати, сам я при работе с неадекватами использую одну психологическую уловку: представляю себя главврачом психиатрической лечебницы, а неадеквата — её пациентом. Внимательно слушаю, не раздражаю возражениями, жду пока пройдет приступ и мягко, под локоток, провожаю в коечку. Всё происходит предельно корректно и вежливо, на уровень неадеквата не опускаемся — врачи отдельно, пациенты отдельно. Ну не обижаться же на него, действительно.
В ПланФиксе мне к этой уловке приходилось прибегать только 2 раза за всю историю (аудитория всё же пока достаточно адекватная), а вот с Одноклассниками и в принципе при общении в соцсетях это здорово помогает.
Сам с усам
В качестве тикет-системы мы используем сам ПланФикс — универсальность позволяет ему вполне комфортно выполнять и эту роль. Многие наши клиенты поступают также.
Тикеты могут попадать в ПланФикс из почты, из внешних форм на сайте, посредством API — ну или прямо из ПланФикса:
В этом варианте клиент ставит задачу службе поддержки и общается в ней прямо из своего аккаунта. Это нормальная для ПланФикса практика — задачи у нас могут ставиться из одного аккаунта в другой. При этом каждый из участников задачи сам управляет комментариями — например, мы можем спокойно общаться по тикету с коллегами в своем аккаунте, клиент этого не увидит. А когда нам нужно будет отправить сообщение ему, мы просто выберем его в блоке “Уведомить об этом” и он получит новый комментарий в своей задаче.
Если клиент общается с нами по почте, мы получаем все его обращения в ПланФикс и работаем с ними как с обычными задачами — а клиент может увидеть все свои задачи и работать с ними в Личном кабинете.
Оценка ответа
Тут у нас тоже всё не как у людей — оценку выставляет не пользователь, а сам сотрудник. И это не просто количественная оценка по какой-то шкале, а набор параметров, характеризующих проведённую работу.
Для этой оценки мы используем стандартный механизм ПланФикса под названием аналитика. Мы добавили в свой аккаунт аналитику “Оценка ответа”, в которой сотрудник, закрывая тикет, оценивает проведенную им работу по нескольким параметрам. Вот так она выглядит в ленте действий по задаче:
Если кликнуть на добавленную аналитику, можно увидеть параметры оценки этого ответа:
Всё, кроме количества ссылок и скриншотов, выбирается из настроенных нами же справочников типовых оценок, поэтому заполнение аналитики занимает секунды. Результаты работы всех сотрудников собираются в отчет и тарифицируются.
Таким образом мы полностью ведем всю работу по обращениям пользователей ПланФикса в самом ПланФиксе, от момента поступления заявки, до расчета зарплаты сотрудникам службы поддержки.
Заключение
Для оценки того, что получается на выходе вышеописанного подхода, можно почитать отзывы о ПланФиксе на Startpack.ru — там часто упоминается служба поддержки.
Закончу тем, с чего начал: наш способ организации техподдержки специфичен и не оптимален, к тому же работает только для небольшой компании. Но зато он даёт нам:
- возможность управлять продуктом в режиме постоянной обратной связи и развивать его для управления реальными, а не придуманными бизнес-ситуациями;
- лояльность пользователей к ошибкам — а их в активно растущем продукте всегда много;
- позитивное “сарафанное радио” — а мы не тратим денег на рекламу и продвигаемся в основном за его счёт, так что для нас это важно;
- дружеские, иногда переходящие в партнерские, взаимоотношения с пользователями.
Вот вроде бы и всё, что можно рассказать о нашем подходе к организации службы поддержки. Наверняка я что-то забыл — готов ответить на вопросы в комментариях.