Концепт «Нить»: сообщение не теряется между экранами

Клиент понимает, где сейчас его сообщение. Поддержка работает с обращением, а повтор отправки не засоряет историю.

Концепт-проект: «Нить» — вымышленная компания. Результатов работы здесь нет: только решения и гипотезы.

О заказчике

• Задача: Поддержка в мобильном приложении
• Модель: Обращение и сообщения
• Ключевой риск: Неопределённый итог отправки
• Граница: Состояние только в памяти вкладки

Задача

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

Концепт описывает диалог клиента и сотрудника. Название и участники вымышлены; рабочий WebSocket, CRM, push и хранение переписки не подключены. Показанные экраны не являются скриншотами продукта клиента.

Риски исходного процесса

Пузырь появился, подтверждения нет

Локальное ожидание и принятие показаны раздельно. Наличие реплики не названо прочтением.

После повтора две одинаковые записи

Техническая попытка использует исходный идентификатор; намеренная новая отправка создаёт другой.

Чужая история после смены пользователя

Для рабочего продукта предусмотрены отдельные проверки доступа и очистки локальных данных.

Решение

Отделены локальная команда и подтверждённая серверная запись. На экране есть понятные состояния: ожидает сети и принято. Прочтение оператором не имитируется по появлению сообщения в истории.

Локальный демонстратор сохраняет введённую реплику в памяти вкладки при отключённой учебной сети. Возврат связи переводит ту же запись в состояние принятия. Повтор обработки использует существующий идентификатор и не добавляет копию. Перезагрузка сбрасывает данные; это явно обозначенная граница демонстрации.

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

Как устроен продукт

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

Что помогает пройти сценарий

Учебная сеть

Переключатель меняет только локальную модель отправки. Устройство не отключается от интернета.

Одна запись

Возврат связи обновляет исходное сообщение, а повтор принятия не добавляет другое.

Граница хранения

Демо работает в памяти вкладки и не обещает сохранение после её перезагрузки.

Ключевые сценарии

Отправить без связи

Текст остаётся в локальной модели.

На входе: Учебная сеть отключена, введён вопрос.

1. Нажать отправку.
2. Прочитать статус ожидания.
3. Проверить сохранённый текст.

На выходе: Одна ожидающая реплика.

Если что-то пошло не так: Перезагрузка вкладки сбрасывает демонстрацию.

Критерий приёмки: Нет ложного обещания доставки серверу.

Восстановить передачу

Связь возвращается после ожидания.

На входе: Есть одна локальная команда.

1. Включить учебную сеть.
2. Обработать исходную запись.
3. Проверить идентификатор.

На выходе: Та же реплика помечена принятой.

Если что-то пошло не так: Это имитация подтверждения, не реальный сетевой запрос.

Критерий приёмки: Не появилась новая копия сообщения.

Повторить подтверждение

Проверка защиты от дубля.

На входе: Демонстрационная команда уже принята.

1. Повторить её обработку.
2. Проверить историю.
3. Отправить новый текст как отдельное намерение.

На выходе: Повтор не добавляет запись; новая отправка добавляет.

Если что-то пошло не так: Одинаковый текст сам по себе не считается дублем.

Критерий приёмки: Число записей соответствует числу пользовательских команд.

Роли пользователей

Клиент

Передать вопрос и понять статус отправки.

Сообщение ещё на телефоне или уже принято?

Оператор

Разобрать назначенное обращение с контекстом.

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

Команда продукта

Согласовать хранение, доступ и восстановление.

Как приложение восполнит события после разрыва связи?

Как устроено технически

История и транспорт

Для рабочего продукта транспорт событий дополняется хранилищем и восстановлением по устойчивому указателю.

Доступ к диалогу

Сервер проверяет участника при чтении, подписке, отправке и выдаче вложений; активная сессия не даёт глобальный доступ.

Поддержка и CRM

Состояния сообщения, обращения и обмена с CRM разделяются. Нужен порядок разбора частичных отказов.

Что входит в разработку

• Локальная отправка текста
• Переключение учебной сети
• Обновление состояния одной записи
• Повтор принятия без дубля
• Сценарии доступа и восстановления

План реализации

1. Разобрать типовые вопросы, роли и допустимый контекст заказа.
2. Согласовать статусы сообщения и жизненный цикл обращения.
3. Проверить мобильный ввод, ожидание и восстановление.
4. Реализовать сервер, историю, права и необходимые каналы.
5. Провести многопользовательскую приёмку и передать эксплуатацию.

Что замеряем после запуска

• Зависшие отправки — Отличает ошибки передачи от времени работы оператора.
• Время до назначения — Показывает начало обработки вопроса, отдельно от автоматического приветствия.
• Повторные обращения — Изучается вместе с причиной закрытия; у концепта нет измеренных показателей клиента.

Стек

История и транспорт, Доступ к диалогу, Поддержка и CRM.

Все кейсы · Услуга · Калькулятор стоимости