Разработка мобильного приложения для нотариуса

Почему мобильное приложение нотариуса буксует на реальных задачах

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

Дальше теряются подтверждения. Клиент согласовал время в мессенджере, но не получил напоминание и не уточнил комплект документов — приехал без согласия второго участника сделки. Администратор ищет, кто и что обещал, и визит переносится целиком.

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

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

Что даёт конторе: время приёма, реестр, меньше отказов

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

• [ ] Расписание приёма в одном окне. Запись идёт по свободным окнам, напоминания клиентам уходят автоматически за сутки и за пару часов до визита — подтверждать каждую встречу звонком больше не нужно. Доля сорванных приёмов падает с каждой пятой-шестой записи до единичных случаев, освобождаются 4–6 часов в неделю.
• [ ] Статусы обращений вместо блокнота. У каждого обращения видно этап: чего ждём от клиента, какие документы готовы, что подписано. Сотрудник не собирает статусы обзвоном, а клиент сам видит, на каком шаге его дело.
• [ ] Электронный реестр нотариальных действий. Запись создаётся из карточки обращения, повторный ввод в журнал исключён, расхождения между реестром и выданными документами не накапливаются. Поиск по номеру, дате или клиенту занимает секунды вместо перелистывания.
• [ ] Меньше ручных операций. Напоминания, сверка записей и подготовка выгрузок уходят в приложение: объём ручной работы сокращается примерно втрое, а ошибки ввода — почти полностью.

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

Форматы приложения: типовая сборка или отдельная под задачи

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

Чем варианты различаются

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

Сроки запуска отличаются кратно: типовая сборка выходит в работу за недели, настройка под контору — за месяц-два с переносом шаблонов, отдельная разработка — от квартала, потому что включает проектирование, обе платформы и проверки на реальных документах.

Как мы внедряем: от обследования до передачи конторе

Проект начинается не с кода, а с описания того, как контора работает сегодня: кто принимает клиента, где ведётся реестр, что готовится вручную. Фиксируем узкие места и договариваемся, какой результат считаем достигнутым — иначе автоматизация упирается в переписывание логики на середине.

1. Обследование процессов. Разбираем приём по шагам: обращение, подготовка документов, расчёты, запись в реестр. Отмечаем, где сотрудник дублирует ввод и где данные расходятся между журналом и учётной системой.
2. Схема данных. Описываем сущности — клиент, обращение, документ, платёж, — их связи и обязательные поля. Схема согласуется до разработки: она определяет и экраны приложения, и формат обмена.
3. Границы первой версии. Выбираем сценарии, которые дают эффект сразу, остальное уводим во второй этап. Так контора получает рабочий инструмент раньше, чем закрыт весь список пожеланий.
4. Настройка обмена с учётной системой. Делаем двустороннюю передачу, помечаем операции уникальными ключами, чтобы повторная отправка не создавала дублей. Отдельно описываем поведение при недоступности системы: что приложение сохраняет и когда досылает.
5. Приёмочная проверка. Прогоняем сценарии на копии реальных данных: параллельный приём, обрыв связи, расхождение версий документа. Каждый шаг подтверждает сотрудник конторы, а не только проверка на стенде.
6. Передача и обучение. Отдаём доступы и настройки, регламенты на типовые ситуации, проводим обучение и остаёмся на связи в первые приёмы — чтобы переход не лёг на плечи одного человека.

Передача конторе: доступы, схемы данных, регламенты приёма

Передача конторе — не финальная встреча, а пакет настроек и документов, по которому нотариус и его помощник работают без нас. Систему отдаём в состоянии, когда её можно эксплуатировать, обновлять и передать другому подрядчику без разбора кода.

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

Это живые документы, а не папка на полке: при изменениях схему и инструкции обновляем вместе с релизом, чтобы описание не расходилось с тем, как система работает.

Кейс: как нотариальная контора ушла от бумажного журнала

Контора принимает по записи, но весь контур держался на бумажном журнале и телефоне. Секретарь согласовывала время голосом и правила ручкой, о переносе узнавали не все — в неделю срывалось три-четыре приёма, а клиент с неполным пакетом документов уходил ни с чем.

Дороже всего обходилась подготовка: нотариус тратил на сверку бумаг 10-15 минут прямо на приёме, записи в реестре искали по датам и почерку, отчётность собирали вручную.

Что было

• Один журнал на ресепшене: двойные записи на слот, правки карандашом.
• Подтверждение и напоминание — только звонком в рабочие часы.

Что изменили

Расписание, статусы и реестр свели в одно приложение. Слот формируется под тип действия, клиент сам выбирает время и получает подтверждение с напоминанием; заявка идёт по статусам «принята — документы проверены — готово к подписанию — завершена». Реестр работает офлайн и синхронизируется при появлении связи, доступ разграничен по ролям — нотариус, помощник, секретарь.

Что стало

• Сорванные приёмы: с 3-4 в неделю до нуля за месяц наблюдений.
• Подготовка документов: с 15 до 4-5 минут за счёт заготовок и предзаполненных полей.
• Поиск по реестру — по фамилии и дате вместо листания журнала, выгрузка для отчётности в один клик.

Отзыв заказчика: «Раньше половина звонков была про запись и переносы. Теперь расписание держит приложение, а мы занимаемся делами».

Можно ли вести приём офлайн и синхронизировать данные позже?

Да, приём офлайн реализуем — и это не урезанный режим, а полноценная работа. Карточки клиентов, реестр действий, шаблоны документов и черновики лежат в локальном хранилище на устройстве, и приложение читает и пишет именно туда. Сервер в этой схеме на время приёма не источник истины, а точка обмена: пока связи нет, он в работе не участвует.

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

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

Что нельзя делать без связи — всё, что зависит от внешних систем: проверки по сторонним реестрам, действия, требующие подтверждения извне. Такие пункты блокируются сразу с понятным объяснением, чтобы операция не ушла в базу и не была отклонена позже.

Локальное хранилище шифруется, срок хранения и очистка после подтверждённой синхронизации задаются политикой. Так помещение с глухими стенами перестаёт быть слепой зоной, а приём идёт без пауз на «поиск сети».

Частые вопросы до старта: доступы, данные, поддержка

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

Что видит помощник нотариуса в приложении?

Роли разводятся заранее: помощник работает со своими приёмами и черновиками, реестр и настройки доступны только нотариусу. Каждое действие попадает в журнал с пользователем и временем — спорную правку всегда видно.

Можно ли перенести записи из текущей системы?

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

Что будет при нестабильной связи в помещении?

Приём и черновик сохраняются на устройстве, отправка идёт фоном при появлении сети. Конфликты версий разбираются по времени правки, поэтому ни один приём не теряется в дальней комнате или подвале.

Кто поддерживает приложение после запуска?

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

Обсудим задачу: пришлём оценку и план работ

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

• Какие нотариальные действия должны идти через приложение: удостоверение сделок и доверенностей, копии, выдача документов, ведение реестра.
• Как реестр нотариальных действий ведётся сейчас — выгрузка из учётной системы, обмен данными или ручной перенос.
• Требования к квалифицированной электронной подписи и защищённым каналам: где хранятся ключи, какие проверки обязательны.
• Нужен ли режим без сети: какие действия выполняются офлайн и как синхронизируются при появлении связи.
• Парк устройств и платформы, а также жёсткие даты — отчётный период, вступление в силу требований к документообороту.
• Доступы к тестовым контурам и контакт со стороны заказчика: кто согласует состав работ и принимает этапы.
• Ожидаемая поддержка после запуска: обновления под новые версии платформ, разбор отказов, доработки по регламенту.

Даже если часть пунктов пока не определена — так и напишите, это тоже вводная. Обсудим задачу и вернёмся с оценкой, разбивкой на этапы со сроками каждого и планом поддержки после запуска: что войдёт в первый релиз, что переносим дальше и где видим риски.