Pull to refresh
14
0
Yulia Sinyanskaya @YuliaSinyanskaya

Support

Send message
правда такое было :) сама была в шоке
спасибо! мне нравится «развивающая обратная связь» и еще «точки роста» :)
Спасибо за ваш комментарий! Согласна, что не надо ждать review и «копить», лучше давать обратную связь регулярно и часто.
у нас получается нормальное распределение, практически нет выбросов (слишком больших или слишком малых значений), поэтому чаще всего среднее значение совпадает с медианой
спасибо за уточнение. именно здесь я имею в виду нестандартные вопросы, чаще всего связанные с конфигурацией продукта. если инженер обладает достаточными знаниями и тестировал всевозможные конфигурации, он может решить такую заявку одним ответом. ну или протестировать в лабе и дать ответ — что опять же говорит о том, что он понимает, о чем речь и может предоставить решение без доп вопросов и долгих переписок.
Большое спасибо за вопросы!

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

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

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

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

Кстати, если есть CSAT, зачем нужны оценки коллег? Все-таки, мне так думается, оценки коллег являются субъективными и имеют малую полезность.

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

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

Согласна :)

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

Мы ограничиваем возможность «воскрешать» заявку после 14 дней. То есть пользователь пришел, мы ему помогли, у него есть две недели всё проверить и вернуться к нам.

И главный вопрос, как, ну КАК считать все эти метрики :(

Действительно, очень важный вопрос :) Тут уже всё зависит от системы, которую вы используете. Современные трекеры (или тикетницы, как их еще называют) уже имеют встроенную систему сбора и хранения данных. Мы много лет назад взяли RT и адаптировали под себя, свои цели и нужды.
Публиковали анонс на TimePad и нашей страничке ФБ. Подписывайтесь, скоро появится информация по следующей встрече.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity