Как автоматизировать продажи в Телеграм? Кейс: +40% заказов
Кратко: если клиенты уже покупают через Telegram, автоматизация внутри Telegram Web App и бота убирает ручной расчёт цены, проверку оплат и часть логистики — без переучивания аудитории. В этом кейсе такой подход за 6 недель разработки дал +40% заказов, ноль ошибок в расчётах и снял потолок роста без найма второго менеджера.
Менеджер ошибался с курсом юаня примерно раз в неделю. Не потому что плохой специалист — просто когда за день прилетает 60 сообщений «хочу вот эти кроссы, сколько стоит?», рано или поздно считаешь неправильно. Через два месяца после запуска автоматизации число заказов выросло на 40%, а ошибок в расчётах стало ровно ноль.
Это была точка входа в проект, который мы разрабатывали для реселлера брендовой одежды и обуви с Poizon (он же Dewu) — крупнейшего китайского маркетплейса кроссовок с моделью аутентикации, где каждая пара проходит проверку подлинности перед отправкой.
Какой бизнес-затык на самом деле мешал расти, а не просто раздражал команду?
60 входящих сообщений в день — и один менеджер, который вручную открывает таблицу курсов, считает рублёвую цену, скидывает реквизиты, ждёт скриншот перевода, записывает заказ. При десяти заказах в день эта схема работала. При шестидесяти — превращалась в то, что клиент сам назвал «производственным адом».
Первый разговор с ним занял около двух часов. Не потому что задача была непонятной, а потому что у клиента не было чёткого ответа на простой вопрос: что болит сильнее всего?
Ошибки в расчётах? Да, клиенты замечали и начинали спорить. Время менеджера? Тоже да — человек тонул. Но корневая проблема оказалась не в рутине как таковой. Клиент хотел расти. Принимать больше заказов. А текущий процесс физически не позволял этого без найма ещё одного человека. Ручная воронка стала не просто раздражителем — она стала потолком выручки.
На практике мы видели такое десятки раз: владелец бизнеса приходит с жалобой на ошибки, а реальная проблема — невозможность масштабироваться. Ошибка с курсом юаня раз в неделю — симптом. Пропускная способность одного менеджера — диагноз. Иначе никак.
Почему для такого кейса выбрали Telegram Web App, а не сайт или отдельное приложение?
100% заказов этот бизнес принимал через Telegram ещё до нашего появления. Клиент писал в чат, менеджер отвечал в чат. Вся база покупателей жила там.
Мы рассматривали три варианта: отдельный сайт, мобильное приложение и Telegram Web App. Сайт означал бы лишний шаг — клиенту нужно перейти по ссылке, дождаться загрузки страницы, разобраться с незнакомым интерфейсом. Приложение в App Store — ещё хуже: установка, регистрация, уведомления, которые никто не разрешает. Переучивание аудитории под новый канал могло стоить до половины базы.
Telegram Web App — мини-приложение, которое открывается прямо внутри чата. Каталог с фотографиями, размерная сетка, кнопка «Купить» — всё в привычном интерфейсе. Клиент не уходит из Telegram. Не устанавливает ничего нового. Не вводит логин и пароль.
Выбор канала здесь диктовался не модой на ботов и не удобством разработки. Это была экономика: сохранить существующую базу и убрать трение на пути к покупке. Для бизнеса, где средний чек зависит от импульса («хочу эти кроссы»), каждый лишний клик — потерянный заказ.
Как была устроена ручная воронка до автоматизации и где в ней терялись деньги?
Пиковая нагрузка — около 60 запросов в день, и каждый проходил через одну и ту же цепочку из шести ручных шагов. Прошлой осенью, когда мы впервые увидели эту схему в действии, поначалу даже не верилось, что она вообще как-то работает.
Вот как это выглядело: клиент пишет в Telegram → менеджер уточняет размер и цвет → открывает таблицу с курсами CNY/RUB → считает итоговую сумму в рублях → отправляет реквизиты → ждёт, пока клиент пришлёт подтверждение перевода → идёт проверять вручную → записывает заказ. Шесть точек, в каждой из которых можно ошибиться, задержаться или потерять клиента.
Потери шли по трём направлениям одновременно. Первое — ошибки: одна неправильная конвертация в неделю означала либо недополученную маржу, либо конфликт с покупателем. Второе — время: менеджер буквально сидел и ждал скриншот чека, вместо того чтобы обрабатывать следующий запрос. Третье — пропускная способность: при 60 сообщениях в день человек физически не мог ответить всем быстро, и часть потенциальных покупателей просто уходила.
Заказы записывались вручную после оплаты. Никакой автоматической истории, никакой аналитики по каналам привлечения. Бизнес летел вслепую.
Как автоматизация убрала ошибки в цене и высвободила время менеджера?
После запуска ошибок в расчёте стоимости стало ноль — не «почти ноль», а именно ноль. Механика простая: каталог подтягивается из базы с артикулами Poizon, цена автоматически конвертируется по текущему курсу CNY/RUB, курс обновляется каждый день. Менеджер в этой цепочке не участвует.
Клиент открывает мини-приложение, видит товар с ценой в рублях, выбирает размер, нажимает «Купить». Никаких «подождите, сейчас посчитаю». Никаких таблиц. Никаких пересчётов на калькуляторе.
Первый кандидат на автоматизацию — процесс, где ошибка напрямую бьёт по деньгам и доверию. Неправильная цена — это спор с клиентом, возврат, потеря лояльности. Правильная цена, выданная за секунду — это завершённый заказ.
Менеджер при этом не исчез из бизнеса. Он перестал тратить время на стандартные запросы — и получил возможность заниматься сложными случаями, нестандартными размерами, допродажами. Автоматизация не заменила человека, а убрала из его дня рутину, которая съедала 80% рабочего времени.
Как автоматизировали оплату и доставку без «скинь скриншот чека» и переписки с менеджером?
Каждая транзакция отслеживается автоматически через интеграцию с платёжной системой. Система сама переводит заказ в статус «Оплачен» — без менеджера, без ручной проверки, без «скинь скриншот чека».
Раньше менеджер буквально сидел и ждал подтверждение перевода. Потом шёл сверять. Потом менял статус. На каждый заказ уходило 3–5 минут только на этот этап. При 60 заказах в день — это до 5 часов чистого времени на одну только сверку оплат. Половина рабочего дня — на проверку скриншотов.
Доставку рассчитывает СДЭК API автоматически. Клиент вводит адрес или выбирает ПВЗ — и сразу видит стоимость, без единого вопроса менеджеру. Никаких «уточните у менеджера». После отправки бот сам присылает обновления статуса посылки.
Это две конкретные точки, где клиент раньше мог уйти: на этапе «а как платить?» и на этапе «а сколько доставка?». Чем меньше покупателю нужно спрашивать и ждать ответа на базовые вещи, тем выше вероятность, что он дойдёт до оплаты.
Зачем в этом проекте добавили бонусы, рефералку и промокоды с UTM, если задача начиналась с ошибок в расчётах?
Бонусная программа, реферальная система и промокоды с UTM-метками были в техническом задании с первого разговора — это не декоративный слой, добавленный «для красоты».
Клиент чётко понимал: автоматизация заказа решает операционную проблему, но не строит повторные продажи. Поэтому в проект заложили три механики удержания. Баллы за каждый заказ, которые можно списать при следующей покупке. Реферальная система: личная ссылка, бонусы за приведённых друзей. Промокоды с UTM-метками — чтобы владелец видел, какой канал привлечения реально приносит заказы.
Для малого бизнеса с ограниченным бюджетом на привлечение рефералка — один из самых дешёвых каналов роста. Привлечь нового клиента через рекламу стоит денег. Привлечь его через друга, который уже купил и доволен — стоит бонусных баллов. Разница ощутимая.
А UTM-промокоды — это про измеримость. Без них владелец не знает, работает ли его пост в Instagram, Telegram-канал или сарафанное радио. С ними — знает точно, вплоть до конкретного поста или конкретного блогера.
Какой технический выбор оказался ключевым и почему Redis здесь был не просто кэшем?
6 недель разработки, около 18 500 строк кода — проект оказался значительно крупнее, чем «просто бот». Backend на Python с aiogram 3 и FastAPI для REST API мини-приложения. PostgreSQL как основная база, Redis для кэша, Docker Compose для деплоя.
Главная техническая сложность была не в каталоге и не в оплате. Она была в синхронизации состояния между двумя интерфейсами — и по факту именно этот узел съел больше всего времени на отладку.
Представьте: клиент добавил кроссовки в корзину через мини-приложение. Потом закрыл его и написал боту «что у меня в корзине?». Или наоборот — начал в боте, продолжил в Web App. Оба интерфейса должны видеть одно и то же состояние заказа. В реальном времени. Если корзина в боте показывает одно, а в мини-приложении другое — пользователь теряет доверие и уходит.
Redis здесь работал не как кэш для ускорения запросов. Он был клеем между двумя контекстами — ботом и Web App. Каждое изменение состояния заказа записывалось в Redis и мгновенно становилось доступным обоим интерфейсам.
Для владельца бизнеса это означает одно: пользовательский опыт не ломается при переключении между каналами. Именно такие «невидимые» технические решения чаще всего определяют, будет ли продукт восприниматься как удобный или как сырой.
Какие результаты получили через два месяца и почему эти цифры важнее красивого интерфейса?
Через два месяца после запуска клиент прислал цифры: заказов стало больше на 40%, ошибок в расчёте стоимости — ноль.
40% роста — это не абстрактная метрика. Если до автоматизации бизнес обрабатывал 60 заказов в день, то после — около 84. Без найма второго менеджера. Без увеличения рекламного бюджета. Рост произошёл за счёт того, что воронка перестала терять людей на этапах расчёта, оплаты и уточнения доставки.
Ноль ошибок в расчётах — это не только про операционную чистоту. Это про отсутствие конфликтов. Каждая ошибка в цене раньше означала неприятный разговор, иногда — возврат, иногда — потерю клиента навсегда.