Ложные пожелания клиентов
Поддержка чаще всех принимает обратную связь по продукту от клиентов и, как правило, обрабатывает обращения в духе «а доработайте, мне надо, не могу работать». Ниже три примера, как это бывает, и комментарии к ним.
#1 💩
— Здравствуйте! Мне нужно, чтобы id обращений в вашей системе начинались с единицы, сейчас они как будто рандомные.
— Добрый день! Id в системе используются без повторений, чтобы избежать накладок, поэтому у каждого свой уникальный номер, стартовать с единицы не получится.
#2 💩
— Здравствуйте! Мне нужно, чтобы id обращений в вашей системе начинались с единицы, сейчас они как будто рандомные.
— Добрый день! Id в системе используются без повторений, чтобы избежать накладок, поэтому у каждого свой уникальный номер, но я передам пожелание в отдел разработки, возможно, в будущем мы что-нибудь придумаем.
#3 🦄
— Здравствуйте! Мне нужно, чтобы id обращений в вашей системе начинались с единицы, сейчас они как будто рандомные.
— Добрый день! Id в системе используются без повторений, чтобы избежать накладок, поэтому у каждого свой уникальный номер, стартовать с единицы не получится, но мы что-нибудь придумаем. Расскажите, какие задачи должна решить нумерация?
— Хотим фиксировать количество сообщений, видеть это в отчетах и передавать клиентам для обратной связи.
— Поняла, спасибо! Клиентам, как правило, не так важно, сколько цифр в идентификаторе — главное решенный запрос и возможность уточнить статус по нему. Вы сможете использовать эти id для обозначения конкретного запроса, считать же по ним количество обращений не придется — отчеты учитывают нагрузку и обработанные запросы без привязки к номерам.
Вот здесь мы описали подробнее, как работают все виды отчетов: …
Чтобы ставить id запроса в тему письма, можно настроить нехитрое правило, которые будет делать это автоматически. Настроить для вас такое?
Ни в первом, ни во втором случае задача клиента не решена, а второй усугубляется еще и тем, что поддержка передаст в продуктовый отдел ложный запрос на доработку. Если коммуникация между отделами выстроена не очень хорошо, такие задачи и правда иногда доходят до прода, и получается, что вместо комплексного решения истинной потребности продукт просто перекрывает поверхностное желание нумеровать входящие тикеты. Так появляются продукты, обрастающие большим количеством никому не нужных, очень узких фич.
В третьем примере один простой уточняющий вопрос решает и задачу клиента, и задачу продуктологов — не нужно ничего дорабатывать, но есть обратная связь и понимание того, что у клиентов есть запросы, которые они не знают, как решать легко и самостоятельно.