После запуска Битрикс24 работа с порталом только начинается. Появляются новые сотрудники, меняются воронки, добавляются роботы, подключается телефония и почта. Часть изменений — типовая настройка, часть — диагностика, часть вырастает в отдельную задачу на разработку. Чтобы это не превратилось в бесконечную переписку, нужен регламент поддержки.
Почему внедрение и поддержка — разные вещи
Внедрение задаёт стартовую конфигурацию: процессы, права, интеграции, миграцию данных. Поддержка ведёт уже работающий портал. Её задача — разобрать инцидент, внести согласованное изменение и проверить результат по рабочему сценарию.
Интегратор не принимает решения за бизнес. Он может диагностировать проблему, настроить робота или объяснить ограничение. Но этапы воронки, правила передачи сделок между отделами и обязательные поля утверждает владелец процесса со стороны заказчика.
Типы обращений в поддержку
Фраза «не работает робот» не определяет работу. Важно классифицировать запрос сразу:
| Тип | Суть | Пример |
|---|---|---|
| Инцидент | Нарушен рабочий сценарий | Сделка не переходит на следующий этап |
| Консультация | Нужно разобраться в текущей настройке | Менеджер не может изменить поле |
| Настройка | Меняется конфигурация в согласованных границах | Поле становится обязательным на стадии |
| Развитие процесса | Меняются роли, этапы или автоматизация | Новое согласование скидки |
| Отдельная разработка | Нужен код или нестандартная интеграция | Собственное приложение или сложная логика |
Граница между настройкой и разработкой зависит от портала. То, что похоже на мини-проект, не стоит оформлять как заявку в поддержку.
Что зафиксировать в SLA
SLA для Битрикс24 — это не обещание «ответим за пять минут». Это регламент прохождения запроса:
- Канал обращений — сервис-деск, задача или форма, но единый для всех.
- Инициаторы — кто вправе ставить и подтверждать запрос.
- Приоритет — по влиянию на процесс, а не по слову «срочно».
- Часы работы — когда обращения принимают и что делать вне них.
- Эскалация — когда подключают интегратора или разработчика.
- Приёмка — кто и по какому сценарию проверяет результат.
Единый канал нужен не для формальности. В личных сообщениях теряются история, вложения и статус. В карточке обращения должны остаться исходные данные, решение и результат проверки.
Роли в сопровождении
В небольшой компании несколько ролей может совмещать один человек, но полномочия должны быть чёткими:
- Заказчик/владелец процесса — утверждает правила, приоритеты и изменения, принимает результат.
- Администратор Битрикс24 — собирает обращения, проверяет настройки и права.
- Первая линия — регистрирует запрос, уточняет данные, передаёт дальше.
- Интегратор — диагностирует, выполняет настройки, оценивает изменения.
- Разработчик — подключается, когда нужен код или сложная интеграция.
Если разные сотрудники предлагают противоречащие изменения, решение принимает владелец процесса. Иначе поддержка не сможет выбрать, какую версию правил реализовывать.
Как оформить заявку
Хорошая карточка сокращает число уточнений. Полезный минимум:
- что нужно исправить, настроить или объяснить;
- тип обращения;
- описание проблемы или желаемого изменения;
- затронутый процесс и влияние на работу;
- шаги воспроизведения;
- фактический и ожидаемый результат;
- примеры записей, текст ошибки или скриншот;
- роли или пользователи, у которых воспроизводится проблема;
- срок, если привязан к событию;
- контакт для приёмки.
Не передавайте пароли, токены и внутренние идентификаторы в задачах и скриншотах. Доступы — только по согласованному безопасному каналу.
Порядок изменений в рабочем портале
Новое поле или робот может повлиять на отчёты, права и смежные процессы. Поэтому плановые изменения проходят этапы:
- Диагностика — уточняют процесс, настройки, права, роботов, интеграции.
- Оценка — определяют объём, зависимости, исходные данные, критерий готовности.
- Согласование — владелец процесса подтверждает новый порядок.
- Тест — проверяют по согласованным сценариям.
- Выпуск — переносят в рабочий портал.
- Контроль — пользователь проходит сценарий, результат фиксируют.
Метрики без фиктивных KPI
Метрики помогают увидеть повторяющиеся проблемы, но читаются только вместе с контекстом:
| Метрика | Что показывает |
|---|---|
| Поток обращений по типам | Соотношение инцидентов, консультаций, настроек и развития |
| Повторные инциденты | Проблемы, возвращающиеся после временного решения |
| Накопление запросов | Задачи, ждущие уточнения, оценки или согласования |
| Срок от согласования до приёмки | Скорость прохождения уже согласованных изменений |
| Полнота карточек | Каких данных не хватает для диагностики |
| Обращения по одному процессу | Участки, требующие настройки, инструкции или пересмотра правил |
Рост числа обращений может означать ошибку, но и активное развитие портала. Одна цифра причину не объяснит.
Как выбрать формат поддержки
- Разовые работы — для понятной изолированной задачи.
- Пакет часов — если обращения нерегулярны, но нужна общая очередь.
- Постоянное сопровождение — если портал регулярно меняется, есть интеграции и постоянный поток запросов.
Перед выбором форма стоит проверить: назначен ли владелец процессов, определён ли канал обращений, отделены ли инциденты от плановых изменений, понятен ли порядок работы с разработкой.
