Comments 14
Очень полезная и интересная статья, для любой компании где есть служба тех-поддержки) я бы с удовольствием включил ссылку на эту статью в качестве обучающего материала для сотрудников и руководителей такого отдела)
Спасибо, почитал
Если инженеры решают заявку с первого ответа — это показатель технической «прокаченности» команды. Также, отслеживая вопросы в тикетах, решенных с первого ответа, можно понять, какие статьи в базу знаний очень нужно написать, а какую инфо добавить в документацию по продукту.
Не могли бы Вы пояснить, по какому критерию определяется, что нужно написать и куда, что в первую очередь. Повертел мысль и так и эдок и не понял, как связан FCR с базой знаний. Например, написал человек с вопросом, ответ на который содержится в документации на первой же странице. Вопрос был закрыт одним ответом публикацией ссылки на эту страницу.
или другой пример, вопрос был закрыт одним ответом, но этот вопрос совершенно уникальный и необходимости создавать какой-то материал нет смысла, т.к. есть более часто спрашиваемые и неописанные сущности.
Вопросы problem management и knoledge management мне не дают спать уже давно :) И я был бы очень признателен, если бы Вы поделились опытом и примерами.
Еще некоторые мысли и вопросы:
Интересная у вас метрика — QA. Подумаю на досуге. Мы делаем то же самое, но не ставим оценки. И, вероятно, зря, интегральной картины и динамики -то нет.
Но с другой стороны, динамику и интегральную картину мы получаем для оценки качества все из того же FCR, Количества сообщений в рамках одного запроса и CSAT.
Кстати, если есть CSAT, зачем нужны оценки коллег? Все-таки, мне так думается, оценки коллег являются субъективными и имеют малую полезность. Если только нужны для контроля новичков.
Потому что менеджер может оценить качество ответа по каким-то своим или стандартным критериям. А вот удовлетворенность пользователя в итоге совершенно не совпадет с оценкой менеджера. А что такое качество обслуживания? Мне кажется это зависит от целей. У техподдержки цель можно сформулировать — удовлетворенность от услуги или от продукта, как следствие, повышение ценности услуги или продукта для клиента. Некое конкретное качество или абстрактное качество не представляет ценности само по себе, т.к. нет прямой связи с целью предоставления услуги. Как мне кажется.
И главный вопрос, как, ну КАК считать все эти метрики :( Я умею пользоваться экселькой, но пользователи не хотят и не желают создавать новые тикеты для новых проблем. А очень часто отвечают на старые реквесты. В результате чего ни FCR, ни TTR посчитать корректно в автоматическом режиме не получается :(
Единственный выход, который вижу — запрещать воскрешать обращения, если повторного обращения нет более какого-то количества времени.
Спасибо за интересную статью! И успехов в делах :)
Большое спасибо за вопросы!
Здесь речь о том, случае, когда инфо еще не содержится в гайде или КБ. Например, к вам приходит 10 человек с похожим запросом и все эти запросы решаются одним ответом — проще тогда опубликовать статью, сэкономить время себе и пользователям.
Для таких ситуаций мы создаем черновики статей. и если вопрос встретился еще раз у другого пользователя — публикуем.
Пользователь оценивает с точки зрения понравилось/не понравилось, коллеги же оценивают с точки зрения «правильности». Смотрят на ход мыслей, как можно было бы по-другому и быстрее решить проблему. Это как работа над ошибками в школе :) цель данной оценки — повысить знания инженера.
Согласна :)
Мы ограничиваем возможность «воскрешать» заявку после 14 дней. То есть пользователь пришел, мы ему помогли, у него есть две недели всё проверить и вернуться к нам.
Действительно, очень важный вопрос :) Тут уже всё зависит от системы, которую вы используете. Современные трекеры (или тикетницы, как их еще называют) уже имеют встроенную систему сбора и хранения данных. Мы много лет назад взяли RT и адаптировали под себя, свои цели и нужды.
Не могли бы Вы пояснить, по какому критерию определяется, что нужно написать и куда, что в первую очередь. Повертел мысль и так и эдок и не понял, как связан FCR с базой знаний. Например, написал человек с вопросом, ответ на который содержится в документации на первой же странице. Вопрос был закрыт одним ответом публикацией ссылки на эту страницу.
Здесь речь о том, случае, когда инфо еще не содержится в гайде или КБ. Например, к вам приходит 10 человек с похожим запросом и все эти запросы решаются одним ответом — проще тогда опубликовать статью, сэкономить время себе и пользователям.
или другой пример, вопрос был закрыт одним ответом, но этот вопрос совершенно уникальный и необходимости создавать какой-то материал нет смысла, т.к. есть более часто спрашиваемые и неописанные сущности.
Для таких ситуаций мы создаем черновики статей. и если вопрос встретился еще раз у другого пользователя — публикуем.
Кстати, если есть CSAT, зачем нужны оценки коллег? Все-таки, мне так думается, оценки коллег являются субъективными и имеют малую полезность.
Пользователь оценивает с точки зрения понравилось/не понравилось, коллеги же оценивают с точки зрения «правильности». Смотрят на ход мыслей, как можно было бы по-другому и быстрее решить проблему. Это как работа над ошибками в школе :) цель данной оценки — повысить знания инженера.
Потому что менеджер может оценить качество ответа по каким-то своим или стандартным критериям. А вот удовлетворенность пользователя в итоге совершенно не совпадет с оценкой менеджера. А что такое качество обслуживания? Мне кажется это зависит от целей. У техподдержки цель можно сформулировать — удовлетворенность от услуги или от продукта, как следствие, повышение ценности услуги или продукта для клиента. Некое конкретное качество или абстрактное качество не представляет ценности само по себе, т.к. нет прямой связи с целью предоставления услуги. Как мне кажется.
Согласна :)
Единственный выход, который вижу — запрещать воскрешать обращения, если повторного обращения нет более какого-то количества времени.
Мы ограничиваем возможность «воскрешать» заявку после 14 дней. То есть пользователь пришел, мы ему помогли, у него есть две недели всё проверить и вернуться к нам.
И главный вопрос, как, ну КАК считать все эти метрики :(
Действительно, очень важный вопрос :) Тут уже всё зависит от системы, которую вы используете. Современные трекеры (или тикетницы, как их еще называют) уже имеют встроенную систему сбора и хранения данных. Мы много лет назад взяли RT и адаптировали под себя, свои цели и нужды.
Не могли бы Вы пояснить, по какому критерию определяется, что нужно написать и куда, что в первую очередь. Повертел мысль и так и эдок и не понял, как связан FCR с базой знаний. Например, написал человек с вопросом, ответ на который содержится в документации на первой же странице. Вопрос был закрыт одним ответом публикацией ссылки на эту страницу.
Наличие документации совершенно не означает, что вопросов не будет.
Если вопросы задаются, даже при наличии документации, это значит:
— документацию почему-то не могут найти. нужно придумать, как сделать ее легко доступной.
— либо документация неполна, неточна, и прочее не. нужно ее исправить, актуализировать.
— либо документация описана так, что понимается не так, как должна. нужно переформулировать, перефразировать, по другому структурировать.
— либо функционал устроен так, что вводит в заблуждение. надо переделать функционал.
Т.е. в идеале FCR показывает, что что-то решается очевидным способом, но почему-то это неочевидно с первого раза.
Юля, спасибо за пост.
Перечитал раз пять, особенно агитки/иллюстрации, их наверное раз шесть.
Спасибо за
Спасибо за
> Если инженеры решают заявку с первого ответа — это показатель технической «прокаченности» команды.
а нет ли здесь недоработанности продукта? Иначе говоря, если проблема настолько простая, что её можно решить одним ответом, то не означает ли это что в продукте есть какой-то известный баг или недочет, который стоит исправить и тогда этот класс проблем уйдет?
а нет ли здесь недоработанности продукта? Иначе говоря, если проблема настолько простая, что её можно решить одним ответом, то не означает ли это что в продукте есть какой-то известный баг или недочет, который стоит исправить и тогда этот класс проблем уйдет?
спасибо за уточнение. именно здесь я имею в виду нестандартные вопросы, чаще всего связанные с конфигурацией продукта. если инженер обладает достаточными знаниями и тестировал всевозможные конфигурации, он может решить такую заявку одним ответом. ну или протестировать в лабе и дать ответ — что опять же говорит о том, что он понимает, о чем речь и может предоставить решение без доп вопросов и долгих переписок.
понял. Ну, мы помельче, так что сам факт наличия подобных ответов мы стараемся воспринимать как проблему в софте.
Например, у нас очень долгое время были проблемы с тем, как объяснить людям, в какой файл положить лицензионный ключ. Ответ как раз с первого раза. Потом просто переделали лаунчер (софт то серверный, интерактива нет) и всё стало хорошо.
Например, у нас очень долгое время были проблемы с тем, как объяснить людям, в какой файл положить лицензионный ключ. Ответ как раз с первого раза. Потом просто переделали лаунчер (софт то серверный, интерактива нет) и всё стало хорошо.
А почему для IRT и TTR вы считаете среднее, а не медианное значение?
Спасибо за статью!
В своё время, работая в техподдержке, правда для голосовых ответов, замеряли аналогичные показатели.
Однако у нас был ещё один показатель, о котором тут нет речи, а именно повторное обращение с той же темой. Он позволял быстро оценить качество работы каждого инженера(второй линии).
В своё время, работая в техподдержке, правда для голосовых ответов, замеряли аналогичные показатели.
Однако у нас был ещё один показатель, о котором тут нет речи, а именно повторное обращение с той же темой. Он позволял быстро оценить качество работы каждого инженера(второй линии).
Грамотно выстроенные линии, отстроенные тулзы «под себя» и квалифицированный персонал — все просто.
Sign up to leave a comment.
Качество сервиса на три буквы