Customer Support Ticket System on 1C-Bitrix: from Standard Module to Custom

Every online store eventually faces a flood of customer inquiries. The standard support module in 1C-Bitrix provides basic functionality: creating a ticket, changing status, and replying. But as the business grows, requirements emerge for SLA, order linking, and automatic routing. For example, on one project of an electronics online store, the number of inquiries grew to 500 per day. Operators were drowning in chaos—they had no idea which order was critical and which could wait. The standard module offered no tools for prioritization. After implementing a custom system with SLA, the first response time dropped from 4 hours to 15 minutes. Implementing such a system reduces support costs by 30–50% through automation. As integrators with 10 years of experience with Bitrix, we have frequently upgraded this module or replaced it with a custom system. According to the support module documentation, the standard solution does not include SLA, so serious projects require customization. This article explains how to set up a ticket system that really helps—not one that becomes a black hole.

Why the standard support module may not be enough

The support module solves basic tasks but has limitations:

• No SLA: response time is not controlled, no escalation.
• No order linking out of the box—the customer has to manually explain which order they’re referring to.
• No built-in statistics: resolution time, operator load, number of overdue tickets.
• Difficult to scale across multiple brands or support types.

Let’s compare the standard module with a custom solution:

A custom system handles 3–5 times more tickets with the same budget—proven on projects with thousands of inquiries per day. Operator time savings can reach 60%.

How to link a ticket to an order

Order linking is one of the most sought-after modifications. By default, the module does not know about the sale module. The solution is to add a user field UF_ORDER_ID to tickets. Here’s a step-by-step plan:

1. Add the user field via 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' => 'Заказ'], ]); ?> 

   After these steps, the operator sees the order contents, status, and delivery without manual searching.

   What’s included in the ticket system setup

   As part of the project, we:

   • Audit the current situation: inquiry flow, typical problems, SLA requirements.
   • Design: data schema, operator roles, SLA matrix.
   • Develop: either upgrade the standard module or build a custom system on its own table.
   • Integrate with orders (sale), users, and external services (e.g., ATOL for returns).
   • Configure auto-replies and message templates.
   • Build the operator interface: queue, filters, escalation, statistics.
   • Test and train: perform load testing, prepare operator instructions.
   • Provide warranty support: one month of free fixes after delivery.

   How we build a custom ticket system

   If requirements go beyond the standard module, we build a custom system. The scheme is proven on dozens of projects.

   Data schema:

   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=low, 2=normal, 3=high, 4=critical status VARCHAR(30) DEFAULT 'open', assigned_to INT, -- b_user.ID operator group_id INT, -- operator group 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, -- internal operator note created_at TIMESTAMP DEFAULT NOW() ); 

   We use a separate table (not standard infoblocks) for performance—this ensures speed even with millions of tickets. The ticket number is generated with a prefix and date, making it easy to search.

   How to set up SLA and escalation

   SLA is a service-level agreement that guarantees maximum response and resolution times. In our system, SLA is calculated based on category and priority. Step-by-step setup:

   1. Define ticket categories (e.g., “Return”, “Delivery”, “Technical problem”).
   2. Assign a priority to each category: critical, high, normal, low.
   3. Set the first response and resolution times for each priority.
   4. Configure an agent that checks for overdue tickets every 15 minutes and escalates.

   Example SLA calculator code:

   <?php class SlaCalculator { private array $slaMatrix = [ 'critical' => ['first_reply' => 60, 'resolution' => 240], // minutes '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"); } } ?> 

   The escalation agent raises the priority, changes the responsible operator, and sends a notification to the manager—no critical ticket goes unattended.

   Ticket creation form and operator interface

   In the customer’s personal account, they create a ticket with fields: category, subject, description. If they come from an order page, order_id is pre-filled. After submission, an email is sent with the ticket number and tracking link.

   For operators, we develop an administrative interface: a ticket queue with filters by status, category, assignee, and overdue SLA. Replies include message templates, status change buttons, and the ability to leave internal notes.

   Auto-replies and templates

   Message templates are stored in bl_support_templates. The operator selects a template from a dropdown—the message body is automatically filled with placeholders (customer name, order number, tracking link).

   When a ticket is created, an email is automatically sent via \Bitrix\Main\Mail\Event with type SUPPORT_TICKET_CREATED. When the operator replies, SUPPORT_TICKET_REPLY is sent. The customer is always kept informed of the status.

   Timeline and cost

   Stage	Duration
   DB schema + repositories	2 days
   Creation form + personal account	3 days
   Operator interface	4 days
   SLA + escalation + agent	2 days
   Email notifications + templates	1 day
   Testing	2 days
   Total	2 weeks

   Cost is calculated individually after analyzing requirements. Typically, a project falls within the range of 2 to 4 weeks. Get an estimate for your project—reach out to us, and we’ll prepare a detailed proposal with a work plan.

   We guarantee quality: all ticket systems undergo load testing, and documentation is provided to the client. Our experience includes over 50 successful Bitrix projects and certified specialists.

   Contact us to discuss your task. Order a consultation—we’ll assess your project for free.