Автор: Антон Семенов, аналитик Битрикс24 в Cloudway

кейсы

Часть общей IT-стратегии: Настройка внутренней службы поддержки — это не разовая техническая задача. Это часть глобальной архитектуры портала, логику которой мы подробно разбираем в нашей методологии про внедрение Битрикс24.

Кастомная разработка vs Готовые модули: Использование встроенного инструмента «Смарт-процессы» дает абсолютную гибкость и безопасность данных по сравнению с покупкой коробочных приложений из Маркетплейса.

Постепенное масштабирование: Внедрение внутреннего сервиса всегда начинается с самых загруженных отделов (IT и АХО), чтобы отработать матрицу SLA, и только потом масштабируется на HR, бухгалтерию и юристов.

Четкое разделение понятий: Help Desk — это внешний контур для работы с вашими клиентами. Service Desk — это внутренний контур для обслуживания собственных сотрудников (B2E). Инструменты для них нужны разные.

Архитектура SLA, а не трекер задач: Service Desk на базе смарт-процессов — это жесткий конвейер с автоматическим контролем сроков (SLA) и эскалацией, а не просто доска с карточками, где заявки могут висеть неделями.

Главное за 30 секунд:

Service Desk требует каталога услуг. Сотрудник должен не просто написать свободный текст в чат, а выбрать категорию проблемы из классификатора. Именно поэтому для Service Desk в Битрикс24 используется инструмент «Смарт-процессы», позволяющий создать изолированную, настраиваемую среду с жесткими карточками и обязательными полями.

Service Desk (Внутренняя поддержка) направлен на ваших собственных сотрудников (B2E — Business-to-Employee). Сотрудник пишет IT-отделу: «У меня сломался компьютер». И здесь чаты и Открытые линии не работают. Почему? Потому что IT-специалисту для решения проблемы нужен не просто факт обращения, а жесткая структурированная форма:

• Какой именно компьютер? (Инвентарный номер).
• В каком офисе и кабинете?
• Какое описание проблемы?
• Какова критичность сбоя? (Остановилась работа всего отдела или просто не печатает принтер).

Help Desk (Внешняя поддержка) направлен на клиентов компании (B2B или B2C). Клиент пишет вам в мессенджеры или на почту: «У меня не работает ваш продукт, помогите решить проблему». В Битрикс24 эта задача идеально решается стандартным модулем «Открытые линии» и классической воронкой Лидов или Сделок. Клиенту не нужен сложный интерфейс — ему нужен быстрый ответ в том мессенджере, где ему удобно.

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

За каждой строчкой каталога должен быть закреплен конкретный исполнитель (или роль). Если сотрудник выбирает «Доступ к 1С», заявка автоматически улетает программисту 1С. Если выбирает «Не работает мышка» — заявка падает на младшего эникейщика. Здесь же закладывается базовый приоритет: падение сервера — это всегда «Критический» приоритет, а выдача новой клавиатуры — «Низкий», независимо от того, насколько сильно торопится сотрудник.

Мы всегда начинаем с IT-отдела (техническая поддержка) или АХО (административно-хозяйственный отдел). Причина прагматична: именно в этих отделах генерируется 80% типовых, предсказуемых, повторяющихся запросов.
Замена картриджа, выдача доступов к 1С, починка кондиционера, заказ пропусков для гостей — это алгоритмичные процессы. На них проще всего отработать механику SLA (сроков реакции) и приучить компанию к тому, что «заявки через Telegram больше не принимаются».

Шаг 3. Настройка маршрутизации и приоритетов

Искусственный интеллект и роботы Битрикс24 не смогут распределять заявки, если сотрудники пишут в свободной форме. Вам необходим жесткий классификатор (справочник).
Например, для IT-отдела он выглядит так:

• Группа 1: Доступы и учетные записи (Подгруппы: ERP, Почта, Битрикс24, 1С).
• Группа 2: Оборудование (Подгруппы: ПК/Ноутбук, Периферия, Принтеры/МФУ).
• Группа 3: Сеть и телефония.

Шаг 2. Разработка каталога типовых обращений

Шаг 1. Выбор пилотного подразделения (IT или АХО)

Если вы попытаетесь в первый же день загнать в Service Desk все отделы компании (юристов, безопасников, кадровиков, бухгалтерию), система рухнет под весом собственной бюрократии. Внедрение внутреннего сервиса — это инженерный процесс, требующий последовательности.

Сотрудник пишет сисадмину в личные сообщения: «Вася, у меня 1С висит, срочно!». Вася в этот момент тянет кабель на складе. Он читает сообщение, смахивает уведомление и забывает. Контроля нет. Эскалации руководству нет. Сотрудник сидит час и не может выставить счет клиенту. Бизнес теряет деньги на простое, а аналитики не могут посчитать, сколько реально заявок закрывает сисадмин Вася в месяц.

Руководство выпускает приказ: «Все заявки ставить через Задачи». Но стандартная задача в Битрикс24 слишком гибка. Сотрудник ставит задачу на системного администратора, пишет в названии «Помогите», не прикрепляет скриншот ошибки и ставит крайний срок «Вчера».

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

Service Desk устраняет этот человеческий фактор. Система ведет пользователя по жесткому коридору.

Иллюзия стандартных задач:

Иллюзия чатов (Telegram / Внутренний чат Битрикс24):

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

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

Рядовой сотрудник вообще не должен видеть сложную канбан-доску сисадминов. В идеальной архитектуре мы выводим кнопку «Создать заявку» прямо в левое меню Битрикс24 или на главную страницу Битрикс24. По клику открывается простая, интуитивная CRM-форма. Подробнее про “Наш вайб” Битрикс24 читайте в нашей статье.
В ней настроена зависимость полей: сотрудник выбирает отдел «АХО», и система показывает ему выпадающий список проблем АХО. Выбирает «IT» — появляются поля для скриншотов и выбора программы. Как только форма отправлена, смарт-процесс генерирует карточку тикета.

4. Управленческая аналитика (BI-дашборды)

Система не ждет, пока заявка просрочится. Настроены триггеры предупреждения:

• Осталось 20% времени SLA — робот отправляет ответственному специалисту агрессивный push в чат.
• SLA просрочен на 1 минуту — робот меняет стадию тикета на «Просрочено» и автоматически ставит задачу-разбирательство на руководителя отдела (IT-директора или начальника АХО).
• Это радикально меняет дисциплину в обслуживающих подразделениях.

3. Жесткая эскалация (Автоматический контроль)

Ключевое правило: пользователь никогда не ставит сроки сам. Сроки и приоритет вычисляются роботами Битрикс24 на основе выбранной категории из каталога.
В смарт-процесс заложены сроки SLA (Service Level Agreement).

• Если категория «Падение 1С», система сама ставит приоритет «Критический», срок реакции (взятия в работу) — 15 минут, срок решения — 2 часа.
• Если категория «Справка 2-НДФЛ», приоритет «Низкий», срок решения — 3 рабочих дня.
• Роботы умеют учитывать производственный календарь: заявка, поданная в пятницу в 17:50 со сроком решения 4 часа, должна быть закрыта в понедельник к 11:50, а не просрочена в ночь на субботу.

2. Автоприоритет и расчет сроков (Математика)

1. Единая форма приёма обращений (Главная страница Битрикс24)

Смарт-процессы (Smart Processes) — это инструмент Битрикс24, позволяющий создавать собственные, полностью изолированные рабочие пространства со своей воронкой (канбаном), своими карточками и своими роботами.

Мы проектируем Service Desk на базе смарт-процессов из четырех фундаментальных блоков.

Когда логика отработана на IT-отделе, смарт-процессы легко масштабируются на другие обслуживающие подразделения. Мы создаем для каждого отдела свой изолированный смарт-процесс (свою доску), чтобы заявки на ремонт стульев не смешивались с запросами на расчетные листы.

В Маркетплейсе Битрикс24 десятки готовых приложений класса «Helpdesk / Тикет-система». Возникает резонный вопрос: зачем настраивать смарт-процессы, если можно установить готовый модуль по подписке?
Ответ кроется в гибкости, масштабировании и безопасности данных корпоративного уровня.

3. Управленческие решения: Через два месяца BI-дашборд математически доказал руководству завода, что 40% рабочего времени IT-отдел тратит на реанимацию старых ТСД на складе готовой продукции. Опираясь на эти твердые цифры, компания списала оборудование и закупила новую партию терминалов, что оказалось кратно дешевле, чем оплачивать часы постоянного ремонта.

2. Дисциплина (Эскалация): Роботы полностью исключили потерю ночных заявок. Если тикет не брали в работу вовремя, система автоматически эскалировала проблему на уровень технического директора для служебного расследования.

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

Измеримый результат:

Проблема: IT-отдел и служба эксплуатации (АХО) задыхались в неконтролируемом потоке обращений. Когда на складе ломался принтер этикеток или зависал компьютер на посту мастера цеха, начальник смены просто звонил сисадмину на личный мобильный. Если сисадмин был на другом объекте, линия останавливалась. Ночные смены оставляли заявки на обрывках бумаги. Среднее время реакции на критический сбой составляло от 2 до 4 часов. Руководство не могло посчитать реальную стоимость технического простоя и не понимало, чем фактически загружены инженеры.

Решение на смарт-процессах:
Мы жестко отключили прием заявок по телефону и через мессенджеры. На портале были спроектированы два изолированных смарт-процесса: «Service Desk IT» и «Service Desk Эксплуатация». На рабочих терминалах в цехах и у начальников смен вывели единую кнопку «Сообщить о поломке». По клику открывалась адаптивная CRM-форма с обязательными зависимыми полями: цех, инвентарный номер станка или ПК, категория проблемы.

Мы настроили матричную маршрутизацию. Заявка на замену картриджа улетала младшему эникейщику, а сбой в работе терминала сбора данных (ТСД) мгновенно назначался на дежурного старшего инженера. Роботы контролировали SLA: на критические сбои (остановка отгрузки) давалось 15 минут на реакцию с автоматическим push-уведомлением и звонком на телефон дежурного.

Внедрение правильной архитектуры всегда дает измеримый финансовый результат. Рассмотрим наш проект для регионального завода, выпускающего промышленное оборудование (название скрыто по условиям NDA). В штате 350 сотрудников, производство работает в режиме 24/7, есть три крупных цеха, складской комплекс и бэк-офис.