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