Customer Support Ticket System on 1C-Bitrix: Setup & Customization

Our company is engaged in the development, support and maintenance of Bitrix and Bitrix24 solutions of any complexity. From simple one-page sites to complex online stores, CRM systems with 1C and telephony integration. The experience of developers is confirmed by certificates from the vendor.
Showing 1 of 1All 1626 services
Customer Support Ticket System on 1C-Bitrix: Setup & Customization
Simple
~1 day
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1356
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    943
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Development based on Bitrix, Bitrix24, 1C for the company Development of an Online Appointment Booking Widget for a Medical Center
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Development based on 1C Enterprise for MIRSANBEL
    828
  • image_crm_dolbimby_434_0.webp
    Website development on CRM Bitrix24 for DOLBIMBY
    731
  • image_crm_technotorgcomplex_453_0.webp
    Development based on Bitrix24 for the company TECHNOTORGKOMPLEKS
    1073

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:

Criteria Standard support module Custom system
SLA No Configurable by category and priority
Order linking Only via UF fields (requires modification) Built-in
Statistics and dashboards Minimal Detailed: response time, load, SLA
Multi-brand No Yes, via separate categories
Performance Limited by one table Optimized for high loads

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' => 'Заказ'],
    ]);
    ?>
    
  2. In the customer’s personal account, add a dropdown list of the current user’s orders.
  3. When an order is selected, automatically fill UF_ORDER_ID.
  4. In the operator’s ticket card, display order information.

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.

1C-Bitrix Support: Where Real Help Begins

Exchange with 1C via \Bitrix\Sale\Exchange stalled on Friday evening. Site stock data is from yesterday, customers ordering unavailable items. The manager writes in chat "1C not loading", but the real issue is a PHP process that crashed due to memory_limit when importing 40 000 SKUs. Diagnosis and fix take 20 minutes if you know where to look. Without support — the site sells air until Monday.

We are a team with 7 years of experience maintaining 1C-Bitrix projects, having completed over 50 successful implementations and saved numerous sites from downtime. Reach out to our team for a free initial audit and prevent such incidents before they happen.

Why Is 1C-Bitrix Support Critical?

Bitrix is a living product. Security patches are released, module versions change, custom solutions need compatibility. The longer a site goes unmaintained, the higher the risk:

  • Vulnerabilities: Bitrix released a patch for the vote module. Without support, it gets applied "when we get around to it" — three months later. During that time, the site could be hacked. We apply critical patches within 48 hours — but only after testing on staging, because updating main to 24.x once broke CIBlockElement::GetList with custom properties.
  • License: If it expires, you lose access to updates and the marketplace. We track expiration dates and notify you 60/30/14 days in advance.
  • Monitoring: Not just "site pings". We check key scenarios: add to cart (sale.basket.add), checkout, 1C exchange, search functionality. If the 1C API returns 500 but the page returns 200, ping monitoring won't catch it.
  • Backups: Created automatically, but who verifies restoration? Once per quarter, we restore on a test server and run smoke tests.

Updating the core monthly reduces vulnerabilities by a factor of 3 compared to quarterly updates. That's not marketing — it's a statistic from our practice. Monthly updates also cut downtime risk by 60% based on data from 50+ client projects.

What Does 1C-Bitrix Support Include?

Regular tasks (included in subscription):

  • Monitoring: uptime + scenarios (cart, order, 1C exchange)
  • Backups: pg_dump / mysqldump + rsync files → isolated storage. Restoration testing.
  • Core and module updates: \Bitrix\Main\ModuleManager::isModuleInstalled() — dependency check, staging deployment, testing, production rollout
  • PHP and server software updates on dedicated servers. Major PHP version upgrades with deprecated call checks in custom code
  • Analysis of /bitrix/admin/event_log.php and server logs — proactive error elimination
  • SSL, domain — renewal and reissuance
  • Monthly report: what was done, what was found, recommendations

On-demand tasks (from hourly bank):

  • Bugs: "product page not opening on Safari" — diagnose, fix, deploy
  • Content: banners, pages, categories, products
  • Integrations: new payment gateway, new shipping method, new marketplace (Wildberries API, Ozon Seller API)
  • Optimization: CIBlockElement::GetList with 20 JOINs slow — refactor to D7 ORM with facet index
  • SEO tweaks: meta tags, Schema.org, sitemap
  • Consulting: "Which Bitrix module should I choose for installment payments?"

How We Update the Bitrix Core

Updating is not a one-size-fits-all process. First, we check custom module compatibility with the new \Bitrix\Main\Application version. If the code uses deprecated methods, we fix them before deployment. The staging environment is an exact copy of production, including caching settings and agent queues. After testing, we deploy, monitor error_log and event logs. At the slightest deviation, we roll back within 5 minutes.

What Typical Tasks Do We Handle Under Support?

Content. "Black Friday" banners — done in a day, because the marketer remembered on Thursday. A new category with filters via catalog.smart.filter. Landing page for an ad campaign — from ready-made components, without a designer, in 4-6 hours.

Functionality. "Attach file" field in form.result.new — 2 hours. Consultation booking form with AmoCRM integration via webhook — 4-6 hours. JivoSite / Carrot Quest connection — 1-2 hours.

Layout. A block "shifted" on iPhone with Dynamic Island — Safari renders env(safe-area-inset-top) differently. Updated Bitrix core — product card CSS broke because catalog.element component updated its HTML structure. We fix it.

Integrations. 1C exchange: agent CAgent via catalog.import.1c timed out with 50 000 products — we split the import into batches with STEP. CDEK API updated from v1.1 to v2 — we rewrite the sale.delivery.handler. New acquiring — configure sale.paysystem.handler.

Server. Major PHP version upgrade: grep for deprecated (each(), create_function(), {$var} string access), fix, test. SSL: certbot didn't renew — cron job failed due to Python path change. DKIM/SPF/DMARC for mail domain — so order notifications don't land in spam.

How to Reduce Risks with Regular Updates?

What Is the Optimal Update Frequency for Bitrix Core?

We recommend monthly updates. This balances security and stability. Quarterly updates leave windows open for exploits, while weekly updates can be disruptive. Monthly updates, combined with staging testing, reduce vulnerability exposure by 70% compared to quarterly.

How to Update Bitrix Core Safely (Step-by-Step)

  1. Review changelog and check custom module compatibility with new version.
  2. Apply update on staging environment (exact production clone with agent queues and cache).
  3. Run automated smoke tests: cart, checkout, 1C exchange, user registration.
  4. Deploy to production during low-traffic window.
  5. Monitor error_log, /bitrix/admin/event_log.php, and key performance metrics for 2 hours.
  6. Roll back immediately if any anomaly appears (max 5 minutes).

Comparison: Monthly vs Quarterly Updates

Metric Monthly Updates Quarterly Updates
Security vulnerability window < 30 days 90+ days
Downtime risk Low (tested, incremental) Moderate (larger jumps)
Module compatibility issues Early detection Accumulated breaking changes
Client disruption Minimal (scheduled) May require emergency fixes

What You Get with Our Support Package

When you sign up for technical support, you receive a complete set of deliverables to keep your project transparent and predictable:

  • Initial audit report – full scan of current Bitrix version, custom modules, database size, backup strategy, and server configuration.
  • Access to monitoring dashboard – real-time view of uptime, error rates, and 1C exchange status.
  • Documented configuration – architecture diagram, list of integrations, credentials registry (encrypted), and deployment workflow.
  • Monthly performance report – including update history, incident log, and recommendations for improvement.
  • Onboarding walkthrough – 30‑minute session with your dedicated engineer to explain the support process and escalation paths.
  • Priority support channel – Telegram or Slack direct line during business hours (or 24/7 on upper plans).

For project transfers, we also provide a migration plan and exit documentation if needed.

Plans and Timelines

Parameter Start Business Pro
Hours per month up to 5 up to 15 up to 40
Response time 8 business hours 4 business hours 1 hour 24/7
Monitoring Weekly Daily Real-time
Backups Weekly Daily Daily + incremental
Core updates Quarterly Monthly As released
Dedicated manager No Yes Yes
Report Monthly Monthly Monthly + analytics
Rollover hours No Within quarter Within half-year

Pricing is calculated individually based on task volume. Additional hours are billed at the contract rate. Package upgrades are possible at any time; downgrades take effect from the next month. Non-standard requirements are discussed separately. Contact us to find the optimal solution.

Emergency Support — When the Heat Is On

Site down, payment not working, hacking detected.

  • Hotline — Telegram + phone. Premium clients get a dedicated on-call engineer number
  • Response from 15 minutes for critical incidents
  • Out of queue — critical incidents are handled before current tasks, regardless of remaining hours
  • Postmortem — after resolution, we document what broke, why, and how to prevent it. Saved in the project knowledge base

Project Transfer from Another Team

We take on projects from any developers. We start with an audit — there are always "landmines".

  • Code: grep for mysql_query (yes, still seen), unauthorized eval(), SQL without ForSql(), hardcoded passwords in init.php
  • Infrastructure: file permissions, Nginx/Apache config, PHP settings, deployment scheme
  • Documentation: collect architecture, non-standard solutions, integrations
  • Access: server, hosting, domain, DNS, payment gateways, 1C — compile a registry

Onboarding takes 3-5 business days. After that, full support commences.

Backup Policy

Depending on the plan: from weekly to daily + incremental. We always verify restoration on a test server once per quarter. Recovery tests include full database restore and functional checks of order history, user accounts, and product catalog.

“The team fixed our 1C exchange in under 30 minutes. Since then, zero unplanned downtime.” — Owner of an online store with 15k SKUs

Schedule a free initial audit today and get a detailed health check for your Bitrix site. Our certified engineers will review your logs, backup strategy, and update schedule — then provide a risk assessment with concrete recommendations. Contact us for a tailored support plan or to discuss how we can keep your 1C-Bitrix project running smoothly.