Телеграм-бот для бизнеса: какую работу он реально забирает

Бот забирает не «общение с клиентами», а конкретные операции: перенос данных из сообщения в систему, поиск ответа в справочнике, отправку уведомления и подтверждение действия. Всё остальное он перекладывает — на базу за собой либо обратно на человека. Ниже — как это устроено изнутри, шаг за шагом.

Что происходит между сообщением и ответом

Со стороны выглядит просто: человек написал, бот ответил. Внутри между этими двумя событиями пять этапов.

Первый — получение. Бот либо сам опрашивает сервер мессенджера, либо сервер стучится на его адрес. Первый вариант проще в переносе и не требует внешнего адреса, второй быстрее реагирует на большом потоке.

Второй — разбор. Пришедшее сообщение — это не текст, а структура: кто написал, что нажал, в каком чате, был ли это ответ на прошлое сообщение. Из неё достаётся идентификатор пользователя, и по нему поднимается всё остальное.

Третий — состояние. Бот вспоминает, на каком шаге диалога находится этот человек. Без этого шага бот умеет только отвечать на команды по одной, без связи между ними.

Четвёртый — действие. Запрос в базу, создание заявки, проверка остатка, обращение к платёжной системе.

Пятый — ответ. Текст плюс кнопки, которые определяют, какие переходы возможны на следующем шаге.

Почему состояние — главная часть

Диалог «оформить заказ» состоит из шагов: что нужно, сколько, куда доставить, подтвердить. Между шагами человек может уйти на час, ответить не по порядку или начать заново.

Состояние — это запись в базе: пользователь, текущий шаг, накопленные данные. Хранится оно там же, где остальные данные проекта, а не в памяти работающего процесса. Разница видна при первом же перезапуске сервера: в первом случае человек продолжает с того места, где остановился, во втором — начинает сначала и обычно уходит.

Из этой же записи берётся ответ на вопрос «а что мне отвечали вчера». Историю диалога бот не помнит, он её читает.

Где на самом деле лежат данные

Бот ничего не хранит. Он читает и пишет в ту же базу, откуда работает сайт и админка.

Это не техническая деталь, а условие полезности. Клиент спрашивает статус заказа — бот делает запрос к таблице заказов, той самой, которую видит менеджер в панели. Сотрудник нажимает «Принять» в уведомлении — меняется поле в той же записи заказа, и через секунду новый статус виден на сайте.

Как только бот заводит собственное хранилище, появляются две правды. В одном месте заказ отменён, в другом ещё нет. Дальше это лечится сверками, и лечится плохо.

Поэтому бот проектируется как ещё один интерфейс к системе — наравне с сайтом и админкой, а не вместо них. Разграничение прав действует то же самое: сборщик через бота видит заказы, но не суммы; менеджер видит клиентов, но не настройки.

Какие операции бот действительно снимает

Перенос данных из переписки в систему. Раньше менеджер читал сообщение и печатал то же самое в форму. Теперь заявка приходит уже структурированной: имя, телефон, что нужно, когда.

Ответ на повторяющийся вопрос. Часы, адрес, условия доставки, статус заказа. Это не разговор, а справка, и справку выдаёт база.

Уведомление. Новый заказ, прошедшая оплата, отмена записи. Сообщение уходит в рабочий чат в момент события, а не когда кто-то обновит вкладку.

Подтверждение действия с телефона. Уведомление приходит с кнопками: принять, отклонить, перенести. Нажатие меняет статус в системе. Это тот сценарий, ради которого бота чаще всего и делают: он экономит не переписку, а вход в панель с телефона в дороге.

Разгрузка первой линии. Человек, которому нужен только адрес пункта выдачи, получает адрес и не занимает менеджера.

Что бот только перекладывает

Он не убирает работу, если работа была в другом месте. Если заявки терялись, потому что их некому обрабатывать, бот исправно принесёт их туда же.

Он не отвечает на то, чего нет в базе. Вопрос «есть ли в наличии» — это вопрос к остаткам. Без учёта остатков бот честно скажет «уточните у менеджера», и клиент не поймёт, зачем писал.

Он не ведёт переговоры. Цена под задачу, спорный возврат, недовольный клиент — это решения, и решения остаются людям. Бот может подготовить данные к разговору: поднять историю заказов, показать прошлые обращения.

Три инженерных решения, которые видно не сразу

Подтверждать сразу, отвечать потом. Если действие требует обращения к внешней системе, бот сначала отвечает «принято», а результат присылает вторым сообщением. Иначе человек видит молчание и нажимает кнопку ещё три раза.

Защищаться от повторов. Одно и то же нажатие может прийти дважды. Каждое действие, которое создаёт заказ или платёж, должно уметь распознать, что оно уже выполнено, и не создавать второй.

Уведомление обязано пережить недоступность. Мессенджер иногда недоступен. Уведомление ставится в очередь и повторяется, а не теряется молча. Тот же принцип, что и на стыке магазина с перевозчиком: шаг, который может не пройти, обязан оставлять след.

Как понять, сколько работы бот заберёт у вас

Считать нужно до разработки, и считается это просто.

Возьмите переписку менеджера за одну обычную неделю. Разметьте сообщения на три группы: справка (адрес, часы, статус, наличие), сбор данных (имя, телефон, что нужно, когда), решения (цена под задачу, возврат, спор).

Первые две группы бот забирает целиком. Третью не забирает вообще. Соотношение групп в вашей переписке и есть ответ, причём часто неожиданный: у одних справочных сообщений три четверти, у других — пятая часть.

Отдельно посчитайте, сколько раз за неделю сотрудник заходил в панель с телефона ради одного действия. Каждый такой заход — кандидат на кнопку в уведомлении, и обычно именно здесь экономия времени самая заметная.

Когда бот не нужен

Если поток обращений — пять в день и все разные, бот не окупится: разрабатывается он не бесплатно, а забирает только повторяющееся. Считайте по числу одинаковых сообщений, а не по общему числу.

Если за ботом ничего нет — ни базы, ни админки, ни учёта заказов, — начинать нужно не с него. Такой бот умеет пересылать сообщения и показывать заранее написанный текст, и потолок здесь достигается за месяц. Разумнее сначала собрать систему, а бота добавить интерфейсом. Вилки по разработке — на странице цен.

И третье: бот не должен быть единственным входом. Часть людей в мессенджер не пойдёт, форма на сайте и телефон остаются.

Коротко

Внутри бота пять этапов: получение, разбор, состояние, действие, ответ. Главный из них — состояние, и оно обязано лежать в базе, а не в памяти процесса. Данных у бота своих нет: он читает и пишет туда же, куда сайт и админка, иначе появляются две правды. Забирает он перенос данных из переписки, справочные ответы, уведомления и подтверждение действий с телефона. Не забирает переговоры, решения и то, чего нет в базе.