feel90d 26 авг в 07:00

Как мы за 5 дней собрали контакт-центр для фитнес-клуба на Chatwoot и подключили к WhatsApp, Telegram и VK

Средний

10 мин

924

Мессенджеры * CRM-системы * Open source * Python * DevOps *

Кейс

В конце статьи - ссылка на GitHub-репозиторий с исходниками нашего Python-шлюза для Chatwoot, WhatsApp, Telegram и VK.

Зачем все это нужно?

Обычное утро администратора фитнес-клуба
WhatsApp пикает — клиент спрашивает про расписание. В Telegram — кто-то хочет заморозить абонемент. Во ВКонтакте прилетает новая заявка на пробное занятие, а в e-mail запрос от корпоративного клиента. Между этим нужно ещё принять звонок и не забыть всем вовремя ответить.
Итог предсказуем: кто-то ждет ответа полдня, часть обращений теряется, а кто-то просто уходит к тем, кто отвечает быстрее.

Мы проанализировали 38697 диалогов с клиентами клуба и выяснили: 83.9% нагрузки — это рутинные, повторяющиеся сценарии (поздравления с днем рождения, запись/подтверждение, вопросы по расписанию). А ведь это всё можно было бы автоматизировать — чтобы менеджеры/администраторы тратили время на продажи и действительно важные вопросы, а не однотипные “Добрый день! Подтверждаю запись”.

Вся эта рутина отлично видна на реальных данных:

Почти половина всех диалогов — просто поздравления с днём рождения. Следом — подтверждение записи, напоминания, вопросы по картам и акциям. Всё это можно автоматизировать.

Если разложить диалоги по месяцам и темам, становится ещё очевиднее, насколько много однотипных повторяющиеся сценариев:

Большинство обращений месяц за месяцем — одни и те же сценарии. Это явный сигнал для бизнеса заняться автоматизацией.

Чего мы хотели добиться:

Собрать все каналы в одно окно — чтобы у оператора всегда был полный контекст по клиенту: история, теги, SLA, кто, когда и по какому поводу обращался.
Ввести реальные метрики реакции (FRT/DRT, SLA): чтобы видеть, где «узкие места», и не терять лидов из‑за задержек.
Подготовить инфраструктуру под ИИ‑ассистентов: чтобы в будущем можно было подхватывать типовые вопросы без участия оператора.

Почему не выбрали SaaS‑решение «из коробки»:

Open‑source и независимость. Мы хотели не зависеть от очередного SaaS‑провайдера, а сделать платформу «под себя»: дорабатывать любые фичи, не ждать поддержки, не бояться внезапных изменений тарифов или политик.
У нас уже был основной номер WhatsApp, который сохранили себе несколько тысяч клиентов — и для нас было критично сохранить с ним связь. Наш подход (через Wasender) позволил работать именно с этим же номером, не теряя контакт с существующей аудиторией, и при этом мы можем писать клиенту первым, а не только отвечать на входящие — в отличие от большинства официальных бизнес‑интеграций.
То же самое с Telegram: через Telethon мы подключили именно «живой» аккаунт, а не бота — это единственный способ вести диалог от лица реального человека, а не от «машины», и тоже писать первым, как в обычном мессенджере.
Гибкая интеграция под будущие задачи, в том числе с 1С. Мы заранее думали о «двусторонней» интеграции: чтобы диалоги клиентов из мессенджеров отображались прямо в карточке клиента в 1С. Для SaaS‑платформ это все равно нужно будет дописывать руками.

Что такое Chatwoot — в двух словах

Chatwoot — это open-source платформа для поддержки клиентов, где можно собирать обращения из разных каналов (мессенджеры, e-mail, сайт, соцсети) в одном окне.

Вот как выглядит интерфейс:

Почему это удобно для фитнес-клуба?

Все диалоги — WhatsApp, Telegram, VK, e-mail, webchat — видны в одном интерфейсе.
Легко отслеживать метрики реакции: SLA, кто когда ответил, сколько висит без ответа.
Можно хранить любые дополнительные атрибуты клиента (например, ID из 1С, дату рождения, custom-поля под маркетинг).
Есть мобильное приложение и поддержка русского языка.
Бесплатно, без жесткой привязки к провайдерам и тарифам за каждый канал.
У платформы есть события через webhook - удобно интегрировать с ИИ-агентами.

Пара слов про wasender и telethon

Wasender — это API для WhatsApp за $6 в месяц, который позволяет подключить обычный (не бизнес-аккаунт) номер телефона, а значит, мы можем писать клиентам первым, как из обычного приложения.
Telethon — python‑библиотека для работы с Telegram, с помощью которой можно «подключиться» как обычный пользователь, а не бот (как бот она тоже умеет). Это способ вести диалог от лица администратора клуба, а не бота, и тоже начинать общение первым.

Архитектура решения: как всё устроено

Мы разделили каналы на две группы: одни можно сразу подключить к Chatwoot «из коробки», другие — такие как Wasender, Telegram и VK — требуют самописного шлюза.

Схема такая:

Каналы, которые нельзя напрямую подключить в Chatwoot (обычный WhatsApp-номер, Telegram, VK-группа) — идут через наш шлюз на Python. Он нормализует сообщения, стыкует их с нужным inbox, прокидывает в Chatwoot через API и обратно.
Встроенные каналы (Telegram Bot, e-mail, webchat) — спокойно подключаются к Chatwoot напрямую, без костылей.

Почему так:

В Chatwoot нет поддержки обычного аккаунта WhatsApp (только WhatsApp Business API), а Telegram можно подключить лишь через Bot API, но не напрямую как пользовательский аккаунт.
Наш шлюз как «универсальный адаптер»: он позволяет обойти ограничения и подключать любые нестандартные каналы.

Как это работает на практике

Когда клиент пишет в WhatsApp, Telegram, VK (через шлюз) или напрямую подключённый канал (e-mail, webchat, Telegram Bot) — все сообщения в итоге попадают в Chatwoot. Оператор видит единую историю и работает в одном окне.

Для каналов, которые идут через наш шлюз:

Шлюз, используя Chatwoot API (API Reference), сам создаёт (или находит) контакт, беседу и сообщение в интерфейсе Chatwoot — для Chatwoot всё выглядит как обычная внешняя интеграция через API.
Когда оператор отвечает клиенту из Chatwoot, мы подписываемся на события через webhooks (пример — на скриншоте ниже). Как только приходит событие message.created, наш шлюз получает детали сообщения и отправляет его обратно в нужный мессенджер клиенту.

На скриншоте: список событий, которые можно получать через webhook для построения собственной интеграции — например, message.created для обработки и отправки ответа клиенту в WhatsApp, Telegram или VK.

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

В чём профит такого подхода

Максимальный охват: часть каналов подключена «как есть», часть — через шлюз, поэтому не теряем ни одного клиента.
Гибкость: если завтра появится новый мессенджер (привет, MAX) или специфический канал — просто добавим новый адаптер к шлюзу, а Chatwoot останется центром коммуникации.
Простота автоматизации и ИИ: любые события (message.created, contact.updated и др.) легко передавать во внешние сервисы, ИИ-агентов, 1С и т.п.

Архитектура шлюза и компонентов

Шлюз написан на Python с использованием FastAPI. В качестве «имитации» event bus мы использовали библиотеку pyee — это быстрый способ организовать обработку событий между модулями, но не полноценная промышленная шина. В реальном проекте рекомендуется использовать что‑то серьёзнее, например RabbitMQ или Kafka.

Структура шлюза модульная, с элементами гексагональной архитектуры:

Каждый канал (WhatsApp, Telegram, VK) реализован отдельным адаптером, который занимается разбором входящих и отправкой исходящих сообщений.
Адаптеры обрабатывают события из своих каналов, нормализуют данные, пробрасывают их дальше через общие методы API.
Вся логика интеграции максимально вынесена за пределы ядра - можно легко добавить новый канал или связать шлюз с внешним сервисом (например, AI-агентом или CRM), не переписывая основную логику.

Почему так?
Модульность плюс гексагональная архитектура дают простую поддержку, быстрые изменения и удобную интеграцию новых сценариев — достаточно реализовать новый адаптер или endpoint, не ломая остальной код.

Краткие примеры интеграции: WhatsApp ↔ Chatwoot через Wasender

1. Получение сообщений из WhatsApp и создание их в Chatwoot

Когда клиент пишет в WhatsApp, Wasender отправляет webhook на наш шлюз, хендлер /wasender/webhook/{webhook_id} обрабатывает запрос так:

@router.post("/wasender/webhook/{webhook_id}", response_model=dict)
async def wasender_webhook(
    webhook_id: str,
    payload: WasenderWebhookPayload,
    x_webhook_signature: str | None = Header(default=None, alias="X-Webhook-Signature"),
):
    # Проверяем ID и секрет для безопасности
    if webhook_id != config.wasender.webhook_id:
        raise HTTPException(status_code=403, detail="Invalid webhook ID")
    if x_webhook_signature != config.wasender.webhook_secret:
        raise HTTPException(status_code=403, detail="Invalid X-Webhook-Signature")

    event = payload.event
    if event == "messages.upsert":
        raw = payload.data["messages"]
        key = raw["key"]
        from_me = key["fromMe"]
        # Рассылаем событие в “шину”: входящее или исходящее
        bus.emit("wasender.outgoing" if from_me else "wasender.incoming", payload.model_dump())
    return {"status": "ok"}

Что происходит:

Проверяются ключи и секреты (защита от лишних запросов).
Для события messages.upsert разбирается, кто отправитель (оператор или клиент).
Событие попадает в "шину", где дальше по коду создаётся контакт, диалог и сообщение в Chatwoot.

2. Отправка ответного сообщения из Chatwoot обратно в WhatsApp (через Wasender)

Когда оператор отвечает клиенту из Chatwoot, шлюз ловит webhook /chatwoot/webhook/{webhook_id}:

@router.post("/chatwoot/webhook/{webhook_id}", response_model=dict)
async def chatwoot_webhook(webhook_id: str, request: Request):
    channel = config.chatwoot.channel_by_webhook_id.get(webhook_id)
    if not channel and webhook_id != config.chatwoot.webhook_id:
        raise HTTPException(status_code=403, detail="Unknown webhook ID")

    payload = await request.json()
    event = payload.get("event")
    msg_type = payload.get("message_type")
    conv = payload.setdefault("conversation", {})
    meta = conv.setdefault("meta", {})
    if channel:
        meta["channel"] = channel

    if event == "message_created":
        if msg_type == "incoming":
            bus.emit("chatwoot.incoming", payload)
        elif msg_type == "outgoing":
            bus.emit("chatwoot.outgoing", payload)
    return {"status": "received"}

Что происходит:

Проверяется идентификатор webhook (много каналов — много хуков).
Информация о канале добавляется в payload.
Если это событие message_created и сообщение исходящее, оно попадает в "шину" как chatwoot.outgoing.
Далее роутер сообщений сам решает, через какой канал (адаптер) (Wasender, Telethon, VK) отправлять клиенту.

Все остальные интеграции (Telegram, VK и др.) реализованы по тому же принципу и доступны в исходниках — ссылка на репозиторий будет в конце статьи.

Грабли и подводные камни: что пошло не так

WhatsApp (Wasender):

Очень низкий порог входа (6$ в месяц, можно писать первым), но:
- Нужна нероссийская карта для оплаты — для кого-то это возможно будет проблемой, но это сильно дешевле любой интеграции доступной в РФ.
- Риск бана за спам — если слать много массовых рассылок, аккаунт быстро заблокируют. Но это общее место, конкретно к Wasender/WhatsApp отношения не имеет.
- При большом объёме сообщений нужна очередь и контроль частоты отправки.
Отправка статуса сообщения API отдает не сразу - пришлось реализовать "бэкофф" (повтор с увеличивающейся задержкой).

Telegram (Telethon):

Реальная угроза банов: при первом запуске через Telethon разлогинило на всех устройствах, и чуть не схватили бан. Опытным путем выяснили, что надо заполнять device_model, system_version и делать паузы между действиями.
Интерактивная авторизация: сессия хранится в файле. Такой вариант, как в репозитории, не подходит для прода - при первом запуске всё равно нужно вводить логин и пароль. Для прода стоит реализовать отдельные ручки для авторизации.

VK (Callback API):

VK не отдаёт телефон пользователя по API, а многие клиенты зарегистрированы только на номер. Пришлось добавить custom-атрибуты (vk_user_id, vk_peer_id) для связи карточек клиентов.
В варианте с callback-api сервер должен быть доступен из интернета (локально можно отлаживать с ngrok).
Дополнительные атрибуты. Можно дообогащать данные клиентов (дата рождения, город, количество подписчиков), но заполнены не всегда.

Прочее:

Объединение контактов: если клиент сначала пишет в WhatsApp, а потом — в VK, Chatwoot по умолчанию создаёт две разные карточки. Помогает функция merge: можно объединить профили вручную, а custom-атрибуты позволяют автоматизировать этот процесс.
Event bus: pyee - не настоящая шина, в проде обязательно нужен брокер (Kafka, RabbitMQ), чтобы не терять события и масштабироваться.
Безопасность: все ключи, токены и файлы сессий вынесены в .env (в исходнике — пример .env_template). Для продакшена лучше хранить секреты в секрет-хранилищах (Vault, AWS Secrets Manager).
Rate limiting и anti-spam: обязательно следить за частотой отправки, не игнорируйте лимиты и не экспериментируйте с массовыми рассылками на боевых номерах.

Что получилось на выходе и метрики

Как изменилось после внедрения

После перехода на Chatwoot получили рост прозрачности процессов - теперь все обращения из WhatsApp, Telegram, VK и e-mail идут в одно окно, ничего не теряется, вся история общения с клиентом видна в одном месте. Проще контроллировать. Администраторы и менеджеры перестали путаться между окнами и мессенджерами: для каждого клиента - вся переписка, комментарии, теги, SLA - все в одном месте.

Ощутимые результаты (цифры — примерные, но на основе реального эффекта):

Скорость ответа (FRT) для входящих сообщений сократилась с 20–40 минут до 3-5 минут даже в часы пик.
Доля неотвеченных обращений стала чуть ниже: раньше часть диалогов могла теряться, теперь почти все обращения фиксируются и закрываются, пропусков практически нет.
До 80% всех диалогов — это типовые сценарии (ДР, запись, напоминание, вопросы по картам), и их теперь можно быстро автоматизировать либо закрывать полуавтоматически через заготовленные в Chatwoot шаблоны.
Заметно снизилась нагрузка на администраторов: вместо того, чтобы постоянно прыгать между приложениями, они работают в едином окне, быстро находят нужную переписку и могут фокусироваться на сложных вопросах и продажах.

Главный бизнес-эффект

Меньше потерь лидов: когда все обращения из каналов фиксируются и идут по единому процессу, меньше ситуаций “кто-то забыл перезвонить” или “забыли отправить подтверждение”.

Что дальше / Планы на развитие

Основной вектор развития — AI-автоматизация клиентских сценариев. Уже сейчас вся инфраструктура позволяет подключить LLM-агента - достаточно добавить логику автодействий на стороне шлюза.

В ближайшее время планируем:

Автоматизировать ответы на типовые вопросы (расписание, запись, акции, подтверждение, FAQ) полностью через AI‑агента.
Реализовать автоматические поздравления с днем рождения, напоминания о тренировках, простые upsell прямо через сценарии в шлюзе — без участия операторов.
Разработать «умные» фильтры, чтобы AI‑агент подключался только когда действительно может помочь.
Используя RAG (Retrieval‑Augmented Generation) отвечать на вопросы клиентов используя информацию из базы знаний.

Заключение и выводы

В нашем кейсе за 5 дней мы собрали полноценный омниканальный контакт‑центр для фитнес‑клуба, избавились от рутины и получили инфраструктуру, готовую к подключению AI‑агента и интеграции.

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

Где ещё можно применить это решение:

Сервисные и b2c-компании с большим потоком чатов: медицинские центры, стоматологии, школы и детские кружки, салоны красоты.
Колл‑центры, где важно не терять ни одного клиента и нужен «живой» номер для коммуникации.
Компании, у которых часть клиентов привыкла писать в WhatsApp/Telegram на личный номер, а бизнесу нужно централизовать историю и аналитику.

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

Исходники шлюза и готовых адаптеров выложены в открытый доступ — ссылка тут.

Спасибо, что дочитали до конца! Буду рад обратной связи, вопросам и комментариям.

Хабы: