Регламент обработки заявок разваливается в первую же неделю, если в нём нет двух вещей: конкретного срока первого ответа и человека, который отвечает за каждый этап. Я собирал такие регламенты для служб поддержки на Tilda-сайтах, интернет-магазинов на WooCommerce и Telegram-ботов с очередью тикетов, и почти везде причина хаоса одна и та же: заявка приходит по трём каналам сразу, и никто не может сказать, кто её ведёт следующим. Ниже рабочая структура регламента: сроки по каналам, роли, приоритеты, эскалация и то, что из этого стоит автоматизировать, а что проще прописать словами.
Зачем нужен регламент обработки заявок: что он лечит на практике
Без письменного регламента каждый новый сотрудник поддержки придумывает свои правила: кто-то отвечает клиенту сразу, кто-то откладывает заявку на потом, если она кажется сложной. Итог - разброс времени ответа от пары минут до суток на похожие по сути обращения.
На практике регламент закрывает три задачи. Первая - клиент получает ответ в предсказуемое время, и это время можно проверить по логам чата, почты или CRM. Вторая - руководитель видит, на каком этапе застряла заявка и кто держит её у себя дольше срока. Третья - при увольнении или отпуске сотрудника заявки не зависают, потому что маршрут передачи прописан заранее, а не решается в момент, когда человек уже недоступен.
Отдельно регламент нужен, если заявки приходят из разных источников: форма на сайте, почта, Telegram-бот, звонок. Без единой точки входа часть обращений теряется - я видел это на проекте с WooCommerce, где заявки на возврат из формы на сайте и из личного кабинета попадали в разные почтовые ящики, и часть возвратов клиенты просто не дожидались, обращаясь в поддержку маркетплейса напрямую.
Срок первого ответа: нормативы по каналам
Срок первого ответа - не про решение вопроса, а про сам факт реакции: живой человек увидел заявку и дал понять, что её взяли в работу. Путать эти два срока - частая ошибка: менеджер отвечает клиенту через два дня уже с готовым решением и считает, что уложился, хотя по факту клиент два дня не знал, дошло ли обращение вообще.
В регламентах, которые я собираю для клиентов, нормативы по каналам обычно выглядят так:
| Канал | Норматив первого ответа |
|---|---|
| Онлайн-чат на сайте | 2-5 минут в рабочее время |
| Telegram-бот, мессенджер | до 15 минут |
| Электронная почта | 2-4 рабочих часа |
| Телефон, входящий звонок | до 30 секунд на снятие трубки |
| Тикет в CRM без приоритета | до 1 рабочего дня |
Цифры не универсальны: для интернет-магазина в высокий сезон 15 минут на Telegram могут быть недостижимы без второго дежурного, а для B2B-сервиса с квалифицированной поддержкой 4 часа на почту иногда избыточная роскошь, клиенты ждут быстрее. Смысл таблицы не в конкретных числах, а в том, что для каждого канала норматив должен быть зафиксирован отдельно, потому что ожидания клиента разные: от чата ждут ответа как от живого человека онлайн, от почты - как от почты.
Кто за что отвечает: роли в обработке заявки
Регламент без ролей превращается в список пожеланий. Я обычно развожу ответственность на четыре роли, даже если физически это два-три человека.
| Роль | Зона ответственности | Что проверяют по этой роли |
|---|---|---|
| Дежурный, первая линия | Принять заявку, дать первый ответ, определить приоритет | Соблюдение срока первого ответа |
| Ответственный исполнитель | Решить вопрос по существу или подготовить эскалацию | Срок решения по приоритету |
| Руководитель поддержки | Мониторинг очереди, разбор просрочек, конфликты между линиями | Число заявок, вышедших за срок |
| Владелец продукта или процесса | Решения по нетиповым заявкам, изменения в самом регламенте | Частота пересмотра регламента |
На небольшом проекте первая линия и исполнитель - один и тот же человек, и это нормально, если он физически успевает и снимать входящий поток, и закрывать сложные тикеты. Проблема начинается, когда роли совмещены, но нигде не прописаны: тогда просроченная заявка виснет без объяснений, потому что формально за неё отвечали все, а по факту никто. В регламентах я всегда указываю роль по имени или по должности, а не абстрактно «поддержка» - это единственный способ проверить исполнение через месяц.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Приоритеты заявок и сроки решения
Срок первого ответа - только часть регламента. Вторая часть - приоритет и срок решения, потому что заявка «не могу зайти в личный кабинет» и заявка «уточните цвет товара» не должны жить в одной очереди с одинаковым весом.
| Приоритет | Пример обращения | Срок первого ответа | Срок решения |
|---|---|---|---|
| Критический | Сайт или бот недоступен, оплата не проходит | до 15 минут | до 2 часов |
| Высокий | Ошибка в заказе, нет доступа к аккаунту | до 30 минут | до 1 рабочего дня |
| Обычный | Вопрос по товару, статусу доставки | до 2 часов | до 2 рабочих дней |
| Низкий | Пожелание, вопрос не по текущему заказу | до 1 рабочего дня | по договорённости |
Приоритет присваивает первая линия при приёме заявки, а не тот, кто её потом решает - иначе исполнитель будет откладывать неудобные тикеты, понижая приоритет задним числом. В регламенте стоит закрепить конкретный список признаков для каждого приоритета, чтобы решение не зависело от настроения дежурного: например, «оплата не проходит» всегда критический, а «не понимаю, как оформить возврат» всегда обычный, вне зависимости от тона письма клиента.
Эскалация заявок: когда и кому передавать
Эскалация - место, где регламенты чаще всего рвутся, потому что в них прописывают только «к кому идти», но забывают «через сколько».
Рабочая схема строится на трёх вопросах. Первый - какой признак запускает эскалацию: истёк срок первого ответа, истёк срок решения, или исполнитель сам понял, что вопрос не его уровня. Второй - куда идёт заявка: на руководителя линии, на другого специалиста той же линии или сразу на владельца продукта, если вопрос касается денег или репутации. Третий - что происходит с исходной заявкой: она передаётся целиком, с историей переписки и уже собранной информацией, а не открывается заново, потому что клиент, которого просят описать проблему ещё раз, теряет доверие быстрее, чем от долгого ожидания.
На практике эскалацию удобнее запускать не вручную, а по таймеру: если тикет висит в статусе «в работе» дольше срока по приоритету, система сама уведомляет руководителя, а не ждёт, пока дежурный вспомнит об этом.
Автоматизация регламента обработки заявок: боты и n8n
Часть регламента держится только на дисциплине сотрудников, а часть выгоднее переложить на автоматику, потому что человек забывает про таймеры, а скрипт нет.
На одном проекте я собирал aiogram-бота, который дублировал новую заявку из CRM в отдельный чат ответственного менеджера и присылал повторное уведомление, если по тикету не появлялось первого ответа за 15 минут. Это не заменяет регламент, но убирает самую частую причину просрочки: человек просто не заметил новую заявку среди остальных уведомлений.
Второй рабочий вариант - собрать воронку заявок в n8n: обращения из формы на сайте, почты и Telegram-бота попадают в один сценарий, размечаются по каналу и приоритету и уходят в общую очередь в CRM или таск-трекере вместо того, чтобы жить в трёх разных местах. Здесь же удобно вешать таймеры эскалации из предыдущего раздела - n8n сравнивает время создания тикета с нормативом по приоритету и присылает напоминание, если срок подходит к концу. Настройку такого сценария беру как отдельный проект от 25 000 ₽, срок обычно 1-2 недели в зависимости от количества каналов.
Если регламент нужно не просто описать на бумаге, а поддерживать в рабочем состоянии месяц за месяцем, дальше эта работа обычно уходит в формат сопровождения. Я веду такие проекты через техподдержку с контролем сроков по заявкам от 15 000 ₽ в месяц - в неё входит разбор просроченных тикетов и донастройка правил маршрутизации, когда меняется поток обращений.
Частые ошибки при внедрении регламента
Регламент, который живёт только в документе и никогда не открывается, не работает - это самая частая ошибка. Если сотрудники узнают о нормативах один раз на собеседовании, а потом файл лежит в общей папке без напоминаний, через месяц каждый вернётся к своей привычной скорости реакции.
Вторая ошибка - сроки без учёта рабочего времени. Норматив «2 часа на почту» бессмысленен, если не сказано, часы рабочие или календарные: заявка, отправленная в пятницу вечером, не должна считаться просроченной в субботу утром, если поддержка не работает по выходным.
Третья - один норматив на все каналы и все типы обращений. Я видел регламенты, где «15 минут на ответ» стоит и для чата на сайте, и для почты, и для комментария в соцсети - в результате норматив либо систематически нарушается на почте, либо искусственно завышается для чата, где клиент реально ждёт быстро.
Четвёртая - отсутствие метрики для проверки. Регламент без данных о том, сколько заявок реально уложились в срок, превращается в декларацию о намерениях. Даже простая таблица в CRM с двумя столбцами, время поступления и время первого ответа, уже даёт возможность раз в месяц смотреть, где регламент буксует.
Частые вопросы
За сколько времени нужно давать первый ответ на заявку?
Зависит от канала и приоритета. В своей практике я закладываю 2-5 минут для чата на сайте, до 15 минут для Telegram, 2-4 рабочих часа для почты и до 30 секунд на снятие трубки по телефону - но для критических обращений вроде недоступной оплаты срок сокращается до 15 минут независимо от канала.
Как проверить, кто из сотрудников не укладывается в норматив?
Нужны два таймстампа на каждую заявку: время поступления и время первого ответа. Их можно смотреть вручную в CRM раз в месяц или собирать автоматически через n8n, который сравнивает разницу с нормативом по приоритету и помечает просроченные тикеты.
Нужно ли фиксировать регламент письменно, если в поддержке два человека?
Да. При двух сотрудниках риск не в объёме заявок, а в том, что оба считают ответственным другого, когда один в отпуске или занят сложным тикетом. Даже короткий документ с ролями и сроками снимает этот конфликт.
Что делать, если заявки приходят из нескольких каналов и часть теряется?
Собрать все каналы в одну точку входа: форма на сайте, почта и Telegram-бот заводятся в один сценарий, который размечает заявку по источнику и приоритету и кладёт в общую очередь CRM. Это устраняет саму причину потерь - обращение, которое раньше уходило в отдельный почтовый ящик или личный чат сотрудника, теперь физически не может миновать общий список.