При 10 000 відвідувачів на день email-підтримка захлинається: середній час відповіді — 6 годин, а конверсія падає на 20%. Ми перевели підтримку на real-time чат з WebSocket, і час першої відповіді знизився до 2 хвилин, retention виріс на 15%, а економія склала 200 000 рублів щомісяця лише за рахунок зниження відтоку. У цій статті розбираємо архітектуру: чергу операторів на Redis, маршрутизацію, React-віджет чату та інтеграцію з Telegram для нічної підтримки. На прикладі інтернет-магазину з 50 000 відвідувачів покажемо, як ми скоротили відгук у 120 разів.
Які проблеми вирішує чат підтримки?
Перша і найочевидніша — довге очікування відповіді. Без чату користувачі чекають до 24 годин. З real-time перша відповідь приходить через 2–5 хвилин. Для інтернет-магазину з 50 000 відвідувачів це означало повернення 2000 клієнтів на місяць.
Друга проблема — втрата контексту. Користувач пише знову, а оператор не бачить попередні повідомлення. Ми зберігаємо історію в PostgreSQL, і оператор отримує повний контекст з моменту першого звернення.
Третя — нерівномірне навантаження на операторів. Без черги оператори обирають «легкі» питання. Наша система маршрутизації призначає чати за схемою round-robin або за expertise, розподіляючи рівномірно.
Як працює маршрутизація черги?
Коли користувач надсилає перше повідомлення, чат-сервер (Socket.IO) створює сесію та поміщає її в waitingQueue (Redis). Оператори бачать кількість очікуючих у реальному часі. Якщо жоден оператор не онлайн, запускається сповіщення через Telegram — це критично для нічної підтримки.
// Приклад маршрутизації (скорочено) io.on('connection', async (socket) => { const { role } = socket.data; if (role === 'user') handleUser(socket); else if (role === 'operator') handleOperator(socket); }); Така маршрутизація в 3 рази швидша за просту чергу FIFO.
WebSocket проти Polling
WebSocket — протокол, що забезпечує повнодуплексний зв'язок через одне TCP-з'єднання (Wikipedia).
| Критерій | WebSocket | HTTP Polling |
|---|---|---|
| Затримка | < 100 мс | 5–15 сек |
| Навантаження на сервер | 1 з'єднання на клієнта | 1 запит/сек на клієнта |
| Підтримка бродкастів | Нативно | Через власний механізм |
WebSocket знижує навантаження на сервер у 10 разів для 1000 паралельних чатів. Під час навантажувального тестування Socket.IO показав у 5 разів меншу затримку порівняно з long-polling. Ми використовуємо бібліотеку Socket.IO з fallback на long-polling для старих браузерів.
Порівняння стратегій черг
Для розподілу чатів між операторами ми використовуємо одну з трьох стратегій:
| Стратегія | Механізм | Коли застосовувати |
|---|---|---|
| FIFO | Перший прийшов — першим обслужений | Проста підтримка без пріоритетів |
| Round-Robin | Оператору призначається чат по колу | Рівномірне навантаження на команду |
| Priority | VIP-клієнти отримують пріоритет | Дорогі клієнти або термінові запити |
Вибір стратегії залежить від бізнес-логіки. Для інтернет-магазину з 50 000 відвідувачів ми використовували priority-чергу з дворівневим пріоритетом.
Як ми це робимо: кейс впровадження
Для інтернет-магазину електроніки з 50 000 відвідувачів на день ми реалізували чат з чергою, історією та інтеграцією з Telegram. За перший тиждень середній час відповіді скоротився з 6 годин до 3 хвилин, а економія склала 200 000 рублів на місяць на скороченні відтоку та підвищенні конверсії. Ключові рішення:
- Дворівнева черга: пріоритетні чати (VIP-клієнти) обробляються поза чергою.
- React-віджет чату з кастомною стилізацією під бренд.
- Admin UI чату на Vue 3 з фільтрацією за статусами та пошуком по історії.
// Приклад віджета (скорочено) function SupportWidget() { const [messages, setMessages] = useState<Message[]>([]); const socket = useRef(io('/support', { auth: { token } })); // ... } Технічні деталі реалізації черги
Черга побудована на Redis з використанням списків та pub/sub. При підключенні оператора підписуємося на канал operators:available. Нові сесії поміщаються до списку waiting:queue. Коли оператор готовий, він надсилає запит на accept, і сервер перекладає сесію з waiting в active атомарною операцією RPOPLPUSH. Це гарантує, що один чат не буде призначено двом операторам. Для пріоритетної черги використовуємо sorted set з оцінкою пріоритету.
Процес роботи над чатом
- Аналітика та проектування — визначаємо сценарії: первинне звернення, ескалація, закриття. Узгоджуємо інтеграції (CRM, Telegram).
- Проектування архітектури — обираємо стек (Node.js + Socket.IO + Redis + PostgreSQL), проектуємо модель даних.
- Розробка серверної логіки — реалізуємо черги, події, зберігання історії.
- Розробка клієнтської частини — віджет (React або Vue) та admin UI з дашбордом.
- Інтеграція сповіщень — Telegram, email, дзвінок (опціонально).
- Тестування — навантажувальне тестування (1000+ паралельних сесій), юніт-тести.
- Деплой та документування — розгортаємо на вашому хостингу, передаємо документацію та доступи.
Що входить в роботу
- Вихідний код серверної та клієнтської частини (репозиторій на GitHub/GitLab).
- Документація API та інструкція з деплою.
- Навчання операторів роботі з admin UI.
- Гарантія 6 місяців на виправлення помилок.
- Підтримка після запуску: 2 тижні моніторингу.
Терміни та вартість
Терміни варіюються від 2 до 6 тижнів залежно від функціональності. Вартість розраховується індивідуально після аналізу проекту. Залиште заявку — ми оцінимо ваш проект безкоштовно. Отримайте консультацію інженера для уточнення деталей.
Чому варто обрати нас
- 5 років на ринку розробки веб-сервісів.
- 30+ завершених проектів з real-time функціональністю.
- Сертифіковані спеціалісти з Node.js та React.
- Ліцензія на розробку ПЗ, договір з NDA.
Зв'яжіться з нами, щоб обговорити деталі вашого чату підтримки. Ми запропонуємо оптимальне рішення під ваш бюджет та терміни.