
Gemini в маркетинге почти всегда пытаются применить сразу к двум разным задачам — и именно поэтому проект буксует. Ассистент для команды (черновики постов, саммари созвонов, разбор отзывов) и бот для клиентов (меню, ответ по базе, заявка, запись, эскалация) живут по разным правилам: у них разные пользователи, разный источник правды и разная цена ошибки.
Ниже — как развести эти два контура, что в клиентском боте диктует не модель, а Telegram Bot API, и как собрать пилот, который меряется заявками, а не восторгом «оно отвечает как человек».
Два контура: разные пользователи, разная цена ошибки
| Контур | Пользователь | Источник правды | Цена ошибки | Кто модерирует |
|---|---|---|---|---|
| Внутренний ассистент | маркетолог, SMM, продажи | брифы, прайс, внутренняя база | потерянное время, слабый текст | сам сотрудник перед отправкой |
| Клиентский бот | посетитель, лид, клиент | утверждённый FAQ и прайс | неверная цена/срок клиенту, жалоба | никто в моменте — отвечает робот |
Вывод простой: внутреннему ассистенту можно давать свободу формулировок, клиентскому боту — нельзя. В клиентском контуре модель не «придумывает ответ», а переформулирует то, что уже согласовано.
Что Gemini реально закрывает в маркетинге
| Задача | Контур | Что даёт | Чего не даёт |
|---|---|---|---|
| Черновики постов и рассылок | внутренний | 5 вариантов хука за минуту | фактов о вашем прайсе |
| Саммари звонков и переписок | внутренний | список возражений и запросов | решения, что с этим делать |
| Кластеризация вопросов клиентов | внутренний | готовая структура FAQ | проверки формулировок |
| Ответ по базе знаний | клиентский | гибкое понимание вопроса | гарантии точности без базы |
| Квалификация лида | клиентский | мягкие уточняющие вопросы | оценки платёжеспособности |
| Запись и заявка | клиентский | сбор полей в диалоге | подтверждения слота без интеграции |
Обратите внимание: в клиентском контуре у модели остаётся ровно одна роль — понять вопрос и подобрать ответ из разрешённого набора. Всё остальное делает сценарий. Подробный разбор сравнения моделей — в материале ИИ чат-боты GPT и Gemini.
Что диктует канал, а не модель
Если клиентский бот живёт в Telegram, поведение задаёт не Gemini, а платформа. Три ограничения из официальной документации Telegram Bot API, которые меняют маркетинговый план:
- 1. Бот не пишет первым. Диалог начинает пользователь — бот может отвечать и писать дальше только тем, кто сам открыл переписку. Значит, «база подписчиков» набирается трафиком, а не выгрузкой контактов.
- 2. Два способа получать обновления — `getUpdates` (long polling) и webhook — взаимоисключающие. Пока включён webhook, long polling не работает; апдейты не хранятся на стороне Telegram дольше 24 часов. Это прямо влияет на то, теряете ли вы заявки при падении сервера.
- 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. Выгрузить 100 последних вопросов клиентов и собрать из них 30 пунктов FAQ.
- 2. Утвердить формулировки и запреты одним документом.
- 3. Собрать MVP: меню, ответ по базе, заявка, эскалация, алерт.
- 4. Запустить на один источник трафика и через 7 дней разобрать логи.
Нужна оценка по вашему сценарию — смотрите услугу чат-боты, ориентиры бюджета в разделе цены и напишите через контакты: по описанию задачи вернём состав работ и срок пилота.