BORNLI / о разработке по делу
Приложение для страховой компании
Покажите клиенту, что уже принято системой, какой документ нужно заменить и кто отвечает за следующий шаг. Статус загрузки не должен обещать страховую выплату.
Какую часть процесса переносить в приложение?
Приложение для страховой компании можно начать с одного пути: клиент собирает документы, передаёт пакет и получает конкретный запрос на уточнение. Решение о страховом случае остаётся в действующем процессе страховщика. Если личный кабинет уже закрывает этот путь, сначала стоит проверить его настройку и мобильную доступность.
Росгосстрах описывает личный кабинет для управления полисами и цифрового урегулирования, доступный с мобильных устройств. Это пример продукта названного страховщика, не проект BORNLI и не готовые требования к вашей системе.
Что означает «документы сохранены»?
Модельный сценарий BORNLI. Условное обращение C-418 содержит описание события и три файла. Два файла загружены, третий ещё хранится на устройстве. Экран сообщает «2 из 3 приняты сервером», а не «Заявление принято». Имена, номера и документы вымышлены; концепт не подключён к страховщику.
Для каждого файла нужны отдельные состояния: выбран, загружается, принят, требует замены. Повтор после разрыва связи должен продолжать ту же операцию. Если приложение закрыли, несохранённые файлы нельзя показывать принятыми.

Как подтвердить передачу пакета?
В модели сервер подтвердил три файла и выдал квитанцию R-418. Пакет отправлен на проверку комплектности; выплата не согласована. Пользователь видит дату получения и состав версии, а не только зелёную галочку.
Юридический смысл обращения, способ подписания, идентификация, хранение и сроки определяются видом страхования и утверждённым процессом заказчика. До разработки их проверяют с ответственными специалистами. Эта схема описывает интерфейс, не правовой порядок урегулирования.

Как заменить один документ, не собрать всё заново?
Сотрудник обнаружил нечитаемую страницу в document-03 и запросил замену. Первые два файла остаются принятыми. Клиент загружает document-03 версии 2 в C-418; исходная версия сохраняется в истории с причиной замены. Новое обращение не создаётся.
Техническая ошибка загрузки и содержательный запрос страховщика должны выглядеть по-разному. В первом случае клиент может повторить отправку; во втором ему нужен точный ответ, какой фрагмент заменить и почему.

Как проверить первую версию?
Возьмите один вид обращения и один канал приёма. Проверьте прерывание третьей загрузки, повтор отправки, замену файла, истечение сессии и доступ другого клиента к C-418. Квитанция появляется только после подтверждения всех требуемых файлов и проверки целостности пакета на сервере.
На пилоте измеряйте незавершённые пакеты, повторные обращения и число запросов из-за качества документов. Эффект этой концепции не измерялся. Для оценки нужны обезличенный список документов, роли и описание действующей системы; состав и цена разработки согласуются после разбора интеграции.
От идеи к конкретике
Покажем, как может работать ваш продукт.
Обсудим задачу и материалы, затем подготовим бесплатный кликабельный прототип за 24 часа. До договора.
Обсудить прототип ↗