Чат-бот Gemini для маркетинга

Gemini в маркетинге: внутренний ассистент против клиентского бота, ограничения Telegram Bot API, сценарии FAQ, лида и записи, метрики пилота и чеклист запуска.

Gemini для маркетинга
Gemini для маркетинга

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

Ниже — как развести эти два контура, что в клиентском боте диктует не модель, а Telegram Bot API, и как собрать пилот, который меряется заявками, а не восторгом «оно отвечает как человек».

Два контура: разные пользователи, разная цена ошибки

КонтурПользовательИсточник правдыЦена ошибкиКто модерирует
Внутренний ассистентмаркетолог, SMM, продажибрифы, прайс, внутренняя базапотерянное время, слабый текстсам сотрудник перед отправкой
Клиентский ботпосетитель, лид, клиентутверждённый FAQ и прайсневерная цена/срок клиенту, жалобаникто в моменте — отвечает робот

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

Что Gemini реально закрывает в маркетинге

ЗадачаКонтурЧто даётЧего не даёт
Черновики постов и рассылоквнутренний5 вариантов хука за минутуфактов о вашем прайсе
Саммари звонков и переписоквнутреннийсписок возражений и запросоврешения, что с этим делать
Кластеризация вопросов клиентоввнутреннийготовая структура FAQпроверки формулировок
Ответ по базе знанийклиентскийгибкое понимание вопросагарантии точности без базы
Квалификация лидаклиентскиймягкие уточняющие вопросыоценки платёжеспособности
Запись и заявкаклиентскийсбор полей в диалогеподтверждения слота без интеграции

Обратите внимание: в клиентском контуре у модели остаётся ровно одна роль — понять вопрос и подобрать ответ из разрешённого набора. Всё остальное делает сценарий. Подробный разбор сравнения моделей — в материале ИИ чат-боты GPT и Gemini.

Что диктует канал, а не модель

Если клиентский бот живёт в Telegram, поведение задаёт не Gemini, а платформа. Три ограничения из официальной документации Telegram Bot API, которые меняют маркетинговый план:

  1. 1. Бот не пишет первым. Диалог начинает пользователь — бот может отвечать и писать дальше только тем, кто сам открыл переписку. Значит, «база подписчиков» набирается трафиком, а не выгрузкой контактов.
  2. 2. Два способа получать обновления — `getUpdates` (long polling) и webhook — взаимоисключающие. Пока включён webhook, long polling не работает; апдейты не хранятся на стороне Telegram дольше 24 часов. Это прямо влияет на то, теряете ли вы заявки при падении сервера.
  3. 3. Токен бота — секрет. Он даёт полный контроль над ботом, поэтому не живёт в репозитории, в чате с подрядчиком и в скриншотах. Только переменные окружения и ограниченный доступ.

Первый пункт — главный для маркетинга. Он означает, что Telegram-бот не канал холодных рассылок, а точка приёма уже прогретого трафика: из рекламы, контента, QR-кода, подписи в письме, кнопки на сайте.

Архитектура клиентского бота

Трафик (реклама / контент / сайт / QR)
 → deep-link со стартовым параметром (источник)
 → приветствие + меню из 3-5 пунктов
 → вопрос пользователя
 → поиск по утверждённой базе FAQ
 → если совпадение уверенное -> ответ + следующий шаг
 → если нет -> уточняющий вопрос -> эскалация человеку
 → заявка/запись -> CRM + алерт менеджеру
 → лог диалога для еженедельного разбора

Ключевой узел — ветка «нет уверенного совпадения». Без неё ИИ-бот начинает досочинять, и вы узнаёте об этом из отзыва клиента. Правильное поведение: «Уточню у специалиста, отвечу в течение рабочего дня» и реальный алерт менеджеру.

Три сценария, которые окупаются первыми

1. FAQ. Стоимость, сроки, состав услуги, гарантии, как начать. Собирается из реальной переписки за последние 2–3 месяца: выгружаете вопросы, кластеризуете, формулируете 25–40 ответов и утверждаете их у владельца услуги. Это единственный источник правды для бота.

2. Лид. Бот задаёт 3–4 вопроса: задача, город, срок, контакт. Больше полей — ниже доходимость. Ответы уходят в CRM и в чат менеджеру одним сообщением, чтобы не пересобирать диалог вручную.

3. Запись. Работает, если есть расписание и правило подтверждения. Минимально честная схема: бот собирает желаемый слот и контакт, администратор подтверждает. Автоматическое бронирование слота подключают, когда есть интеграция с календарём или системой записи — иначе получите двойные брони.

Начинать имеет смысл с FAQ и лида: они дают измеримый эффект без интеграций. Запись — второй этап.

Промпт-контур и запреты

Инструкция клиентского бота — это не «будь вежливым ассистентом», а список границ:

  • - отвечать только по предоставленной базе; при отсутствии данных — эскалация;
  • - не называть цены, которых нет в прайсе, и не обещать сроки «под ключ за день»;
  • - не давать юридических, медицинских и финансовых советов;
  • - не спорить с клиентом и не оценивать его бюджет;
  • - при словах «жалоба», «возврат», «суд», «не работает» — сразу человек;
  • - один ответ — одна мысль и один следующий шаг.

Запреты работают лучше, чем инструкции про тон: они проверяемы на тестовом прогоне.

Данные, приватность и география

Для проектов в России есть три практических требования, которые лучше заложить сразу:

  • - Согласие. Если бот собирает имя, телефон, e-mail — это персональные данные. Нужны согласие и ссылка на политику обработки прямо в шаге сбора контакта.
  • - Минимизация. Не собирайте то, что не используете. Паспортные данные, дата рождения «для статистики» и адрес до заказа — лишние поля и лишний риск.
  • - Часовые пояса. Клиент из Владивостока пишет, когда в Москве ночь. Бот должен честно сообщать режим работы менеджера и время ответа, а не молчать до утра. Для сетевых компаний в расписании учитывают локальный часовой пояс филиала.

Отдельно: тексты для российской аудитории проверяйте на канцелярит и кальки с английского — модели охотно выдают «наш сервис предоставляет решения», что в переписке звучит чужеродно.

Метрики пилота

МетрикаЧто показываетОриентир для разбора
Доля закрытых без человекакачество базы FAQрастёт неделя к неделе
Доля эскалацийгде база дыряваякаждая эскалация -> новый пункт FAQ
Заявки из ботаденьгисравниваем с формой на сайте
Доходимость по шагамгде отваливаютсяпадение >40% на шаге = лишний вопрос
Время до ответа менеджерареальная скоростьалерт без реакции = бот бесполезен
Источник входа (deep-link)какой трафик работаетотключаем то, что не даёт заявок

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

Частые ошибки

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

Частые вопросы

Gemini или GPT — что выбрать для маркетингового бота?

Решает не бренд модели, а ваша база FAQ и правила эскалации. Честный способ выбрать — прогнать 30–50 реальных вопросов клиентов через обе модели с одной и той же базой и сравнить долю ответов, которые вы готовы отправить клиенту без правок.

Можно ли собрать базу подписчиков бота и делать рассылки?

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

Сколько вопросов нужно в базе, чтобы бот был полезен?

Обычно хватает 25–40 хорошо сформулированных ответов: они закрывают основную массу обращений. Дальше база растёт из логов эскалаций, а не из фантазии.

Бот заменит менеджера?

Нет. Он снимает повторяющиеся вопросы и собирает заявку в нерабочее время. Сделки, торг и нестандартные случаи остаются человеку.

Нужен ли отдельный бот под каждый филиал?

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

Чеклист перед запуском

  • - [ ] Контуры разведены: ассистент команды и клиентский бот — разные проекты
  • - [ ] База FAQ утверждена владельцем услуги, у каждого ответа есть автор
  • - [ ] Ветка «не знаю» ведёт к человеку, алерт проверен вживую
  • - [ ] Токен в переменных окружения, доступ ограничен
  • - [ ] Выбран один способ приёма обновлений: webhook или polling
  • - [ ] Согласие на обработку данных и ссылка на политику в шаге контакта
  • - [ ] Указан режим работы и время ответа с учётом часового пояса
  • - [ ] Deep-link со стартовым параметром для каждого канала трафика
  • - [ ] Заведены метрики и дата разбора логов

Что сделать на этой неделе

  1. 1. Выгрузить 100 последних вопросов клиентов и собрать из них 30 пунктов FAQ.
  2. 2. Утвердить формулировки и запреты одним документом.
  3. 3. Собрать MVP: меню, ответ по базе, заявка, эскалация, алерт.
  4. 4. Запустить на один источник трафика и через 7 дней разобрать логи.

Нужна оценка по вашему сценарию — смотрите услугу чат-боты, ориентиры бюджета в разделе цены и напишите через контакты: по описанию задачи вернём состав работ и срок пилота.

Оставить заявку · Все статьи