Сервисный каталог внутри компании: как описать услуги, SLA и ответственность

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

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

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

Короткий вывод

• Сервисный каталог нужен не для красивого регламента, а для того, чтобы сотрудник понимал, куда обратиться и что будет дальше.
• Начинать стоит с частых и болезненных услуг: доступы, документы, счета, заявки клиентов, согласования, закупки, внутренние обращения.
• Каждая услуга должна иметь владельца, входные данные, маршрут, срок реакции, срок исполнения и понятный результат.
• SLA работает только тогда, когда связан с реальными статусами задач, а не висит отдельной таблицей.
• Каталог снижает количество хаотичных сообщений в чатах, но не отменяет живое общение: он задает правила входа и контроля.
• Хороший каталог растет итерациями: сначала 10-20 услуг, затем расширение по отделам и автоматизация повторяемых маршрутов.
• Если каталог не привязан к отчетам и ответственности, он быстро превращается в справочник, которым никто не пользуется.

Что такое сервисный каталог простыми словами

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

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

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

Зачем сервисный каталог собственнику и руководителям

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

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

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

Какие услуги включать в первую версию

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

Типовые услуги для первого запуска

• IT и доступы: создать учетную запись, восстановить пароль, выдать доступ к сервису, подключить оборудование, настроить рабочее место.
• Финансы и документы: выставить счет, проверить оплату, подготовить акт, согласовать договор, уточнить реквизиты, оформить возврат.
• Продажи и клиентский контур: подготовить коммерческое предложение, согласовать скидку, передать клиента в исполнение, зарегистрировать претензию, уточнить статус заказа.
• Проекты и производство: принять задачу в работу, запросить материалы, согласовать изменение объема, передать результат на проверку.
• HR и административные процессы: оформить отпуск, запросить справку, согласовать командировку, подготовить место для нового сотрудника.
• Маркетинг: подготовить материал, обновить страницу, согласовать публикацию, запросить дизайн или аналитику.

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

Карточка услуги: какие поля обязательны

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

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

SLA без бюрократии: как задать сроки, которые работают

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

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

Пример SLA для разных услуг

SLA должен жить не в отдельном файле, а внутри статусов и отчетов. Если заявка просрочена, система должна показать это автоматически. Если срок приостановлен из-за ожидания данных от заявителя, это тоже должно быть видно. Иначе руководитель снова возвращается к ручной проверке.

Как связать каталог с задачами и ответственностью

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

Если услуга требует одного действия, достаточно простой задачи. Если есть несколько этапов, нужен маршрут: «Новая», «На уточнении», «В работе», «На согласовании», «Готово», «Отклонено». Если услуга затрагивает клиента, ее нужно связать с CRM или клиентским контуром. Если услуга повторяется по проектам, ее стоит связать с проектной карточкой или шаблоном.

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

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

Матрица выбора: какие услуги автоматизировать первыми

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

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

Пошаговый план внедрения

Шаг 1. Собрать реальные обращения

Не начинайте с идеальной структуры. Возьмите 2-4 недели реальных запросов из чатов, почты, CRM, задач и устных обращений. Сгруппируйте их по смыслу: доступы, документы, согласования, клиентские вопросы, закупки, внутренние консультации. Важно видеть не только название запроса, но и кто его задает, кому передает, где возникает задержка и чем завершается работа.

Шаг 2. Выбрать 10-20 услуг для пилота

Пилот должен быть достаточно заметным, но не бесконечным. Хорошо работают услуги на стыке отделов: продажи — финансы, продажи — исполнение, HR — руководители, IT — вся команда, поддержка — продукт или производство. Именно там чаще всего теряются сроки и ответственность.

Шаг 3. Описать карточки услуг

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

Шаг 4. Настроить единый вход

Единый вход не означает, что все сотрудники перестанут общаться в чатах. Он означает, что результат запроса фиксируется в системе. Заявку можно создать из формы, письма, CRM, чата или вручную, но дальше она должна жить в едином контуре. Для первичного запуска можно использовать понятный интерфейс ВЕБОФИС и постепенно добавлять автоматические правила.

Шаг 5. Привязать SLA и отчеты

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

Шаг 6. Запустить обучение и обратную связь

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

Пример: счет, договор и закрывающие документы

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

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

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

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

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

В каталоге услуга может называться «Подготовить рабочее место нового сотрудника». Внутри формы указываются ФИО, дата выхода, отдел, роль, руководитель, список систем, оборудование, почта, доступы, документы. Заявка может порождать несколько задач: IT, HR, бухгалтерия, руководитель отдела. Владелец услуги отвечает за то, чтобы процесс в целом был завершен до даты выхода.

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

Где здесь может помочь ИИ

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

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

Как применить в ВЕБОФИС

В ВЕБОФИС сервисный каталог можно собрать как связку разделов: карточки услуг, формы заявок, задачи, статусы, SLA, уведомления, база знаний и отчеты. Для небольшого бизнеса это можно начать без тяжелого проекта: выбрать несколько отделов, описать первые услуги, настроить единый вход и вывести руководителю простую панель контроля.

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

Контекстный следующий шаг: выберите один отдел, где чаще всего теряются внутренние запросы, и соберите 15 последних обращений. По ним уже можно построить первую версию каталога, не споря о теории. Если нужна система, где заявки, задачи, SLA и отчеты будут связаны в одном контуре, ВЕБОФИС можно использовать как основу пилота.

Ошибки и риски

Ошибка 1. Делать каталог как справочник, а не как рабочий процесс

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

Ошибка 2. Ставить одинаковые сроки на все услуги

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

Ошибка 3. Описывать услуги языком отдела, а не заявителя

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

Ошибка 4. Не назначать владельца услуги

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

Ошибка 5. Автоматизировать хаос без упрощения

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

Ошибка 6. Не показывать пользу сотрудникам

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

Чеклист запуска сервисного каталога

• Собраны реальные обращения из чатов, почты, задач и CRM за последние недели.
• Выбраны 10-20 услуг для первого пилота.
• Для каждой услуги назначен владелец.
• Определены обязательные поля заявки и список типовых вложений.
• Описаны статусы, маршрут, условия возврата на уточнение и закрытия.
• Заданы сроки реакции, исполнения и эскалации.
• Каталог связан с задачами или заявками, а не существует отдельным документом.
• Настроен отчет по количеству, срокам, просрочкам и причинам возврата.
• Подготовлены короткие инструкции для сотрудников и владельцев услуг.
• Запланирован пересмотр каталога после первых 2-4 недель работы.

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

FAQ

Чем сервисный каталог отличается от базы знаний?

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

Нужен ли сервисный каталог малому бизнесу?

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

Можно ли вести каталог в таблице?

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

Кто должен владеть сервисным каталогом?

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

Сколько услуг включать в первую версию?

Оптимально начать с 10-20 услуг. Этого достаточно, чтобы увидеть эффект и не перегрузить команду описанием всего бизнеса. После пилота каталог можно расширять по отделам.

Что делать, если сотрудники продолжают писать в личные сообщения?

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

Как понять, что каталог работает?

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

Можно ли подключить ИИ к сервисному каталогу?

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