Две недели назад задал вопрос. Ответы разделились на три лагеря: «если клиент доволен — плюс в карму поддержки», «если проблема та же — вопрос к поддержке», «поддержка отработала, подвели те, кто за ней».

Все три — о том, кто сработал хорошо, а кто плохо. А почему клиент пришёл в третий раз? Для меня пока у повторяющейся причины нет владельца, её меряют скоростью закрытия, и она живёт вечно.

В 2019-м в Тинькофф (сейчас Т-Банк) часть переводов уходила по устаревшим реквизитам, клиент узнавал об этом через несколько дней и писал в поддержку. Каждое обращение закрывали быстро и вежливо. И на следующий день получали такое же.

Решение оказалось не в поддержке. Я спроектировал мониторинг, который ловил такие платежи сам и ставил задачу ответственной команде на уточнение реквизитов. Клиент ни о чём не узнавал: проблема решалась до того, как у него появлялся повод написать.

Это problem management — не ИТ-инструмент, а управленческий. В основе одно различение. Инцидент — то, что сломалось сейчас, его чинят быстро. Проблема — причина, по которой это ломается снова; её устраняют. Пока компания меряет только скорость закрытия инцидентов, она платит за одно и то же каждый день и называет это стабильной работой.

Потом я повторял это дважды. В Vivid Money, как Problem Manager в продуктовой команде платежей и переводов: унаследованный бэклог разбирали не по одному тикету, а по причинам — и разобрали почти полностью. В Plata тот же принцип заложили в сервисную модель с самого начала, и быстрый рост показал, что он работает.

Схема не зависит от отрасли: нужен поток повторяющихся событий — заявки, рекламации, простои, возвраты — и человек, которому за них отвечать.

В быту так же. В офисном санузле вкладки против брызг несколько дней лежали вверх ногами: задача уборщика — «помыть», а не «чтобы работало», и каждый уровень чинит последствия предыдущего.

Признак везде один: если одно и то же делаешь в третий раз — это уже не задача, а причина, которую пора искать.

С чего начать без системы и бюджета. Первое: посчитать, какая доля обращений или инцидентов — повторы одной причины. Второе: назначить владельца проблем — одного человека, у которого это в должности, а не «все понемногу». Третье: одна причина в неделю, доведённая до закрытия, а не "десять" параллельно.

Мешает одно: проблема почти никогда не срочная. У инцидента есть клиент, который ждёт; у проблемы — нет. Поэтому без владельца её никто не решит.

Если посчитаете долю повторов — напишите, какая получилась. По моему опыту эта цифра удивляет всех, кто считает её впервые.