Проблема електронної черги та її вирішення
Зазначимо: коли в ЦНАПі або іншій установі з великим потоком клієнтів традиційна черга — це стрес. Люди беруть талон, виходять на вулицю й пропускають виклик. Повернувшись, вони виявляють, що їхній номер вже анульовано, і доводиться чекати на повторну видачу. Оператори витрачають час на повторне призначення, а загальна пропускна здатність падає.
Мобільний застосунок для електронної черги вирішує цю проблему: талони синхронізуються в реальному часі через WebSocket, а персоналізовані push-повідомлення попереджають за 3, 2 і 1 позицію до виклику.
За даними наших проєктів, час простою скорочується на 40%, а витрати на персонал знижуються до 20% завдяки автоматизації. Розробка мобільного застосунку для електронної черги — це інвестиція, яка окупається завдяки скороченню витрат і підвищенню лояльності клієнтів.
Логіка роботи мобільного застосунку для електронної черги
Черга — це не просто список. Стан змінюється кожні 2–5 хвилин, і клієнт має бачити актуальну позицію без ручного оновлення. Ми використовуємо WebSocket для миттєвої синхронізації — затримка не перевищує 100 мс. Така архітектура витримує навантаження до 5000 одночасних підключень.
Два підходи до синхронізації:
- WebSocket (переважно): з’єднання відкрите, поки застосунок активний. Коли викликають наступний номер, сервер розсилає подію всім підключеним клієнтам. На Flutter —
web_socket_channel, стан уRiverpod StreamProviderабоBLoC. Затримка — не більше 100 мс, що у 3 рази швидше за SSE. - SSE (Server-Sent Events): простіше реалізувати на бекенді, односторонній канал. Затримка ~300 мс.
Зазначимо: коли застосунок переходить у фоновий режим, WebSocket закривається. Тоді вмикаються push-повідомлення:
- «Перед вами залишилося 3 людини» — попередження.
- «Ваш номер наступний!» — час підходити.
- «Вас викликають до вікна №5» — негайне повідомлення.
Логіка сервера: під час кожного виклику розраховується позиція кожного, хто очікує, і надсилаються персоналізовані повідомлення тим, хто має 3, 2 або 1 позицію до виклику.
Докладніше про налаштування push-повідомлень
Для iOS використовується APNs, для Android — FCM. Потрібне коректне налаштування сертифікатів в App Store Connect і ключів у Firebase Console. Push-повідомлення проходять через App Store Review Guidelines Section 5.1. Для додаткового захисту застосовується code signing і provisioning profile.
Як працює попередній запис?
Розширений сценарій: користувач не просто бере талон, а записується на конкретний час. За 30 хвилин до слота надходить push-нагадування, за 10 хвилин — «виходьте зараз». Реалізація через Bull Queue на Redis: під час створення запису задачі ставляться в чергу з delayed timing. Це знижує кількість неявок на 35%.
Чому варто обрати Flutter для електронної черги?
Flutter дає змогу покрити iOS і Android одним кодом, що скорочує вартість розробки в 1.5 раза порівняно з нативними застосунками. Збірка через fastlane і доставка оновлень через Code Push (Shorebird) дають можливість виправляти баги без схвалення App Store. Анімації та UI працюють на 60 FPS навіть на старих пристроях.
Процес роботи: від ідеї до деплою
- Аналітика: вивчаємо навантаження, кількість вікон, типи послуг, сценарії користувача.
- Проєктування: архітектура черги (черга в пам'яті Redis), схеми API, макети.
- Реалізація: бекенд на Node.js + PostgreSQL, мобільний застосунок на Flutter, налаштування push (FCM/APNs).
- Тестування: навантажувальне тестування (до 1000 одночасних користувачів), юзабіліті.
- Деплой: налаштування CI/CD, завантаження в магазини застосунків, підключення моніторингу (Crashlytics).
Зв'яжіться з нами, щоб обговорити ваш проєкт і отримати попередню оцінку.
Що входить у розробку мобільного застосунку?
- Розробка мобільного застосунку (iOS + Android) і бекенд-сервісу
- Інтеграція з наявними системами (наприклад, АСУ МФЦ)
- Налаштування push-повідомлень (FCM + APNs)
- Генерація та сканування QR-кодів талонів
- Аналітичний дашборд для адміністратора (кількість відвідувачів, середній час, піки навантаження)
- Документація API та архітектури
- Навчання персоналу роботі з адмін-панеллю
- Підтримка протягом 3 місяців після запуску
Стек: бекенд — Node.js + PostgreSQL + Redis + Bull Queue; мобільна частина — Flutter (або React Native).
| Масштаб | Терміни |
|---|---|
| MVP: талон, позиція, push | 4–6 тижнів |
| + Попередній запис, кабінет оператора | 8–10 тижнів |
| + Аналітика, мультиофіс, інтеграція | 14–16 тижнів |
| Підхід | Швидкість | Складність | Затримка |
|---|---|---|---|
| WebSocket | Висока | Середня | 50–100 мс |
| SSE | Середня | Низька | 200–300 мс |
| Polling | Низька | Дуже низька | 5–10 с |
Досвід і гарантії
Ми — команда з досвідом розробки мобільних застосунків для систем управління чергами та державного сектору. Реалізували понад 20 проєктів, зокрема рішення для ЦНАП та медичних центрів.
Гарантуємо стабільну роботу під навантаженням до 10 000 одночасних користувачів і відповідність вимогам безпеки (шифрування даних, App Store Review Guidelines).
Замовте розробку мобільного застосунку для електронної черги — ми оцінимо ваш проєкт і запропонуємо архітектуру. Отримайте консультацію для розрахунку термінів і вартості.
