В Казахстане Telegram насчитывает более 10 миллионов активных пользователей в месяц, а Kaspi.kz — около 13 миллионов: вместе эти две инфраструктуры покрывают практически всё взрослое население страны. При этом средний бизнес здесь продолжает мыслить категориями 2018 года: «нам нужно мобильное приложение». Тендеры на разработку iOS и Android-версий стартуют от 8–12 млн тенге, тянутся 6–9 месяцев, заканчиваются App Store и Google Play, а потом 80% установок не доживают до второй недели. И всё это для функциональности, которую Telegram-бот собирает за неделю.
Мы в West Star Ltd ведём интеграционные проекты на Python/Django и регулярно сталкиваемся с одним и тем же сценарием: клиент изначально приходит за приложением, а уезжает с ботом — и через три месяца понимает, что приложение ему вообще не нужно. Дело не в моде на ботов и не в дешевизне. Дело в том, что для большинства B2B-сценариев в Казахстане модель «канал в мессенджере + платежи через Kaspi» функционально превосходит мобильное приложение по всем измеримым параметрам, кроме одного. Об этом исключении — в конце.
Почему нативное приложение перестало быть очевидным выбором
Стандартная стоимость разработки коммерческого мобильного приложения в Алматы и Астане сегодня — 8–15 млн тенге за MVP с базовой функциональностью на двух платформах. Срок — от полугода до года, считая прохождение модерации в App Store. К этому добавляется ежегодная стоимость поддержки (15–25% от бюджета разработки), плата за аккаунт разработчика Apple ($99/год) и Google Play ($25 единоразово), и вечный геморрой с обновлениями SDK, новыми требованиями к приватности и совместимостью с новыми версиями iOS и Android.
Затем начинается худшая часть — установки. Чтобы клиент пользовался приложением, ему нужно: открыть магазин, найти его (или перейти по ссылке, которую вы где-то ему отправили), дождаться загрузки 80–150 МБ, выделить место в памяти, согласиться с разрешениями, зарегистрироваться, подтвердить email или номер. По индустриальной статистике, между «увидел рекламу» и «открыл приложение в первый раз» теряется 60–80% аудитории. В B2B-сегменте, где пул клиентов и так узкий, это катастрофа.
Telegram-бот в этой логике обходится по-другому. Клиент уже в Telegram. Регистрации нет, установки нет, разрешений нет. Один клик по ссылке — и он внутри. Ноль трения на входе. Идентификация при необходимости делается через request_contact — пользователь одним нажатием делится номером, и тот же самый номер привязан к Kaspi-аккаунту, к договору в 1С, к базе клиентов в CRM. Замкнутый круг идентификации, для которого в приложении пришлось бы городить SMS-верификацию с её стоимостью 15–25 тенге за сообщение.
Что Kaspi Pay изменил в этой математике
До 2024 года ключевым ограничением ботов был именно прием платежей. Можно было либо просить присылать чеки в чат и сверять вручную, либо встраивать сторонний эквайринг с комиссией 2,5–3,5% и его собственным онбордингом для клиента. Сейчас ситуация другая. У Kaspi есть прямое API для бизнеса (Kaspi Pay для предпринимателей), которое позволяет генерировать QR-коды и инвойсы с автоматическим webhook-уведомлением о факте оплаты. Параллельно сложилась экосистема посредников — AiPay, Pay.Aibot.kz и аналогичные, — которые упрощают подключение для тех, кто не хочет напрямую договариваться с банком.
Технологически это значит, что сценарий «клиент написал боту → бот выставил счёт через Kaspi → клиент оплатил в один клик в своём приложении Kaspi → бот получил webhook и перешёл к следующему шагу» работает за 4–8 секунд без участия оператора. Для ресторана это означает приём заказа без менеджера. Для оптовой компании — отгрузку по предоплате без бухгалтерского сопровождения каждой сделки. Для сервисного бизнеса — приём абонентской платы по подписке.
Раньше эта же связка требовала минимум двух человек на стороне продавца, отдельного приложения с интеграцией платёжной системы, сертификации и трёх-четырёхмесячного цикла внедрения. Сейчас — одного разработчика и недели работы.
Где бот работает лучше всего
Если убрать маркетинговую обёртку, типовые B2B-сценарии, где Telegram-бот обыгрывает приложение, делятся на четыре категории.
Заявки и тикеты. Клиент отправляет заявку, она маршрутизируется на менеджера, тот отвечает, клиент получает уведомление. Это весь функционал — и его одинаково обслуживают приложение и бот. Только бот пишется за 5–10 рабочих дней силами одного разработчика, а приложение требует трёхмесячного спринта.
Ввод и проверка данных по 1С. Менеджер на складе сканирует штрихкод через бот, бот запрашивает остатки через OData, возвращает количество и текущий резерв. Раньше под это писали мобильные приложения с подключением к терминальному серверу. Сегодня — одна функция в боте плюс OData-эндпоинт, и менеджер пользуется этим прямо в Telegram, который у него и так открыт.
Подписочные и абонентские модели. Доступ к платному контенту, расчёту KPI, отчётам, аналитике, экспертным консультациям. Бот выставляет ежемесячный счёт через Kaspi, при оплате открывает доступ, при просрочке — закрывает. Никакой App Store с его 30% комиссией. Никаких отдельных платёжных страниц на сайте.
Уведомления и операционка. Заказы, статусы, договоры на согласование, напоминания о платежах, отчёты по KPI. Здесь бот не просто конкурирует с приложением — он его съедает. Push-уведомления в приложениях имеют conversion 3–8% открытия; сообщение в Telegram — 60–80%, потому что мессенджер открывается каждые 15 минут, а приложение — раз в неделю.
Реальная экономика проекта
Возьмём конкретный сценарий: торговая компания, 200 постоянных клиентов B2B-сегмента, нужно автоматизировать приём заявок, выставление счетов через Kaspi и сверку оплат с 1С.
В формате нативного приложения: 10 млн тенге на разработку (iOS + Android), 6 месяцев до релиза, 2 млн тенге в год на поддержку. Через год после запуска приложение установлено у 40–60% клиентской базы, активно используют 25–35%. Возврат инвестиций — спорный.
В формате Telegram-бота: 600–900 тыс. тенге на разработку (Python + aiogram + интеграция с Kaspi API + OData-коннектор к 1С), 1,5–2 месяца до релиза, 150–250 тыс. тенге в год на поддержку. Через две недели после запуска бот доступен 100% клиентской базы (никаких установок). Активная использование — 70–85%, потому что Telegram у этих людей открыт всегда.
Соотношение бюджета — примерно 1:15 не в пользу приложения. Соотношение по охвату — 1:2 в пользу бота. Соотношение сроков — 1:4. Эта арифметика ломает практически все аргументы за приложение в типовом B2B-сценарии. И это не сравнение «дешёвое поделие против качественного продукта» — функциональность сопоставима. Разница в том, что бот использует чужую инфраструктуру (Telegram + Kaspi), а приложение требует строить свою.
Технический стек, который реально работает в Казахстане
Для производственного бота на казахстанском B2B-рынке стек устоялся. Базис — Python с библиотекой aiogram 3.x (асинхронная, поддерживает все актуальные возможности Bot API). База данных — PostgreSQL для транзакционных данных и Redis для кэша и rate-limiting. Деплой — Docker на VPS у локального провайдера или у Hetzner для географической близости (важно для скорости webhook'ов от Kaspi).
Для интеграций критически важны два слоя. OData-коннектор для 1С — это позволяет боту в реальном времени читать остатки, заказы, контрагентов и при необходимости создавать документы. Здесь экономия на масштабе огромная: 1С в Казахстане стоит у подавляющего большинства компаний, и слой между ним и Telegram-ботом окупается на первом же клиенте. Второй слой — Kaspi Pay API через webhook на собственный backend, потому что прямое подключение даёт гибкость, которой нет у посредников.
Для более сложных сценариев — Telegram Mini Apps. Это HTML/JS-приложения, которые открываются прямо внутри Telegram без выхода на App Store. Подходят для каталогов, корзин, личных кабинетов с табличным интерфейсом, которые сложно поместить в формат сообщений и кнопок. Сборка занимает в 1,5–2 раза дольше, чем чистый бот, но всё равно остаётся в разы дешевле нативного приложения.
Где этот подход реально не работает
Прежде чем продавать клиенту бот вместо приложения, важно честно обозначить границы.
Сценарии с интенсивной графикой и видео. Если ваш продукт — это, например, обучающая платформа с потоковым видео, библиотека дизайнерских ассетов или инструмент для редактирования изображений, Telegram-интерфейс будет тесным. Mini Apps это частично решает, но «тяжёлый» UX в окне мессенджера всё равно ощущается компромиссом.
Игры и продукты с выраженной геймификацией. Здесь приложение даёт настолько лучший UX, что разница перевешивает все экономические соображения. Bots могут работать как канал привлечения и удержания, но не как основной интерфейс.
Офлайн-первое использование. Курьерские приложения, складская логистика на территориях с плохим покрытием, полевые работы — нужно, чтобы интерфейс работал без сети и синхронизировался при появлении связи. Telegram требует подключения для каждой операции.
Привязка к специфическим функциям устройства. Считыватели NFC, специальные камерные режимы, биометрия для подписи документов через NCALayer-подобные сервисы. Часть этого решается через Mini Apps, но не всё.
Брендовое присутствие. Если для бизнеса критически важна полноценная иконка на главном экране клиента, отдельная экосистема, узнаваемость как «у вас есть наше приложение» — бот этого не даёт. Это эмоциональный фактор, но иногда он стоит денег.
Зависимость от платформы. Telegram блокировался в России и в нескольких других юрисдикциях. В Казахстане сейчас рисков такого рода нет, но архитектурно бизнес, построенный поверх стороннего мессенджера, всегда несёт риск, что владелец платформы изменит правила, тарифы API или политику. У собственного приложения этого риска нет.
Что делать
Для большинства казахстанских компаний из малого и среднего сегмента типичная задача — это автоматизировать ту часть взаимодействия с клиентом, которая сейчас идёт через WhatsApp, телефонные звонки и руками заполняемые накладные. В этом сценарии Telegram-бот с интеграцией Kaspi Pay и 1С через OData покрывает 80% потребности при бюджете в 10–15 раз меньшем, чем приложение, и сроке внедрения, измеряемом неделями, а не кварталами.
Подход, который работает: начать с бота на 2–3 ключевых сценария (приём заявок, выставление счетов, статусы заказов), запустить за 6 недель, протестировать на реальной клиентской базе, а через 3–4 месяца — на основе фактических данных об использовании — принимать решение, нужно ли вообще приложение. В нашей практике (AI-бухгалтер, OData Hub, складские интеграции) этот сценарий повторяется регулярно: до запуска бота клиент твёрдо хотел приложение, после трёх месяцев боевой эксплуатации — даже не возвращается к этой идее.
Мобильное приложение — это инструмент. Хороший, дорогой, мощный. Но как и любой инструмент, он подходит не для всех задач. В Казахстане 2026 года вопрос «нам нужно мобильное приложение?» лучше формулировать иначе: «есть ли в нашем сценарии ровно те функции, ради которых стоит платить в 15 раз больше и ждать в 4 раза дольше?». Если ответ честный — «нет», то бот не компромисс. Бот — правильный выбор.