Не знаю, кому написать: как организовать внутреннюю поддержку сотрудников в крупной компании

В понедельник сотруднику понадобился доступ к корпоративной системе. Он написал руководителю, тот отправил его в IT. Там попросили согласование службы безопасности. Безопасность уточнила, какие права нужны, на какую систему и кто её владелец. К среде участники переписки разобрались, кто должен согласовать заявку. Доступа пока нет, работа стоит, зато сотрудник уже многое узнал об устройстве компании.

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

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

Почему обращения теряются между подразделениями

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

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

Проблемы здесь разные, хотя сотрудник описывает их одинаково: «Не могу добиться ответа».

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

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

Единое окно: один вход, разные исполнители

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

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

После выбора ситуации возможны три пути:

1. Сотрудник получает инструкцию и решает вопрос самостоятельно.

2. Обращение поступает в ответственную службу.

3. Создаётся общий запрос, внутри которого связаны действия нескольких подразделений.

Единое окно не требует собирать IT, HR и бухгалтерию в один отдел. Оно требует согласовать вход, передачу обращений и ответственность за результат.

Как распределить типовые запросы

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

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

Кто отвечает за запрос, если участвуют три службы

В процессе стоит разделить три роли:

• владелец услуги определяет, как она оказывается: какие данные нужны, кто согласует, какие сроки действуют;

• ответственный за обращение следит за конкретным запросом и сообщает сотруднику о ходе работы;

• исполнители выполняют отдельные действия: согласуют права, настраивают учётную запись, проверяют результат.

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

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

Разберём спор: IT отправляет к владельцу системы, а тот возвращает в IT

Сотрудник запросил доступ к отчётам. IT готов выдать права, но не знает, какая роль допустима. Владелец системы отвечает: «Пусть IT определит техническую группу». Заявка начинает ходить между очередями.

В предлагаемой схеме это разбирается так:

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

2. Владелец системы подтверждает, какие действия сотруднику разрешены.

3. IT сопоставляет эти полномочия с технической ролью и назначает её.

4. Если стороны не договорились, вопрос передаётся владельцу услуги или руководителям, указанным в порядке эскалации.

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

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

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

Как настроить маршруты, сроки и статусы

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

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

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

Не путайте приоритет с настойчивостью

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

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

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

Сохраняйте общий срок и время отдельных этапов

Для запроса доступа полезно видеть две картины:

• сколько сотрудник ждёт от отправки заявки до возможности работать;

• сколько заняли уточнение данных, согласование и техническая реализация, если она нужна.

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

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

Показывайте следующий шаг

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

Из этапа проверки возможен переход в ожидание уточнений. Из согласования — эскалация или мотивированный отказ.

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

Какие вопросы отдавать в самообслуживание

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

Но инструкция «Как получить доступ» не выдаёт права. Она объясняет условия и помогает правильно начать процесс.

В нашем примере материал должен отвечать на практические вопросы:

• кто может запросить доступ;

• какие сведения потребуются;

• как описать нужные действия в системе;

• какие согласования предусмотрены;

• где проверить статус;

• что делать, если доступ выдан, но нужная функция не появилась.

Организуйте материалы по ситуациям

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

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

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

Встройте поиск ответа в путь обращения

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

Чтение материалов не должно становиться обязательным препятствием. Иначе человек с нестандартной проблемой будет нажимать случайные ответы, чтобы наконец добраться до специалиста.

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

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

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

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

Обновляйте знания по результатам обращений

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

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

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

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

Как понять, что поддержка стала работать лучше

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

Сначала зафиксируйте определения метрик, затем сравнивайте одинаковые категории и приоритеты.

Для самостоятельных решений можно собирать подтверждение «Удалось решить задачу?» и проверять, не последовала ли затем заявка по той же теме. Такая оценка всё равно будет неполной: часть пользователей не отвечает. Поэтому рядом с долей успешных ответов нужно показывать охват опроса.

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

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

Условный расчёт: сколько времени уходит на лишние действия

Предположим, поддержка обрабатывает 1 000 обращений в месяц. Сравним два периода с одинаковым объёмом и составом запросов.

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

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

Как внедрять единое окно без запуска на всю компанию сразу

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

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

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

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

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

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

Чем должна закончиться история с доступом

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

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

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

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

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

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