Pull to refresh

Comments 21

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

С декабря 2015, видимо.


Ждал хинта — как быстрее дозвониться в службу поддержки провайдера и объяснить что ситуация аховая ))

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

Понимаю это про меня?)

Да верно. Если сохранился текст комментария, прошу продублировать.
А понижающих коэффициентов нет?
Нет, понижающих коэффициентов в примененном методе не предусмотрено. Они в данном случае и не нужны. Если с заявки с высоким приоритетом в процессе работы снимается один из параметров повышающих коэффициент приоритета, система сразу пересчитывает значение и заявка перемещается в очереди обращений в соответствии с новым значением.
Я немного не про это. Нет ли отрицательных характеристик у самой заявки или её автора?
Нет, такого механизма у нас нет.
А у вас нет пользователей, которые буквально спамят техподдержку? Скажем так, неадекваты, задающие вопрос ради вопроса (наверное, им не с кем пообщаться).
Такие пользователи, как правило появляются у команд поддерживающих B2C продукты. У нас сегмент B2B, где у людей, как правило, нет времени на подобные мероприятия, а есть определенные бизнес задачи, которые необходимо решить в кратчайшие сроки. Поэтому ответ нет.
В моей практике на предыдущих местах работы такие прецеденты были. Каждый раз вопрос решался индивидуально уже на уровне руководства. Как правило у крупных компаний для этих целей предусмотрена исключительная процедура «увольнения» клиента, но в моей практике применялась она лишь один раз.
Примерно так и думаю в целом, но, знаете, есть такой специфический B2B в нашей стране, где весьма своеобразные кадры в бюджетных и околобюджетных учреждениях…
Пожалуй, здесь нет каких-то универсальных рецептов. В каждом подобном случае вопрос решается индивидуально. Благо общее их количество мизерно в сравнении с объемом реальных обращений.
Друзья, читайте продолжение темы в новой статье: https://habrahabr.ru/company/infowatch/blog/321012/ (Простая математика для решения непростых задач)
Sign up to leave a comment.