Регламент первой линии: документ, после которого поддержка не зависит от человека

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

Что входит в регламент

• Каналы и часы покрытия: где принимаем обращения, в какое время, что происходит вне этого времени.
• Категории обращений: вопрос, дефект, запрос функции, жалоба, финансовый вопрос — с примерами и признаками каждой.
• Зоны ответственности: что первая линия решает сама, что передаёт дальше и кому — по каждой категории.
• Сроки: время первого ответа и время решения по категориям; что считается решённым обращением.
• Тон и шаблоны: обращение на «вы» или «ты», подпись, шаблоны типовых ответов на каждом языке.
• Эскалация: как оформляется передача дефекта в разработку — с шагами воспроизведения, окружением и severity; как передаются финансовые и юридические вопросы.
• Запрещённое: что первая линия не обещает и не делает — возвраты без подтверждения, сроки исправления, юридические оценки.
• Отчётность: что считается еженедельно — объём, темы, время ответа и решения, доля эскалаций.

Категории и правила для каждой

Главная ошибка регламентов — описывать процесс в целом, а не по категориям. Вопрос «как сменить пароль» и жалоба «списали дважды» требуют разных действий, сроков и прав. Рабочий регламент — таблица: категория, признаки, что делает первая линия, кому передаёт, срок, шаблон ответа. Пяти-семи категорий достаточно почти любому продукту.

1. Вопрос по продукту: ответ из базы знаний в пределах срока первого ответа; если ответа нет — уточнение у команды и дополнение базы.
2. Дефект: воспроизведение по шагам пользователя, тикет в трекер с severity, промежуточный ответ пользователю, уведомление после исправления.
3. Запрос функции: благодарность, запись в бэклог идей, без обещаний по срокам.
4. Жалоба: ответ в сжатый срок, эскалация ответственному, контроль закрытия.
5. Финансовый вопрос: сбор данных операции, передача ответственному, промежуточный ответ в пределах SLA, никаких обещаний возврата до решения.

Сроки, которые работают

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

Как регламент живёт

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