Немного расскажу про работу с технической поддержкой - это те, прикованные к пулемету люди, которые прикрывают разработчиков от неприятных слов со стороны клиентов. И затыкают собой все дырки в customer experience.

Масштабируется техническая поддержка трудно и дорого. Неудовлетворенный клиент - это весьма вероятно потерянный клиент. Один сотрудник может обработать только фиксированное число входящих запросов. А много сотрудников это дорого. Итого: проблемный продукт делает удержание клиента дорогим.

Есть в индустрии широко известный показатель CAC = Customer Acquisition Cost, сколько стоит привлечение клиента в бизнес. Например, KupiVip рассказывал, что им привлечение клиента стоит 2000р и зарабатывать магазин начинает только после 3й покупки однажды привлеченного клиента. А есть несколько менее известная метрика CRC = Customer Retention Cost, сколько стоит удержать клиента. Вот туда надо посчитать расходы на тех. поддержку. Например, в хостинге одно обращение в поддержку в год может вывести лишить компанию дохода от этого клиента и оставить один убыток. В нашем бизнесе такое же произойдет для самых маленьких и дешевых клиентов. Поэтому мы боремся за низкое число инцидентов в поддержке даже исходя из чисто экономических соображений, а не только из любви к клиентам.

Что можно сделать для снижения числа инцидентов? Из очевидного, что можно сделать заранее:

1) качественный продукт без багов. бинго! но есть тонкий нюанс - релевантность багов пользовательским сценариям

> Заходит однажды тестировщик в бар.
> и заказывает:
> кружку пива,
> 2 кружки пива,
> 0 кружек пива,
> 999999999 кружек пива,
> ...
> После всего этого в бар заходит первый реальный пользователь и спрашивает, где тут туалет. Бар взрывается.

2) продукт с хорошим UX. Всякая непонятность вызовет вопросы и обращение в поддержку. Возможно, вызовет даже больше обращений, чем баг выше (баг хотя бы не всегда и не у всех срабатывает).

Что можно сделать после (продукт уже вышел)?

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

Передавать скорее будут проблемы, которые или сложно решить отделом тех. поддержки самостоятельно или вообще невозможно. Цена решения такой проблемы очень высока в поддержке (часы, дни, недели). Но может быть также дорого ее устранение и в разработке. Но возможно , что массовая проблема на 15 минут в поддержке кумулятивно (на десятках и сотнях случаев) стоит в поддержке столько же, как и сложная проблема, а решается в разработке намного дешевле.

Почему не всегда легко узнать о типовых простых проблемах? Если поддержка передана в аутсорс, то аутсорс часто оплачивается за объем. Или за объем и скорость решения. Как легче всего набить объем? На массовом решении инцидентов с типовым известным рецептом. Никакого интереса сообщать о таких инцидентах в разработку аутсорсер не испытывает. Но это не обязательно проблема корыстного интереса. Даже бескорыстный человек не запоминает то, что не было для него проблемой. Вы не помните в каком порядке чистили зубы и какой ботинок застегнули первым. А применить легкое известное решение это не проблема. С какой стороны подступиться?

3.1) если не аутсорс поддержка - то попросить подумать и вспомнить типовые массовые проблемы (здесь есть интерес в общем успехе, так что сработает)

3.2) взять выборку в 100-500 входящих инцидентов и поискать повторы в причинах. Кажется страшным, но это вполне реально сделать.