Правило поддержки - поддержка работает для пользователей. 

Рассмотрим полумеры. 

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

Кейсы отрицательные:

• Требование: одно обращение - один вопрос. Если вдруг два или переход на другой вопрос - ответ о том, что нужно для каждого вопроса отдельный тикет для поддержки. Это нарушает правило поддержки. Вы требуете потратить на вас время, хотя это вы поддержка и у вас оплачено время на работу с пользователями.
• Требование: оценить тикеты. Допустим, 10 тикетов и 20 писем с просьбами оценить уровень. Навязчиво. Назойливо. Если мне, как пользователю понравился ответ - я сам зайду и оценю. Писать для этого 10 писем о том, что сейчас придёт письмо для оценки и ещё 10 писем с возможностью оценки - перебор. Причём очень часто ты оцениваешь хорошо-отлично для того, чтобы поддержка в следующий раз хотя бы вообще вышла на связь, а то, что ответа можно ждать дней 10 - ну хз, перебор для моих нужд, понятно что это они работают как им удобно, нарушая правило поддержки. Затраты времени на отзывы, что нужно именно для поддержки и для руководства поддержки.
• Технические ограничения: снимите видео с ситуацией для поддержки в нужно формате, объёме, чтобы всё видно - стрелочки, клики, элементы. Используйте самые новые технологии + залейте на файлообменник, а то у нас форма максимум принимает 30 мб. Framework 3.5 устарел, у поддержки ограничения спецотдела?, ого думаю,  уровень в отрицательную стороны от правило поддержки.
• Технические ограничения: пришлите проект так, чтобы можно было повторить. При этом явно требуют все доступы к аккаунтам, твой проект, покажите на видео где ошибка и что им сделать, чтобы была у них такая же ошибка. Тут очень сложно показать так называемую "плавающую ошибку", либо ошибку, которая всплывает 1 раз на 1 млн выполнений.
• Конфиденциальность. Выложить куски проекта, в общий чат, где есть все, кто угодно. Обсуждение проекта в общем со скринами, видео в общем. Ну тут вообще пиздец, я считаю.
• Социал. Сотрудники техподдержки боятся руководства больше, чем могут помочь пользователю. Оценки, отзывы, разбиение тикетов на 2 и более - всё это нужно для руководителя отдела поддержки, но тратит время пользователя. Правило поддержки.
• Социал. Упрёки и одёргивания. Придумывание причин отказать, например, как с разбиением тикетов. 
• Сроки. Отсутствие ограничений, через день-два-неделю-месяц. Будет ли ответ - хз. Что говорить, об ответе с решением твоих задач или там будет написано - пришлите нам ваш проект мы посмотрим, случай описанный в третьем пункте текущего списка.
• Технические ограничения и сроки. В результате ожидания ответа, который нужен сразу, мы получаем от техподдержки решение. Но в процессе ожидания, мы делаем своё решение, чаще всего это "костыли". Ну и соответственно никто возвращаться к тому вопросу не хочет и получается, что готовое, правильное решение просто лежит в архивах техподдержки.

Кейсы положительные:

• Только опыт работы с поддержкой мог сформировать в моём сознании такой пост.

Пост буду обновлять по мере появления новых кейсов и случаев. 
В комментариях можете добавить свои кейсы, положительные или отрицательные.

обновление 06.02.2024