Маршрутизация заявок с корпоративного сайта: карта сценариев и правила распределения

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

Что входит в маршрутизацию заявок и где её границы

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

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

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

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

Исходные данные и ответственные за правила

Прежде чем что-то настраивать, соберите входные данные. Нужен перечень страниц с формами и понимание, чем эти страницы отличаются по смыслу. Нужен список филиалов или направлений с реальными адресами и названиями — фиктивные адреса в такой схеме недопустимы, иначе заявка уйдёт в никуда. Нужен список ролей получателей и их зон ответственности.

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

Ответственные делятся на три уровня. Владелец правил — тот, кто утверждает матрицу и меняет её при появлении новых услуг или филиалов. Администратор — тот, кто вносит изменения в настройки и проверяет, что они применились. Получатели — те, кто обрабатывает заявки и сообщает, если что-то приходит не туда. Без владельца правил матрица превращается в набор разовых договорённостей.

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

Варианты распределения и критерии выбора

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

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

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

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

Предметная последовательность действий

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

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

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

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

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

Матрица «сценарий → поля → получатель → срок → потеря»

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

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

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

Учебный пример: как это выглядит на практике

Учебный пример. Компания с тремя филиалами и двумя направлениями услуг обновляет корпоративный сайт. Формы есть на страницах услуг, направлений и филиалов. Задача — чтобы заявка попадала нужному адресату и не терялась. Данные о компании и количестве объектов условные.

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

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

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

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

Как связать формы, уведомления и фиксацию статуса

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

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

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

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

Типичные ошибки и ограничения схемы

Одна из частых ошибок — правила описаны, но не назначен владелец. Через некоторое время появляется новая услуга или филиал, правило не обновляется, и заявка уходит не туда. Вторая ошибка — получатель указан как отдел, а не как роль или человек. В отделе может не быть ответственного, и заявка зависает.

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

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

Если сайт только создаётся, маршрутизацию удобнее закладывать вместе с разработкой. В этом случае стоит обсудить разработку корпоративных сайтов на 1С-Битрикс с учётом форм, ролей и статусов, чтобы не переделывать потом. Если сайт уже есть, начните с матрицы и тестовых заявок.

Чек-лист приёмки маршрутизации

Перед тем как считать задачу выполненной, пройдите по пунктам. Чек-лист помогает не пропустить шаги и зафиксировать результат.

• Для каждого сценария обращения указаны поля формы, получатель, срок реакции и признак потери.
• Все филиалы и направления в матрице соответствуют реальным адресам и названиям.
• У каждого получателя есть роль или конкретный ответственный, а не абстрактный отдел.
• Для нетиповых запросов предусмотрена общая очередь и ответственный за разбор.
• Статусы ведутся в одном месте и меняются при действии по заявке.
• Проведён тестовый прогон по одной заявке на каждый сценарий.
• Проверено поведение при отсутствии получателя: срабатывает эскалация или общая очередь.
• Назначен владелец правил и администратор, отвечающий за изменения.

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

Что делать дальше и как поддерживать схему

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

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

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

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