Настройка тикет-системы поддержки покупателей 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 успешных проектов на Битрикс, сертифицированные специалисты.

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