3.3) если поддержка должным образом организована, то должны быть публичные или хотя бы внутренние knowledge base статьи. Простой способ устранить типичные проблемы - ликвидировать причину заглядывать в самые цитируемые/посещаемые. С одной стороны это каннибализация труда тех.поддержки, а с другой стороны - это гарантированная отдача. Низковисящий фрукт. Пробовали и имели хорошие результаты.

Что не очень работало в моей практике -

4) категоризация входящих инцидентов (или так называемая таксономия). Когда-то было построено дерево, описывающее функции продукта, и всякий инцидент приписывался к соответствующему узлу. Почему не взлетело?

4.1) при аутсорсе обеспечить соблюдение этого правила сложно. Нужны постоянные проверки и контроль качества. Это дорого. А неправильно расставленные категории бесполезны

4.2) даже правильно расставленные категории оказались бесполезны. проблемы пользователей оказались равномерно размазаны по всем функциональным категориям. грубо говоря, чем пользуемся, на то и жалуемся. не было какого-то узкого места.

возможно, такое узкое место нашлось бы при категоризации под каким-то другим углом (скажем, не по функциям, а по внутренним компонентам). Но заполнение тогда становится еще более сложным и еще менее надежным. Не готов рекомендовать этот путь.

Disclaimer. Текст записан по мотивам кухонной мини-лекции коллегам, и на полноту рассмотрения не претендует.