Онлайн-чат для криптообменника — не косметика на сайте, а часть инфраструктуры продаж и поддержки. Обычные SaaS-чаты для интернет-магазинов закрывают базовые сценарии, но плохо ложатся на специфику обмена крипты: оператору нужна привязка диалога к заявке, Telegram — как полноценный канал, и контроль над собственными данными. Ниже — по полкам, что реально должен уметь такой чат и как он устроен.
Почему обычный SaaS-чат плохо подходит обменнику
Стандартный чат для e-commerce думает в терминах «корзин» и «заказов». В обменнике у диалога другая привязка — заявка на обмен с конкретным направлением, суммой, реквизитами и статусом транзакции. Когда оператор пишет клиенту, он должен видеть эту заявку сразу, без переключений между вкладками.
Плюс к этому — половина клиентов приходит из Telegram, а не с сайта. Каналы должны работать в одной очереди, а не в трёх параллельных мессенджерах. И ещё специфика: переписка часто содержит адреса кошельков, хеши транзакций, иногда — данные KYC. Хранить это в чужой облачной инфраструктуре — отдельный риск, который не каждый обменник готов принимать.
Виджет на сайте: четыре режима под разные стратегии
Не каждому обменнику нужен полноценный чат на сайте 24/7. Виджет имеет смысл проектировать с возможностью выбрать один из четырёх режимов:
- Native — встроенный чат прямо на сайте: клиент пишет, не уходя из обменника.
- Telegram fallback — основной чат на сайте, но если оператор не онлайн, виджет предлагает писать в Telegram.
- Только Telegram — для аудитории, которая по умолчанию живёт в мессенджере.
- Внешний — кнопка переадресует в стороннюю систему, если у вас уже есть инфраструктура поддержки.
Виджет должен настраиваться под бренд — цвета, аватары, текст приветствия. Без чужого «powered by» в углу.
Кабинет оператора: где живёт вся работа
Главное место, где работает поддержка, — это рабочий кабинет оператора. Что в нём должно быть:
- Очередь диалогов с приоритетами и распределением между сменами.
- Карточка клиента с контекстом заявки: какой обмен, какая сумма, в каком статусе.
- Шаблоны ответов на типовые вопросы — «когда придёт перевод», «почему пришла не та сумма».
- Теги для маркировки сложных кейсов и быстрого поиска.
- Защита от двойного ответа: если два оператора одновременно открыли диалог, второму система покажет, что кейс уже занят.
Сценарий из жизни: клиент пишет «где мой перевод», оператор открывает диалог и сразу видит в правой панели его заявку, статус сети, хеш транзакции. Ответ занимает 20 секунд вместо пяти минут перекрёстных проверок.
Один кабинет на несколько обменников
Если у вас два-три обменника под разными доменами, держать три копии чата неудобно. Мультисайт-режим позволяет вести всё из одного кабинета: операторы видят, с какого обменника пришёл клиент, переключаться между «инстансами» не нужно. Это особенно полезно тем, кто работает на нескольких рынках или ведёт партнёрские проекты.
Каналы: Telegram, почта, API
Большинство обменников ловят клиентов сразу из нескольких мест. Хороший чат сводит их в одну очередь:
- Telegram-мост. Бот собирает входящие сообщения из Telegram и кладёт в общий поток. Ответ оператора уходит обратно в Telegram под именем бота.
- Почта. Входящие письма становятся диалогами; ответы оператора уходят с вашего домена.
- REST API. Можно создавать диалоги из своих скриптов — например, при определённых событиях по заявке.
- Webhooks. Уведомления о новых сообщениях, статусах, действиях оператора — можно встроить в CRM или внутренний Telegram-чат команды.
Главное — клиент не сталкивается с «напишите нам в нашей системе тикетов», а пишет туда, где ему удобно.
Realtime и безопасность
Реалтайм
Под капотом — стек на WebSocket-ах (Socket.IO) и Redis для синхронизации событий между процессами. На уровне UX это даёт:
- Видно, что клиент сейчас печатает (typing indicator).
- Прочтения и presence — онлайн ли оператор и клиент.
- Очередь обновляется без перезагрузки страницы.
- Если двое начали отвечать одному клиенту, система блокирует второго и подсказывает, что диалог уже взят.
Мелочь, но именно она убирает основные косяки поддержки: дублирующиеся ответы, забытые диалоги, путаницу в смене.
Безопасность
Поддержка в обменнике работает с чувствительными данными. Что должно быть на уровне платформы:
- Двухфакторная аутентификация для операторов — обязательная, не «по желанию».
- Защищённые сессии: токены с ограниченным временем жизни, привязка к устройству.
- Audit-журнал: кто и когда вошёл, ответил, переназначил диалог, удалил сообщение.
- Шифрование данных на сервере, доступы на уровне ролей.
Если регулятор или партнёрский банк попросит показать организацию доступов и логов — есть что показать.
Self-hosted: данные остаются у вас
Главное архитектурное решение — ставить чат на свой сервер, а не использовать чужое облако. Технически это базовый стэк: NestJS на бэкенде, React на фронте, Postgres для данных, Redis для realtime, всё в Docker. Что это даёт:
- Переписка и данные клиентов остаются в вашем контуре. Никакого третьего вендора, который может однажды отключить аккаунт.
- Никакой посекундной телеметрии в чужом облаке — легче проходить compliance-аудит.
- Никакой посеатной оплаты: добавляете операторов столько, сколько нужно, не упираясь в лицензию.
Минусы тоже есть, по-честному: нужен VPS, нужно следить за обновлениями, в команде должен быть человек с базовым DevOps. Если этого нет — облачный SaaS-чат проще на старте, но рано или поздно вы упрётесь в его ограничения.
Вывод
Чат на сайте обменника — это инструмент конверсии и удержания, а не «галочка для лендинга». Хороший чат сокращает время ответа в разы, сводит Telegram и сайт в одну очередь и оставляет данные клиентов под вашим контролем. Если запускаете или масштабируете обменник и хотите готовое self-hosted решение под эту задачу — посмотрите iEXChat.
