В экстренной ситуации голосовой звонок недоступен или затруднён для людей с нарушением слуха, речи или зрения, а диспетчерской нужно быстро получить тип опасности, место и распределить обращение нужному оператору.
Собрали мобильное приложение и веб-панель диспетчера на общем API: человек выбирает нужную службу одним действием, координаты передаются автоматически, повторные обращения закрепляются за тем же диспетчером, а важные оповещения дублируются сразу четырьмя каналами - push, SMS, email и веб-сокет.
Решение прошло весь путь от сигнала до распределения, обработки и оповещения и проверено фокус-группами людей с нарушением слуха и зрения; в постоянную эксплуатацию система пока не выведена - нужны отдельные согласования и регламент со стороны службы.
Иногда сам звонок становится препятствием
В экстренной ситуации человеку трудно спокойно объяснить, что произошло и где он находится. Для человека с нарушением слуха или речи обычный голосовой звонок может быть недоступен целиком. Слабовидящему сложно набрать номер, прочитать подсказки и продиктовать адрес.
Первоначально решение задумывалось для иностранцев, которым мешает языковой барьер. По мере работы фокус сместился к людям с особыми потребностями: для них проблема находилась не в качестве перевода, а в самом требовании позвонить и говорить с оператором.
Сценарий нужно было свести к действию, которое передаст службе три вещи: кто зовёт, какая помощь нужна и где находится человек. Со стороны диспетчерской задача зеркальная: новый сигнал должен сразу попасть к подходящему оператору, получить статус и не исчезнуть в общей очереди.
Человек выбирает службу, место добавляется автоматически
Система состоит из мобильного приложения и веб-панели диспетчера, которые работают через общий API. В приложении человек выбирает тип службы. Регион, город и координаты уходят вместе с обращением, поэтому оператор получает место без голосового объяснения адреса.
Задача сигнала не состоит в имитации длинного разговора. Приложение заранее структурирует минимум, который нужен диспетчеру для начала реакции, и отправляет его одним действием.
К профилю привязан номер телефона, но обратный звонок разрешён не всегда. В опасной ситуации звук способен выдать человека тому, кто находится рядом. Если включён режим "не звонить", диспетчер видит это ограничение и не набирает номер.
Обычный звонок при этом не усложняли. Когда пользователь сам выбирает позвонить в экстренную службу, приложение запускает стандартный набор номера по сотовой связи. Между человеком и оператором не появляется дополнительный интернет-слой, от которого зависел бы привычный сценарий.
Подписка на события тоже привязана к месту. Пользователь выбирает свой регион и не просматривает поток по всей стране, чтобы заметить событие, которое относится к его городу или области.
Медицинская карточка открывается только во время вызова
Пользователь может по желанию заранее указать хронические заболевания и другие состояния, важные для скорой помощи. Во время активного медицинского обращения оператор видит, к чему готовиться и какие особенности передать бригаде.
Так вызов скорой содержит больше, чем координаты и общий тип "нужна медицинская помощь". Карточка помогает заранее понять, с каким состоянием может столкнуться бригада и какое оснащение понадобится. Пользователь заполняет эти сведения добровольно; отсутствие карточки не мешает отправить сам сигнал.
Эта информация относится к самым чувствительным данным системы. В базе она хранится в зашифрованном виде: кража самой базы не превращает записи в читаемые медицинские карточки без ключа.
Расшифровка выполняется в момент активного вызова. В остальное время оператор не может открыть карточку из любопытства или просматривать её вне обращения. Данные становятся доступными тогда, когда нужны для помощи, и снова закрываются за пределами этого контекста.
Новое обращение сразу получает место в работе
Входящие появляются в панели через веб-сокеты, без ручного обновления страницы. Каждое обращение проходит фиксированный жизненный цикл: входящее, в работе, обработано, отменено или ошибочное. Под эти состояния в панели сделаны отдельные вкладки, поэтому диспетчер видит очередь и незавершённые случаи.
Переход между вкладками отражает реальную работу с обращением. Новая запись остаётся во входящих, принятая диспетчером переходит в работу, завершённая - в обработанные. Отменённые и ошибочные сигналы сохраняются отдельными состояниями, а не исчезают из истории без объяснения.
Свободный сигнал распределяется по двум признакам: тип службы и регион. Его получают диспетчеры, отвечающие за нужное направление на этой территории.
Сложнее ведёт себя повторное обращение. Если оператор уже работает с человеком, следующий сигнал от него закрепляется за тем же диспетчером. Без этого новая запись снова попала бы в общую очередь и могла уйти коллеге, который не видел предыдущего контекста.
Закрепление превращает набор отдельных сигналов в последовательную работу с одним человеком. Оператор понимает, что происходило раньше, и не начинает каждое новое обращение с нуля.
Важное оповещение не зависит от одного канала
События для жителей региона отправляются четырьмя путями: push на устройство, SMS, email и веб-сокет для тех, кто прямо сейчас находится онлайн. У каждого канала есть собственный способ отказа: у телефона пропал интернет, оператор задержал SMS, приложение выгружено из памяти, письмо пришло позже.
Поэтому важное сообщение дублируется, а не ждёт подтверждения от одного "идеального" транспорта. Схема с единственным каналом и подтверждением доставки выглядела бы экономнее и технически аккуратнее, но оставила бы одну точку отказа между событием и человеком.
Мобильное приложение передаёт серверу токен устройства, а push-рассылку выполняет внешний сервис. Протухшие токены удаляются автоматически, чтобы сервер не продолжал отправлять сообщения на устройства, которые больше их не принимают.
Избыточность здесь осознанна, и она же объясняет фиксированные статусы и закрепление повторного обращения за диспетчером. Цена ошибки в такой системе отличается от обычного продукта: потерянный сигнал означает не пропущенную запись в отчёте, а человека, которому могли не помочь. Этот риск определял архитектуру сильнее, чем стремление сделать её минимальной.
Набор служб хранится в конфигурации
Система стартовала с SOS, пожарной, полиции, скорой и газовой службы. Тип обращения и связь диспетчера с этим типом не зашиты навсегда в код. Когда понадобилось новое направление, его добавили в уже работающей системе без переписывания ядра.
Операционно подключение состоит из договорённости со службой и рабочего места диспетчера. После настройки новый тип появляется среди вариантов, а его обращения получают собственных ответственных.
Эта же механика допускает дальнейшее расширение на коммунальные и бытовые случаи: сантехника при прорыве трубы, электрика при пропавшем свете или эвакуатор для машины на трассе. Но важно отделить работающую основу от направления развития.
| Возможность | Состояние |
|---|---|
| Экстренные типы SOS, пожарная, полиция, скорая и газ | реализовано в ядре |
| Добавление нового типа и назначение диспетчеров | проверено в работе |
| Разный приоритет и ожидаемое время реакции по типу | направление развития |
| Коммунальные и бытовые службы | направление развития |
| Разный объём видимых данных для каждой службы | направление развития |
Коммунальные и бытовые случаи это естественное применение той же механики, а не часть текущей эксплуатации решения.
Приоритет действительно зависит от смысла обращения. Запах газа требует немедленной реакции, а застрявшая на трассе машина допускает помощь в течение нескольких часов. Тип определяет не только исполнителя, но и ожидаемую срочность.
С расширением списка служб становится важнее минимизация данных. Эвакуатору достаточно места автомобиля; медицинская карточка и домашний адрес ему не нужны. Для скорой медицинские сведения, наоборот, могут быть критичны. В экстренном ядре уже реализованы шифрование и показ карточки только во время вызова. Отдельные права видимости для каждого будущего типа службы остаются направлением развития, а не готовой функцией для всех перечисленных сценариев.
Интерфейс проверяли люди, которым звонок недоступен
Приложение тестировали не только разработчики. С ним работали фокус-группы людей с нарушениями слуха и зрения. Они проверяли, понятно ли действие, как выглядит подтверждение сигнала и очевидно ли, что обращение принято.
Замечания возвращались в интерфейс и меняли его до демонстрации. Собранную систему также показывали профильной государственной службе экстренного реагирования на демонстрационных прогонах.
Так проверялась не абстрактная доступность по списку требований, а конкретный путь человека: выбрать службу, отправить место и понять результат без обязательного голосового разговора.
Собранная система ещё не стала постоянно работающей службой
Решение закрывает путь "сигнал - распределение - обработка - оповещение". Оно не заменяет полицию, скорую, пожарную или регламент их работы. Точность места ограничена координатами устройства. Распределение по региону и типу службы работает по заданному правилу, а не прогнозирует текущую нагрузку диспетчеров; при росте команды балансировку потребуется развивать.
API, диспетчерская панель и каналы доставки разделены, поэтому мобильный сценарий, правила распределения, рабочее место диспетчера и способы доставки уведомлений можно развивать независимо друг от друга.
Решение собрано, работало целиком и проверено фокус-группами, но в постоянную эксплуатацию не выведено. Для запуска нужны отдельные согласования, регламенты и финансирование.
Согласования определяют, кто принимает сигнал, по какому регламенту отвечает, как финансируется рабочее место и кто несёт ответственность за эксплуатацию. Государственный цикл здесь может занять больше времени, чем сама разработка, и программный код эту границу не снимает. Под конкретную службу или регион систему можно адаптировать, но публично доступным действующим каналом экстренной помощи она сейчас не является.
Александр
Это реальный проект, поданный обезличенно. Узнаваемые детали - отрасль, конкретику, всё, по чему можно вычислить заказчика, - мы намеренно меняем; имя и коммерческие тайны заказчика не раскрываем. Неизменной остаётся суть: какую задачу решали и каким инженерным подходом. Кейс написан, чтобы показать проблему и её решение - что и как мы делаем.