Проблемы с доступами в тикетах поддержки: устраните причину

Почему эти тикеты важны

Тикеты в поддержке часто первыми показывают, что с доступом что-то не так. Если одна и та же команда каждую неделю просит об одном и том же исключении, значит, настройки прав, скорее всего, неверные.

Это важно, потому что проблему сначала ощущает именно поддержка. Это люди, которые пытаются помочь клиенту, оформить возврат, проверить заказ или обновить данные в аккаунте, пока время идёт. Если каждый раз нужен менеджер, работа замедляется, а клиенты ждут дольше.

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

Даже короткие заметки в тикете могут многое сказать. Фраза вроде «нужно снова временно дать доступ» или «использую аккаунт Сары, потому что мой не видит биллинг» говорит сразу о двух вещах: у человека есть реальная задача, а текущая схема доступа этой задаче не соответствует.

Такие тикеты — не случайные жалобы. Это повторяющиеся сигналы от той части бизнеса, которая весь день работает с клиентами.

Рост быстро усиливает проблему. Команда из десяти человек ещё может жить на ручных согласованиях и неписаных правилах. На тридцати людях те же привычки превращаются в задержки, путаницу и рискованные обходы. Новые сотрудники копируют то, что помогает выполнить работу, даже если это нарушает правила.

Когда поддержка постоянно просит исключения, сам тикет обычно не является настоящей проблемой. Настоящая проблема в том, что правила доступа больше не совпадают с ежедневной работой. Исправьте это, и количество тикетов обычно снизится, потому что людям перестанет требоваться разрешение на обычные задачи.

Что должна отмечать поддержка

Поддержка часто замечает проблемы с доступом раньше, чем инженерная команда или руководство увидят закономерность. Один тикет сам по себе может выглядеть мелко, но повторяющиеся запросы обычно означают, что схема доступа не соответствует работе.

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

Есть несколько признаков, которые стоит отмечать каждый раз:

• «Разовое» исключение для задачи, которая уже входит в обычную работу человека
• Упоминания общих паролей, заимствованных аккаунтов или фразы «можешь войти и сделать это за меня?»
• Одна и та же заблокированная операция у нескольких людей на одной роли
• Еженедельные или почти еженедельные запросы от одной команды на один и тот же доступ

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

Особое внимание нужно общим логинам. Люди используют их, когда официальный путь слишком медленный, запутанный или вообще отсутствует. Такой обходной путь ослабляет ответственность и потом сильно усложняет наведение порядка.

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

Частота тоже имеет значение. Если одна и та же команда отправляет один и тот же запрос каждую неделю, считайте это пробелом в доступе, а не обычной задачей поддержки. Простая метка в системе тикетов помогает. Достаточно ярлыков вроде «исключение по доступу», «общий логин» и «повторяющаяся проблема роли». Они не должны быть умными. Они должны просто помогать замечать закономерности, пока плохая привычка не стала нормой.

Группируйте запросы до изменения доступа

Если менять доступ по одному тикету, беспорядка обычно становится только больше. В очереди поддержки могут скрываться две очень разные проблемы: редкий нестандартный случай или правило доступа, которое каждый день блокирует людей. Сначала сгруппируйте запросы, чтобы увидеть разницу.

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

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

Посмотрите назад на последние 30–60 дней и посчитайте, как часто появляется один и тот же запрос. Один тикет может выглядеть безобидно. Двенадцать похожих тикетов за шесть недель обычно указывают на плохое правило доступа, недостающую роль или процесс, который больше не соответствует тому, как люди работают.

Именно в этот момент тикеты поддержки перестают быть шумом и начинают становиться полезными операционными данными. Если три специалиста customer success просят об одном и том же исключении в одном и том же инструменте, команде не стоит продолжать выдавать разовые обходные решения. Нужно проверить, не слишком ли узкая роль для реальной работы.

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

Сначала отделяйте редкие исключения от ежедневных блокеров, а уже потом что-то меняйте. Редкий случай может потребовать ручного пути согласования. Ежедневный блокер обычно означает, что нужно изменить роль, создать новую группу прав или чётче разделить зоны ответственности между командами.

Простой процесс проверки

Начните с малого. Возьмите 15–25 недавних тикетов, где есть заблокированные действия, запросы на исключения или случаи, когда люди брали чужой аккаунт, чтобы сделать работу.

Такой выборки обычно хватает, чтобы увидеть закономерность, не превращая проверку в большой проект. И он помогает команде сосредоточиться на повторяющихся проблемах, а не на одном громком запросе.

Для каждого тикета ответьте на один простой вопрос: что человек на самом деле пытался закончить? Не останавливайтесь на кнопке или экране, который не открывался. Запишите реальную задачу, например оформить возврат, обновить адрес доставки или скачать отчёт по клиенту.

Затем сравните эту задачу с той ролью, которая есть у человека сейчас. Если роль называется «сотрудник поддержки», а в работе постоянно есть задачи по биллингу, несоответствие уже видно. Если три человека на одной роли просят одно и то же исключение, считайте это проблемой дизайна роли, а не личной просьбой.

Простой процесс проверки выглядит так:

1. Выберите одну недавнюю группу тикетов от одной команды.
2. Запишите заблокированную задачу простыми словами для каждого тикета.
3. Проверьте, должна ли текущая роль уже покрывать эту задачу.
4. Предложите самое маленькое изменение доступа, которое позволит выполнить задачу.
5. Протестируйте это на одной команде в течение недели или двух.

Самое маленькое изменение — это важно. Если сотрудникам нужен один отчёт, дайте доступ именно к этому отчёту или группе отчётов, а не широкую админскую роль. Если им нужно утверждать скидки до определённого лимита, задайте этот лимит вместо того, чтобы открывать все настройки цен.

Во время теста следите за количеством тикетов, числом ошибок и новыми исключениями, которые появляются. Спросите команду прямо: «Это убрало обходной путь и не создало новой путаницы?»

Типичный пример — растущая команда поддержки. Сотрудники просят менеджера войти в систему и оформить клиентские кредиты, потому что их роль заканчивается на режиме только для чтения в биллинге. Исправление редко состоит в полном доступе к биллингу. Обычно нужен узкий допуск, который позволяет роли поддержки создавать небольшие кредиты в заданных пределах, а крупные суммы по-прежнему уходят в финансы.

Если пилот сработал, обновите шаблон роли, а не только тех, кто первым пожаловался. Так временное исключение превращается в аккуратное исправление прав.

Превратите закономерности в исправления доступа

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

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

Полезная модель доступа разделяет действия, которые люди по привычке часто смешивают:

• Просмотр данных
• Редактирование записей
• Подтверждение изменений
• Экспорт данных

Такое разделение убирает много шумных запросов на исключения. Тому, кто должен проверять счёт, не нужны права на утверждение. Тот, кто может одобрить возврат, не должен автоматически иметь возможность выгружать списки клиентов.

Общие логины нужно сразу пресекать. Команды обычно создают их для ночных смен, отпусков или загруженных периодов. Краткосрочный выход кажется удобным, но он скрывает, кто что сделал, и раздаёт доступ намного шире, чем это было нужно изначально. Лучше работает запасная роль. Подойдёт и роль по сменам с узким набором прав, которая включается только тогда, когда эта команда на дежурстве.

Краткосрочные исключения тоже должны иметь владельца. Решите, кто может их одобрять, что считается уважительной причиной и когда дополнительный доступ заканчивается. Если за это никто не отвечает, временный доступ из-за бездействия становится постоянным.

Небольшой пример хорошо это показывает. Если служба поддержки по выходным постоянно просит использовать аккаунт финансового отдела, чтобы повторно отправлять счета, это не значит, что поддержке нужен полный доступ к финансам. Это значит, что системе нужна ограниченная роль, которая позволяет видеть статус биллинга и повторно отправлять одобренные счета, но не менять платёжные данные и не выгружать записи.

Записывайте эти исправления простым языком. У каждой роли должны быть три простых ответа: какую задачу она покрывает, кто её получает и чего она делать не может. Так будущие изменения остаются честными, а старым обходным путям сложнее вернуться.

Короткий пример из растущей команды

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

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

Очередь это временно разгрузило, но создало две новые проблемы. У компании пропал понятный след в аудите, а лиды тратили часть каждой смены на роль живого моста доступа. Простой возврат стал занимать трёх человек вместо одного.

Менеджер взял тикеты за две недели и поискал повторы. У большинства запросов была одна и та же форма: сотрудникам нужно было оформлять небольшие возвраты по правилам, не трогая настройки биллинга и данные клиентского аккаунта. Значит, команде был нужен не широкий админский доступ, а одна недостающая роль.

Они добавили роль для выходных возвратов с жёсткими ограничениями. Сотрудники в этой группе могли смотреть историю заказов и оформлять возвраты в пределах заданной суммы. Они не могли менять способы оплаты, редактировать профили клиентов или открывать финансовые инструменты вне экрана возврата.

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

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

Вот за таким сигналом и стоит следить. Если люди снова и снова просят об одном и том же исключении, они часто описывают недостающую роль точнее, чем это делает текущая политика.

Ошибки, которые только усугубляют проблему

Большинство проблем с доступом в тикетах поддержки начинаются не со злого умысла. Они начинаются с быстрого решения, которое кажется безобидным. Менеджер хочет, чтобы жалобы прекратились, поддержка хочет, чтобы очередь двигалась, и кто-то получает широкий админский доступ «только пока». Такой обходной путь часто остаётся на месяцы.

Широкий доступ создаёт сразу две проблемы. Люди видят или меняют больше, чем нужно для их работы, а у команды пропадает стимул исправлять правила ролей, потому что количество тикетов падает по неправильной причине.

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

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

Повторяющиеся срочные запросы тоже требуют внимания. Если поддержка каждый месяц видит одинаковый тикет «нужен доступ сегодня», это уже не исключение. Правило неверное, либо в роли не хватает того, что людям реально нужно для работы.

Некоторые команды ещё и упускают самую рискованную группу: подрядчиков, временных сотрудников, стажёров и людей, которые на день закрывают чужую смену. В таких случаях чаще всего появляются общие логины или неформальный обмен аккаунтами. Это может сохранить темп работы, но разрушает ответственность.

Старые права тоже задерживаются. Кто-то переходит из продаж в операции и сохраняет оба набора доступов. Кто-то уходит из проекта, но ещё недели спустя открывает его инструменты. Поддержка часто замечает это раньше остальных, потому что история тикетов всё показывает.

Если сотрудники просят одно и то же исключение больше одного раза, согласующие дают устное разрешение, не обновляя роль, временные сотрудники пользуются чужими аккаунтами или тот же запрос возвращается на следующей неделе, командe стоит перестать считать такие тикеты обычными. Их нужно выносить в список на проверку.

Быстрая проверка перед запуском

Изменение доступа должно позволять нужному человеку закончить работу без нового тикета на следующий день. Если поддержке всё ещё нужно просить помощи у лида, значит, исправление слишком маленькое или затрагивает не тот шаг.

Проверяйте реальную задачу, а не формулировку запроса. Человек может просить «полный доступ», хотя ему нужно только повторно отправить счёт, оформить возврат или обновить одно поле клиента. Давайте доступ к действию, которое ему действительно нужно, а не ко всей зоне вокруг него.

Перед запуском задайте пять вопросов:

• Может ли человек завершить задачу от начала до конца без участия коллеги?
• Даёт ли изменение только нужное действие и ничего лишнего?
• Может ли менеджер одобрить доступ по одному понятному правилу вместо расплывчатого исключения?
• Может ли команда быстро убрать или ограничить доступ, если заметит злоупотребление или плохой побочный эффект?
• Не упрётся ли ночная и выходная смена в тот же блок, потому что исправление работает только когда нужные люди онлайн?

Чёткие правила согласования важнее, чем многие ожидают. «Лиды поддержки могут оформлять возвраты до 200 долларов» — это понятно. «Доверенные сотрудники могут работать с биллингом» — нет.

Быстрый откат тоже важен. Если вы не можете убрать изменение за минуту-две, рискованный доступ может остаться дольше, чем планировалось. Так временные исключения и становятся обычной практикой.

Простой пример: сотрудник поддержки не может отменять дублирующиеся заказы после 18:00, поэтому просит сделать это инженера. Решение — не админский доступ. Решение — узкое право, которое позволяет обученным сотрудникам поддержки отменять дублирующиеся заказы с одобрением менеджера и с простой возможностью отключить это право.

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

Что делать дальше

Не начинайте с полной переписки политики. Начните с типа запроса, который чаще всего встречался в прошлом месяце. Если один и тот же запрос на доступ появился 12 раз, это обычно проблема роли, а не обучения.

Возьмите небольшую подборку недавних тикетов и поищите повторы. Общие пароли, согласования только через менеджера и разовые запросы на выгрузку часто указывают на одно и то же: людям нужно делать часть своей работы, но роль этого не позволяет.

Затем назначьте короткую встречу с одним лидом поддержки и одним лидом операций. Двадцати минут достаточно, если принести реальные примеры. Прочитайте вслух несколько тикетов и задайте три вопроса: что было заблокировано, какой обходной путь использовали люди и кому пришлось вмешаться.

После этого исправьте один повторяющийся обходной путь и оформите его как одно изменение в доступе. Держите решение маленьким и конкретным. Если сотрудники постоянно берут общий логин, чтобы смотреть статус заказа, замените это нормальной ролью, которая даёт доступ только для чтения к экрану заказа. Запишите, кому выдаётся роль, какое действие она разрешает, кто её одобряет и когда вы пересмотрите её снова.

Это работает лучше, чем расплывчатое обещание позже навести порядок в правах. Маленькие исправления быстро снижают количество тикетов и одновременно уменьшают риск того, что общие логины станут нормой.

После запуска изменения наблюдайте за тем же типом запроса две недели. Если тикеты падают, переходите к следующему повторяющемуся шаблону. Если нет, проблема может быть выше — в дизайне ролей или в правилах согласования.

Если такие проблемы распределены между поддержкой, операциями и финансами, может помочь человек, который работал и с техническими системами, и с повседневным дизайном процессов. Oleg Sotnikov на oleg.is делает такую работу как Fractional CTO, помогая небольшим и средним командам настраивать роли, согласования и внутренние процессы без переворота всей системы.

Цель простая: дать людям возможность выполнять обычную работу в своих аккаунтах и в понятных рамках.