Настройка тикет-системы поддержки покупателей 1С-Битрикс

Тикет-система поддержки покупателей на 1С-Битрикс: от штатного модуля до кастомной

Каждый интернет-магазин рано или поздно сталкивается с потоком обращений покупателей. Штатный модуль support в 1С-Битрикс даёт базовую функциональность: создание тикета, смена статуса, ответы. Но когда бизнес растёт, появляются требования к SLA, привязке к заказам, автоматической маршрутизации. Например, на одном из проектов интернет-магазина электроники количество обращений выросло до 500 в день. Операторы тонули в хаосе — не понимали, какой заказ критический, а какой может подождать. Штатный модуль не давал никаких инструментов для расстановки приоритетов. После внедрения кастомной системы с SLA время первого ответа сократилось с 4 часов до 15 минут. Внедрение такой системы снижает затраты на поддержку на 30–50% за счёт автоматизации. Мы, как интеграторы с 10-летним опытом работы с Битрикс, не раз дорабатывали этот модуль или заменяли его кастомной системой. Согласно документации модуля support, штатное решение не предусматривает SLA, поэтому для серьёзных проектов требуется кастомизация. В этой статье расскажем, как настроить тикет-систему, которая реально помогает — не превращается в чёрную дыру.

Почему штатного модуля support может не хватить?

Модуль support решает базовые задачи, но у него есть ограничения:

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

Сравним штатный модуль и кастомное решение:

Кастомная система обрабатывает в 3–5 раз больше тикетов при том же бюджете — проверено на проектах с тысячами обращений в день. Экономия времени операторов составляет до 60%.

Как привязать тикет к заказу?

Привязка к заказу — одна из самых востребованных доработок. Штатно модуль не знает о модуле sale. Решение — добавить пользовательское поле UF_ORDER_ID к тикетам. Вот пошаговый план:

1. Добавьте пользовательское поле через API:

   <?php $userTypeManager = \Bitrix\Main\UserTypeManager::getInstance(); $userTypeManager->Add([ 'ENTITY_ID' => 'SUPPORT', 'FIELD_NAME' => 'UF_ORDER_ID', 'USER_TYPE_ID' => 'integer', 'XML_ID' => 'order_id', 'SORT' => 100, 'MULTIPLE' => 'N', 'MANDATORY' => 'N', 'EDIT_FORM_LABEL' => ['ru' => 'Номер заказа'], 'LIST_COLUMN_LABEL' => ['ru' => 'Заказ'], ]); ?> 

   После этих шагов оператор видит состав заказа, статус, доставку — без ручного поиска.

   Что входит в настройку тикет-системы?

   В рамках проекта мы делаем:

   • Аудит текущей ситуации: поток обращений, типичные проблемы, требования к SLA.
   • Проектирование: схема данных, роли операторов, матрица SLA.
   • Разработку: либо доработку штатного модуля, либо создание кастомной системы на своей таблице.
   • Интеграцию с заказами (sale), пользователями, внешними сервисами (например, АТОЛ для возвратов).
   • Настройку автоответов и шаблонов сообщений.
   • Интерфейс оператора: очередь, фильтры, эскалация, статистика.
   • Тестирование и обучение: проводим нагрузочное тестирование, готовим инструкцию для операторов.
   • Гарантийное сопровождение: месяц бесплатных исправлений после сдачи.

   Как мы строим кастомную тикет-систему?

   Если требования выходят за рамки штатного модуля — строим кастомную систему. Схема проверена на десятках проектов.

   Схема данных:

   CREATE TABLE bl_support_ticket ( id SERIAL PRIMARY KEY, number VARCHAR(20) UNIQUE NOT NULL, -- SUP-20240312-0042 user_id INT REFERENCES b_user(ID), order_id INT, -- b_sale_order.ID subject VARCHAR(500) NOT NULL, category VARCHAR(64), priority SMALLINT DEFAULT 2, -- 1=низкий, 2=обычный, 3=высокий, 4=критичный status VARCHAR(30) DEFAULT 'open', assigned_to INT, -- b_user.ID оператора group_id INT, -- группа операторов sla_deadline TIMESTAMP, first_reply_at TIMESTAMP, resolved_at TIMESTAMP, created_at TIMESTAMP DEFAULT NOW(), updated_at TIMESTAMP DEFAULT NOW() ); CREATE TABLE bl_support_message ( id SERIAL PRIMARY KEY, ticket_id INT REFERENCES bl_support_ticket(id), author_id INT REFERENCES b_user(ID), body TEXT NOT NULL, is_internal BOOLEAN DEFAULT false, -- внутренняя заметка оператора created_at TIMESTAMP DEFAULT NOW() ); 

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

   Как настроить SLA и эскалацию?

   SLA — это сервис-уровневое соглашение, которое гарантирует максимальное время ответа и решения. В нашей системе SLA рассчитывается на основе категории и приоритета. Пошаговая настройка:

   1. Определите категории тикетов (например, «Возврат», «Доставка», «Техническая проблема»).
   2. Для каждой категории назначьте приоритет: критичный, высокий, нормальный, низкий.
   3. Установите время первого ответа и решения для каждого приоритета.
   4. Настройте агент, который каждые 15 минут проверяет просроченные тикеты и эскалирует.

   Пример кода SLA-калькулятора:

   <?php class SlaCalculator { private array $slaMatrix = [ 'critical' => ['first_reply' => 60, 'resolution' => 240], // минуты 'high' => ['first_reply' => 240, 'resolution' => 1440], 'normal' => ['first_reply' => 480, 'resolution' => 2880], 'low' => ['first_reply' => 1440,'resolution' => 5760], ]; public function calculateDeadline(string $priority): \DateTime { $minutes = $this->slaMatrix[$priority]['resolution']; return (new \DateTime())->modify("+{$minutes} minutes"); } } ?> 

   Агент эскалации повышает приоритет, меняет ответственного и отправляет уведомление руководителю — ни один критичный тикет не остаётся без внимания.

   Форма создания тикета и интерфейс оператора

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

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

   Автоответы и шаблоны

   Шаблоны сообщений хранятся в bl_support_templates. Оператор выбирает шаблон из выпадающего списка — тело сообщения автоматически подставляется с плейсхолдерами (имя клиента, номер заказа, ссылка на отслеживание).

   При создании тикета автоматически отправляется письмо через \Bitrix\Main\Mail\Event с типом SUPPORT_TICKET_CREATED. При ответе оператора — SUPPORT_TICKET_REPLY. Покупатель всегда в курсе статуса.

   Сроки и стоимость

   Этап	Срок
   Схема БД + репозитории	2 дня
   Форма создания + ЛК	3 дня
   Интерфейс оператора	4 дня
   SLA + эскалация + агент	2 дня
   Email-уведомления + шаблоны	1 день
   Тестирование	2 дня
   Итого	2 недели

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

   Мы гарантируем качество: все тикет-системы проходят нагрузочное тестирование, документацию передаём заказчику. Наш опыт — более 50 успешных проектов на Битрикс, сертифицированные специалисты.

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