В екстреній ситуації голосовий дзвінок недоступний або утруднений для людей із порушенням слуху, мовлення чи зору, а диспетчерській потрібно швидко отримати тип небезпеки, місце і розподілити звернення потрібному оператору.
Зібрали мобільний застосунок і вебпанель диспетчера на спільному API: людина обирає потрібну службу однією дією, координати передаються автоматично, повторні звернення закріплюються за тим самим диспетчером, а важливі сповіщення дублюються одразу чотирма каналами - push, SMS, email і веб-сокет.
Рішення пройшло весь шлях від сигналу до розподілу, обробки й сповіщення і перевірене фокус-групами людей із порушенням слуху та зору; у постійну експлуатацію систему поки не виведено - потрібні окремі погодження й регламент з боку служби.
Іноді сам дзвінок стає перешкодою
В екстреній ситуації людині важко спокійно пояснити, що сталося і де вона перебуває. Для людини з порушенням слуху чи мовлення звичайний голосовий дзвінок може бути недоступний цілком. Людині зі слабким зором складно набрати номер, прочитати підказки й продиктувати адресу.
Спершу рішення задумувалося для іноземців, яким заважає мовний бар'єр. З часом фокус змістився до людей з особливими потребами: для них проблема була не в якості перекладу, а в самій вимозі зателефонувати й говорити з оператором.
Сценарій треба було звести до дії, яка передасть службі три речі: хто кличе, яка допомога потрібна і де перебуває людина. З боку диспетчерської завдання дзеркальне: новий сигнал має одразу потрапити до відповідного оператора, отримати статус і не зникнути в загальній черзі.
Людина обирає службу, місце додається автоматично
Система складається з мобільного застосунку та вебпанелі диспетчера, які працюють через спільний API. У застосунку людина обирає тип служби. Регіон, місто та координати йдуть разом зі зверненням, тому оператор отримує місце без голосового пояснення адреси.
Завдання сигналу не полягає в імітації довгої розмови. Застосунок заздалегідь структурує мінімум, який потрібен диспетчеру для початку реакції, і надсилає його однією дією.
До профілю прив'язаний номер телефону, але зворотний дзвінок дозволений не завжди. У небезпечній ситуації звук здатний виказати людину тому, хто перебуває поруч. Якщо ввімкнено режим "не телефонувати", диспетчер бачить це обмеження й не набирає номер.
Звичайний дзвінок при цьому не ускладнювали. Коли користувач сам обирає зателефонувати до екстреної служби, застосунок запускає стандартний набір номера мобільним зв'язком. Між людиною й оператором не з'являється додатковий інтернет-шар, від якого залежав би звичний сценарій.
Підписка на події теж прив'язана до місця. Користувач обирає свій регіон і не переглядає потік по всій країні, щоб помітити подію, яка стосується його міста чи області.
Медична картка відкривається лише під час виклику
Користувач може за бажанням заздалегідь вказати хронічні захворювання та інші стани, важливі для швидкої допомоги. Під час активного медичного звернення оператор бачить, до чого готуватися і які особливості передати бригаді.
Так виклик швидкої містить більше, ніж координати та загальний тип "потрібна медична допомога". Картка допомагає заздалегідь зрозуміти, з яким станом може зіткнутися бригада і яке оснащення знадобиться. Користувач заповнює ці відомості добровільно; відсутність картки не заважає надіслати сам сигнал.
Ця інформація належить до найчутливіших даних системи. У базі вона зберігається в зашифрованому вигляді: крадіжка самої бази не перетворює записи на придатні для читання медичні картки без ключа.
Розшифрування виконується в момент активного виклику. У решту часу оператор не може відкрити картку з цікавості чи переглядати її поза зверненням. Дані стають доступними тоді, коли потрібні для допомоги, і знову закриваються за межами цього контексту.
Нове звернення одразу отримує місце в роботі
Вхідні з'являються в панелі через вебсокети, без ручного оновлення сторінки. Кожне звернення проходить фіксований життєвий цикл: вхідне, в роботі, оброблено, скасовано або помилкове. Під ці стани в панелі зроблені окремі вкладки, тому диспетчер бачить чергу та незавершені випадки.
Перехід між вкладками відображає реальну роботу зі зверненням. Новий запис залишається у вхідних, прийнятий диспетчером переходить у роботу, завершений - в оброблені. Скасовані та помилкові сигнали зберігаються окремими станами, а не зникають з історії без пояснення.
Вільний сигнал розподіляється за двома ознаками: тип служби та регіон. Його отримують диспетчери, які відповідають за потрібний напрям на цій території.
Складніше поводиться повторне звернення. Якщо оператор уже працює з людиною, наступний сигнал від неї закріплюється за тим самим диспетчером. Без цього новий запис знову потрапив би в загальну чергу і міг би піти колезі, який не бачив попереднього контексту.
Закріплення перетворює набір окремих сигналів на послідовну роботу з однією людиною. Оператор розуміє, що відбувалося раніше, і не починає кожне нове звернення з нуля.
Важливе сповіщення не залежить від одного каналу
Події для мешканців регіону надсилаються чотирма шляхами: push на пристрій, SMS, email та вебсокет для тих, хто просто зараз перебуває онлайн. У кожного каналу є власний спосіб відмови: у телефона зник інтернет, оператор затримав SMS, застосунок вивантажено з пам'яті, лист прийшов пізніше.
Тому важливе повідомлення дублюється, а не чекає на підтвердження від одного "ідеального" транспорту. Схема з єдиним каналом і підтвердженням доставки виглядала б економніше й технічно охайніше, але залишила б одну точку відмови між подією та людиною.
Мобільний застосунок передає серверу токен пристрою, а push-розсилку виконує зовнішній сервіс. Застарілі токени видаляються автоматично, щоб сервер не продовжував надсилати повідомлення на пристрої, які більше їх не приймають.
Надлишковість тут усвідомлена, і вона ж пояснює фіксовані статуси та закріплення повторного звернення за диспетчером. Ціна помилки в такій системі відрізняється від звичайного продукту: втрачений сигнал означає не пропущений запис у звіті, а людину, якій могли не допомогти. Цей ризик визначав архітектуру сильніше, ніж прагнення зробити її мінімальною.
Набір служб зберігається в конфігурації
Система стартувала з SOS, пожежної, поліції, швидкої та газової служби. Тип звернення та зв'язок диспетчера з цим типом не зашиті назавжди в код. Коли знадобився новий напрям, його додали у вже чинній системі без переписування ядра.
Операційно підключення складається з домовленості зі службою та робочого місця диспетчера. Після налаштування новий тип з'являється серед варіантів, а його звернення отримують власних відповідальних.
Ця ж механіка допускає подальше розширення на комунальні та побутові випадки: сантехніка при прориві труби, електрика при зниклому світлі або евакуатор для машини на трасі. Але важливо відділити робочу основу від напряму розвитку.
| Можливість | Стан |
|---|---|
| Екстрені типи SOS, пожежна, поліція, швидка та газ | реалізовано в ядрі |
| Додавання нового типу та призначення диспетчерів | перевірено в роботі |
| Різний пріоритет та очікуваний час реакції за типом | напрям розвитку |
| Комунальні та побутові служби | напрям розвитку |
| Різний обсяг видимих даних для кожної служби | напрям розвитку |
Комунальні та побутові випадки це природне застосування тієї самої механіки, а не частина поточної експлуатації рішення.
Пріоритет справді залежить від змісту звернення. Запах газу вимагає негайної реакції, а застрягла на трасі машина допускає допомогу протягом кількох годин. Тип визначає не лише виконавця, але й очікувану терміновість.
З розширенням списку служб стає важливішою мінімізація даних. Евакуатору достатньо місця автомобіля; медична картка та домашня адреса йому не потрібні. Для швидкої медичні відомості, навпаки, можуть бути критичними. В екстреному ядрі вже реалізовані шифрування та показ картки лише під час виклику. Окремі права видимості для кожного майбутнього типу служби залишаються напрямом розвитку, а не готовою функцією для всіх перелічених сценаріїв.
Інтерфейс перевіряли люди, яким дзвінок недоступний
Застосунок тестували не лише розробники. З ним працювали фокус-групи людей з порушеннями слуху та зору. Вони перевіряли, чи зрозуміла дія, як виглядає підтвердження сигналу і чи очевидно, що звернення прийнято.
Зауваження поверталися в інтерфейс і змінювали його до демонстрації. Зібрану систему також показували профільній державній службі екстреного реагування на демонстраційних прогонах.
Так перевірялася не абстрактна доступність за списком вимог, а конкретний шлях людини: обрати службу, надіслати місце й зрозуміти результат без обов'язкової голосової розмови.
Зібрана система ще не стала службою, що постійно працює
Рішення закриває шлях "сигнал - розподіл - обробка - сповіщення". Воно не замінює поліцію, швидку, пожежну чи регламент їхньої роботи. Точність місця обмежена координатами пристрою. Розподіл за регіоном і типом служби працює за заданим правилом, а не прогнозує поточне навантаження диспетчерів; при зростанні команди балансування потрібно буде розвивати.
API, диспетчерська панель та канали доставки розділені, тому мобільний сценарій, правила розподілу, робоче місце диспетчера та способи доставки сповіщень можна розвивати незалежно один від одного.
Рішення зібране, працювало цілком і перевірене фокус-групами, але в постійну експлуатацію не виведене. Для запуску потрібні окремі погодження, регламенти та фінансування.
Погодження визначають, хто приймає сигнал, за яким регламентом відповідає, як фінансується робоче місце і хто несе відповідальність за експлуатацію. Державний цикл тут може зайняти більше часу, ніж сама розробка, і програмний код цю межу не знімає. Під конкретну службу чи регіон систему можна адаптувати, але публічно доступним чинним каналом екстреної допомоги вона зараз не є.
Олександр
Це реальний проєкт, поданий знеособлено. Впізнавані деталі - галузь, конкретику, усе, за чим можна визначити замовника, - ми навмисно змінюємо; ім'я та комерційні таємниці замовника не розкриваємо. Незмінною лишається суть: яке завдання розв'язували і яким інженерним підходом. Кейс написано, щоб показати проблему та її вирішення - що і як ми робимо.