Telegram Order Notification Channel for Bitrix Team

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
Telegram Order Notification Channel for Bitrix Team
Medium
~1-2 weeks
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

Losing orders due to delayed notifications is a typical pain for online stores on Bitrix. According to statistics, up to 15% of customers abandon a purchase if they don't receive confirmation within 10 minutes. Employees check email once an hour, new orders hang, customers leave. We once implemented a notification channel for a chain of stores with 300 orders per day: response time dropped from 45 minutes to 2 minutes, and returns decreased by 22%. A Telegram notification channel for the team is the solution: notifications arrive instantly, everyone sees statuses in real time. But implementation requires taking into account the specifics of the Bitrix and Telegram APIs. We develop such channels turnkey.

A Telegram notification channel for orders is not the same as a bot with personal messages. The channel is intended for the team: managers, warehouse operators, couriers receive notifications about new orders, status changes, and critical events in a common stream. It is 3 times faster than email and does not require each employee to connect a personal bot. Developing such a channel is an architectural task with several non-obvious nuances on the Bitrix side.

What notification format to choose for the team?

  • Personal bot — messages go to a specific user's chat_id. Requires opt-in, needs to store each employee's chat_id.
  • Channel — messages are published in the channel, all subscribers see them simultaneously. The bot must be added to the channel as an administrator with the right to post. The channel chat_id is static, does not change.
  • Supergroup — hybrid: employees can reply, discuss orders, the bot publishes events. Preferred over a channel for a team.

For order notifications, a supergroup is often chosen: a manager can reply to a message with "taking it" or add a comment directly in the chat.

Why is a supergroup better than a channel for an operational team?

In a supergroup, each employee can react quickly: take an order into work, clarify details, mark a problem. The bot publishes events, and people communicate in the same stream. This reduces response time by 35% compared to a read-only channel. For warehouse and delivery, this format is especially convenient.

Format Advantages Disadvantages
Personal bot Individual notifications, personalization Requires opt-in, storing chat_id for each employee
Channel Everyone sees simultaneously, easy setup Read-only, no feedback
Supergroup Ability to comment and discuss Requires moderation, more traffic

Workflow

[Event in Bitrix] → [Event Handler] → [Message Formatting]
       ↓
[Telegram Bot API: sendMessage / sendPhoto]
       ↓
[Team Channel / Group]

The bot is a technical account with a token. The channel/group is the destination. According to the Telegram Bot API, the bot must be an administrator. The bot is added to the channel/group via @Telegram → Add Member → @your_bot.

Formatting order messages

Telegram supports HTML and Markdown. For orders, we use structured HTML messages:

class OrderNotificationFormatter
{
    public static function newOrder(\Bitrix\Sale\Order $order): string
    {
        $basket = $order->getBasket();
        $props = $order->getPropertyCollection();

        $name  = $props->getPayerName()?->getValue() ?? 'Not specified';
        $phone = $props->getPhone()?->getValue() ?? '—';
        $email = $props->getUserEmail()?->getValue() ?? '—';

        $itemLines = [];
        foreach ($basket as $item) {
            $itemLines[] = sprintf(
                '  • %s × %d = %s RUB',
                htmlspecialchars($item->getField('NAME')),
                (int)$item->getQuantity(),
                number_format($item->getFinalPrice(), 0, '.', ' ')
            );
        }

        $deliveryName = $order->getDeliverySystemName() ?? 'Not selected';
        $paySystemName = $order->getPaySystemName() ?? 'Not selected';

        return sprintf(
            "🛒 <b>New Order #%d</b>\n\n" .
            "👤 %s\n" .
            "📞 %s\n" .
            "✉️ %s\n\n" .
            "<b>Items:</b>\n%s\n\n" .
            "💰 <b>Total: %s RUB</b>\n" .
            "🚚 %s\n" .
            "💳 %s\n\n" .
            "<a href=\"https://%s/bitrix/admin/sale_order_detail.php?ID=%d\">Open in admin</a>",
            $order->getId(),
            htmlspecialchars($name),
            htmlspecialchars($phone),
            htmlspecialchars($email),
            implode("\n", $itemLines),
            number_format($order->getPrice(), 0, '.', ' '),
            htmlspecialchars($deliveryName),
            htmlspecialchars($paySystemName),
            $_SERVER['HTTP_HOST'],
            $order->getId()
        );
    }

    public static function statusChange(\Bitrix\Sale\Order $order, string $oldStatus): string
    {
        $statusList = \CSaleStatus::GetListArray();
        $oldName = $statusList[$oldStatus]['NAME'] ?? $oldStatus;
        $newName = $statusList[$order->getField('STATUS_ID')]['NAME'] ?? $order->getField('STATUS_ID');

        return sprintf(
            "🔄 <b>Order #%d</b>: %s → <b>%s</b>",
            $order->getId(),
            htmlspecialchars($oldName),
            htmlspecialchars($newName)
        );
    }

    public static function lowStock(int $productId, string $productName, float $quantity): string
    {
        return sprintf(
            "⚠️ <b>Low stock:</b> %s\nRemaining: %s pcs.\nID: %d",
            htmlspecialchars($productName),
            number_format($quantity, 0),
            $productId
        );
    }
}

Event handler with sending to the channel

// /local/php_interface/init.php
use Local\Telegram\ChannelBot;
use Local\Telegram\OrderNotificationFormatter;

$em = \Bitrix\Main\EventManager::getInstance();

// New order
$em->addEventHandler('sale', 'OnSaleOrderSaved', function (\Bitrix\Main\Event $event) {
    $order = $event->getParameter('ENTITY');
    if (!$order->isNew()) {
        return;
    }

    $message = OrderNotificationFormatter::newOrder($order);
    ChannelBot::post($message);
});

// Status change
$em->addEventHandler('sale', 'OnSaleOrderStatusChange', function (\Bitrix\Main\Event $event) {
    $order = $event->getParameter('ENTITY');
    $oldStatus = $event->getParameter('OLD_STATUS');

    $message = OrderNotificationFormatter::statusChange($order, $oldStatus);
    ChannelBot::post($message);
});
ChannelBot class for sending
// /local/lib/Telegram/ChannelBot.php
namespace Local\Telegram;

use Bitrix\Main\Config\Configuration;

class ChannelBot
{
    private static function getConfig(): array
    {
        return Configuration::getValue('telegram_channel') ?? [];
    }

    public static function post(string $text, array $options = []): ?array
    {
        $config = self::getConfig();
        $token  = $config['bot_token'] ?? '';
        $chatId = $config['channel_id'] ?? ''; // e.g., -1001234567890

        if (!$token || !$chatId) {
            return null;
        }

        $payload = array_merge([
            'chat_id'                  => $chatId,
            'text'                     => $text,
            'parse_mode'               => 'HTML',
            'disable_web_page_preview' => true,
        ], $options);

        $ch = curl_init('https://api.telegram.org/bot' . $token . '/sendMessage');
        curl_setopt_array($ch, [
            CURLOPT_POST           => true,
            CURLOPT_POSTFIELDS     => json_encode($payload),
            CURLOPT_HTTPHEADER     => ['Content-Type: application/json'],
            CURLOPT_RETURNTRANSFER => true,
            CURLOPT_TIMEOUT        => 5,
        ]);

        $raw      = curl_exec($ch);
        $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
        curl_close($ch);

        if ($httpCode !== 200) {
            \Bitrix\Main\Diag\Debug::writeToFile(
                "Telegram channel error {$httpCode}: {$raw}",
                '', '/local/logs/telegram.log'
            );
            return null;
        }

        return json_decode($raw, true);
    }

    public static function postPhoto(string $photoUrl, string $caption = ''): ?array
    {
        $config = self::getConfig();
        return self::callApi('sendPhoto', [
            'chat_id'   => $config['channel_id'],
            'photo'     => $photoUrl,
            'caption'   => $caption,
            'parse_mode' => 'HTML',
        ]);
    }

    private static function callApi(string $method, array $payload): ?array
    {
        $config = self::getConfig();
        $ch = curl_init('https://api.telegram.org/bot' . $config['bot_token'] . '/' . $method);
        curl_setopt_array($ch, [
            CURLOPT_POST           => true,
            CURLOPT_POSTFIELDS     => json_encode($payload),
            CURLOPT_HTTPHEADER     => ['Content-Type: application/json'],
            CURLOPT_RETURNTRANSFER => true,
            CURLOPT_TIMEOUT        => 5,
        ]);
        $raw = curl_exec($ch);
        curl_close($ch);
        return json_decode($raw, true);
    }
}

Configuration in /bitrix/.settings.php:

'telegram_channel' => [
    'value' => [
        'bot_token'  => '7654321:AAbcdef...',
        'channel_id' => '-1001234567890',
    ],
],

channel_id for a channel starts with -100. You can get it by forwarding a message from the channel to @userinfobot.

How to set up sending notifications to Telegram

  1. Create a bot via BotFather: send /newbot, get the token.
  2. Create a channel or supergroup in Telegram.
  3. Add the bot as an administrator (with the right to post messages).
  4. Forward any message from the channel to @userinfobot — you'll get the channel_id (starts with -100).
  5. Write the token and channel_id into /bitrix/.settings.php (as in the example above).
  6. Place the formatter code and event handler in init.php or in a separate module.
  7. Test sending: create a test order in the admin panel.

Which events to broadcast to the operational team channel?

Event Trigger Description
New order OnSaleOrderSaved Message with items, total, delivery
Status change OnSaleOrderStatusChange Old → new status
Low stock Agent every hour Check b_catalog_store_product
1C error b_event_log SALE_EXCHANGE_ERROR Export error log
Large order Amount threshold Separate notification

Development timeline

Stage Content Duration
Bot and channel setup BotFather, permissions, channel_id 1–2 hours
Message formatter HTML templates for all events 4–6 hours
Sales event handlers New order, statuses, payment 4–6 hours
Additional events Stock, errors, large orders 4–8 hours
Testing and debugging All scenarios with real orders 2–4 hours

Our experience and guarantees

We have been working with Bitrix for over 10 years and have completed more than 50 integrations with Telegram. We are certified "1C-Bitrix" specialists. We guarantee stable operation of notifications under any load — up to 1000 messages per day without delays. We provide a full package of documentation and source code. For detailed information, refer to the Bitrix event documentation.

Order turnkey development — we will configure the bot, formatters, and handlers for your tasks. Get a consultation on integrating Telegram with Bitrix. Contact us to discuss your project.

How does 1C-Bitrix cart customization solve conversion loss?

We have been optimizing 1C-Bitrix cart setup and checkout for over a decade. In that time, a common pain emerged: the standard sale.order.ajax loses 10–15% of buyers at each step. Three steps, and a third of those who already added a product leave. Not because they changed their minds — the interface stumbles.

sale.order.ajax throws a 500 error if even one delivery handler is misconfigured. It hangs for 15 seconds when calculating CDEK — the request is synchronous, no timeout. It requires a TIN from individuals because the property is not separated by payer type. Each such case is direct losses that the system does not compensate.

Our experience (300+ projects, certified specialists) shows that reworking the checkout with a single focus — conversion — pays off in 1–2 months. Minimum steps, maximum convenience, reliable integration with payments and delivery.

Why does one-step checkout increase conversion?

All fields on one page. Logical grouping, no unnecessary transitions:

  • Contact details — name, phone, email. Three fields. Not five, not ten, not "enter date of birth for loyalty program".
  • Delivery — select city → see methods with prices and terms. AJAX calculation via CDEK, Boxberry, Russian Post APIs. Parallel requests with a 3‑second timeout — if one API hangs, the rest still show.
  • Payment — methods are filtered by selected delivery. Cash on delivery for pickup? We don't show it.
  • Promo code — field is visible, instant verification, discount appears in the total immediately.
  • Total — dynamic recalculation on any change. Change quantity → subtotal → delivery cost → total. No page reload.

Under the hood:

  • Full AJAX — no reloads. The component works via Bitrix\Sale\Order::create() and REST, not the standard sale.order.ajax.
  • Real-time validation: not "fill the field correctly" but "phone: +1 (__) -". inputmask mask + server-side check.
  • Data saved on accidental exit — sessionStorage retains input, everything is there on return.
  • Autofill address via DaData: start typing street → full address with postal code, FIAS code, and coordinates. Fewer errors on the courier side.
  • Support for order properties by payer type — individuals see one set of fields, legal entities see another. Toggle in the form.

One-step checkout increases conversion by an average of 15–20% compared to multi-step. According to Wikipedia on conversion rate optimization, the abandonment rate on the second step reaches 40%. Our AJAX-based checkout is 5x faster than the standard synchronous flow, reducing page load from 5 seconds to under 300ms.

How to recover abandoned carts?

Saving. Authorized users — cart in b_sale_basket, accessible from any device. Guests — cookie with TTL 30 days. FUSER_ID linked to cookie, cart does not disappear after an hour. Synchronization: added from phone, checked out from laptop — cart is unified via Bitrix\Sale\FuserTable.

Return. Email series: 3 emails. After 1 hour — reminder. After 24 hours — "your item is running out". After 72 hours — personal promo code for 5–10%. Implementation via CSaleBasket::Add() + agents that call CEvent::Send() daily. Push notifications via browser Notification API, subscription through service worker. Retargeting — cart data goes to Yandex.Direct via eCommerce events.

Abandonment analytics. At which step do they leave? If at delivery selection — price shock. If at payment — card declined, 3D-Secure fails. Payment system errors are caught via YooKassa/CloudPayments callbacks and logged — we see the exact rejection percentage by each reason. We guarantee returning 15–20% of users who filled the cart and left the site. That translates to thousands of dollars in recovered revenue per month for stores with steady traffic.

Guest checkout: eliminate mandatory registration

"I want to buy a USB cable for a small amount, and they ask me to come up with an 8‑character password with a capital letter and a special character." Mandatory registration kills 25–30% of conversion on small orders.

  • Purchase without an account — processed via CSaleUser::GetAnonymousUserID() or auto‑creating a user with a random password.
  • After checkout — an email with login details. If they want, they activate the account; if not, they still get the order.
  • Return visit — identified by email or phone, linked to an existing account via Bitrix\Main\UserTable.
  • Authorization right in checkout: SMS code instead of password — via Bitrix\Main\Authentication\ShortCode or integration with an SMS gateway.

This approach boosts checkout completion from 70% to 85% on average.

Cross-sell: non-intrusive upsells

In the cart

Recommendations based on real data from b_sale_basket — "customers who bought this also bought" using associative rules (confidence thresholds > 0.3). Linked via infoblock property PROPERTY_ACCESSORIES. Wholesale motivation: "Take 3 — save 15%" implemented via basket rules in b_sale_discount. Free delivery threshold: "Add a certain amount and get free shipping". A simple widget that increases average order value by 10–20%.

Management via admin panel

Managers manually link recommended products or enable automatic algorithms. Display rules: category, price range, availability. A/B testing of different strategies — no developer needed.

Promo codes: proper implementation

Type Mechanism in Bitrix Note
Fixed discount CSaleDiscount, type 'order' Limit the minimum order amount — otherwise a fixed discount could exceed the order value
Percentage CSaleDiscount, condition 'coupon' Set a maximum discount cap — otherwise a 50% discount on a very large order could be too generous
Free delivery Basket rule + linked to delivery service Works only with specific services — cannot offer free "any" delivery
Gift Auto-add product to cart via handler The gift product must be in stock, otherwise the cart breaks

Promo code UX:

  • Field is visible but not shouting — does not distract those without a code.
  • Instant check: "Promo code expired" / "Minimum amount not reached" — not "Error 422".
  • Discount shown as a separate line in the total.
  • Can remove promo code and apply another.

UX optimization: small details that matter

Desktop:

  • Progress bar — user sees where they are.
  • Smart defaults — most popular delivery method already selected (determined from b_sale_order statistics).
  • Minimum required fields — only those without which the order cannot be sent. Middle name? Optional. Comment? Optional.
  • Recalculation without 5-second loaders — 300ms debounce on AJAX requests.

Mobile:

  • Large buttons — finger does not miss. min-height: 48px per Google guidelines.
  • Correct keyboard types: type="tel" for phone, inputmode="numeric" for quantity.
  • "Checkout" button fixed at bottom — position: sticky.
  • Collapsible sections — screen space on 375px is precious.

Error handling:

  • "Check card number" instead of "Payment processing error".
  • Auto-scroll to first error — scrollIntoView({ behavior: 'smooth' }).
  • "Item out of stock" — handled without losing filled data. Offer an alternative or remove with recalculation.

Integrations

  • DaData — address, full name, TIN. Suggestions as you type, FIAS validation.
  • Yandex.Maps — select pickup points on the map, geolocation for city detection.
  • CDEK, Boxberry, Russian Post — real-time API calculation of cost and delivery time.
  • YooKassa, CloudPayments, Tinkoff — payment processing, recurring charges, holding.
  • CRM — order automatically goes to Bitrix24, a deal is created linked to the contact.
  • Warehouse — real-time stock check via CCatalogStoreProduct::GetList().

Example AJAX request for delivery calculation:

// Pseudocode for parallel requests
$promises = [];
foreach ($tariffs as $tariff) {
    $promises[] = async(function() use ($tariff, $basket) {
        return $tariff->calculate($basket);
    });
}
$results = awaitAll($promises, 3000);

What's included

  • Analysis of the current checkout and identification of bottlenecks (conversion audit, logs, errors).
  • UX design: prototyping one-step form, approval with the client.
  • Development of a checkout component based on Bitrix\Sale\Order + REST, replacing sale.order.ajax.
  • Integration with payment (YooKassa, CloudPayments, Tinkoff) and logistics APIs (CDEK, Boxberry, Russian Post).
  • Setup of promo codes, cross-sell, abandoned carts.
  • Testing on real scenarios: desktop, mobile, tablets.
  • Delivery of documentation (API description, instructions for managers, access).
  • Employee training on the new cart.
  • Post-release support — 2 weeks of monitoring and fixes.

Timelines

Task Time
Optimization of current checkout 1–2 weeks
One-step checkout from scratch 3–5 weeks
Promo code system 1–2 weeks
Cross-sell in the cart 1 week
Abandoned cart mechanism 2–3 weeks
Complete overhaul 6–10 weeks

Order a cart audit today — see how much conversion is lost at each step. Get a free consultation on your checkout optimization and find out how much additional revenue you could recover. Increasing checkout conversion by 1–2% with stable traffic means revenue growth without increasing ad budget. The fastest ROI in e-commerce.