BORNLI
BORNLI / Материалы / Приложение для страховой компании: документы и статусы

BORNLI / о разработке по делу

Приложение для страховой компании

Покажите клиенту, что уже принято системой, какой документ нужно заменить и кто отвечает за следующий шаг. Статус загрузки не должен обещать страховую выплату.

Редакция BORNLI ·

Какую часть процесса переносить в приложение?

Приложение для страховой компании можно начать с одного пути: клиент собирает документы, передаёт пакет и получает конкретный запрос на уточнение. Решение о страховом случае остаётся в действующем процессе страховщика. Если личный кабинет уже закрывает этот путь, сначала стоит проверить его настройку и мобильную доступность.

Росгосстрах описывает личный кабинет для управления полисами и цифрового урегулирования, доступный с мобильных устройств. Это пример продукта названного страховщика, не проект BORNLI и не готовые требования к вашей системе.

Что означает «документы сохранены»?

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

Для каждого файла нужны отдельные состояния: выбран, загружается, принят, требует замены. Повтор после разрыва связи должен продолжать ту же операцию. Если приложение закрыли, несохранённые файлы нельзя показывать принятыми.

Третий файл ещё не отправлен — Отправка не завершена
Концепция BORNLI, модельный сценарий. Третий файл сохранён на устройстве. Квитанции о получении полного пакета пока нет.

Как подтвердить передачу пакета?

В модели сервер подтвердил три файла и выдал квитанцию R-418. Пакет отправлен на проверку комплектности; выплата не согласована. Пользователь видит дату получения и состав версии, а не только зелёную галочку.

Юридический смысл обращения, способ подписания, идентификация, хранение и сроки определяются видом страхования и утверждённым процессом заказчика. До разработки их проверяют с ответственными специалистами. Эта схема описывает интерфейс, не правовой порядок урегулирования.

Пакет получен системой — Проверка комплектности
Концепция BORNLI, модельный сценарий. Сервер подтвердил три файла. Получение документов не означает согласование выплаты.

Как заменить один документ, не собрать всё заново?

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

Техническая ошибка загрузки и содержательный запрос страховщика должны выглядеть по-разному. В первом случае клиент может повторить отправку; во втором ему нужен точный ответ, какой фрагмент заменить и почему.

Замените нечитаемую страницу — Нужен новый файл
Концепция BORNLI, модельный сценарий. Первые два файла остаются принятыми. Новая версия добавляется в то же обращение.

Как проверить первую версию?

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

На пилоте измеряйте незавершённые пакеты, повторные обращения и число запросов из-за качества документов. Эффект этой концепции не измерялся. Для оценки нужны обезличенный список документов, роли и описание действующей системы; состав и цена разработки согласуются после разбора интеграции.

От идеи к конкретике

Покажем, как может работать ваш продукт.

Обсудим задачу и материалы, затем подготовим бесплатный кликабельный прототип за 24 часа. До договора.

Обсудить прототип ↗