Клиент меняет согласованную заявку: что должен увидеть сотрудник

Подготовлено 23 октября 2026 года

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

Привяжите решение к версии данных

В учебной заявке З-65 услуга согласована на условное время Т1. Клиент предлагает Т2. Прежнее подтверждение относится к Т1 и остальным данным принятой версии В-1. Оно не доказывает доступность сотрудника и возможность исполнения в Т2.

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

Разделите черновик правки и действующую заявку

Пока предложение Т2 рассматривается, участники должны различать принятую В-1 и правку П-1. Для учебного примера выбираем правило: до нового решения действующей остаётся В-1. Это решение владельца процесса, которое нужно явно согласовать для своей услуги.

Определите значимые поля

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

Для каждого поля полезно указать влияние, нужную роль и ожидаемое действие. Если изменение затрагивает несколько условий, сотруднику нужно видеть их вместе, а не получать серию несвязанных уведомлений. Неизвестное влияние — вопрос владельцу процесса до автоматизации.

Сообщите сотруднику конкретное отличие

Учебное сообщение: «Клиент предлагает изменить время З-65: было Т1, предлагается Т2. Действует В-1; требуется решение по П-1». Оно объясняет предмет и следующий шаг. Одного текста «Заявка изменена» недостаточно для осознанного подтверждения.

На экране решения покажите прежнее и новое значения, версию основания, инициатора и доступные действия. Если с момента открытия появилась следующая правка П-2, подтверждение П-1 не должно незаметно принять её тоже. Этот случай включают в требования к реализации.

Опишите отказ от правки

При отказе в учебной схеме В-1 продолжает действовать, П-1 получает отдельный результат и объяснение. Клиент видит, что новое время не принято. Нельзя удалять П-1 так, будто обращения не было, или показывать Т2 как согласованное после отрицательного решения.

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

Приёмка одного сценария изменения

Проверьте принятие П-1 с появлением В-2 и отказ с сохранением В-1. Затем добавьте следующую правку до решения и попытку подтвердить устаревший экран. В каждом результате должно быть видно, какая версия действует и к чему относится решение.

Заявка / принятая версия / её условия:
Инициатор и черновик правки:
Поле — прежнее значение — предлагаемое значение:
Значимость изменения / нужная роль:
Что действует до решения:
Принятие — новая версия и подтверждение:
Отказ — действующий результат и объяснение:
Следующая правка до ответа — правило:
Контрольные примеры / свидетельство решения:

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

Если такой участок есть в вашем проекте, опишите одно действие и нужный результат. Первый разговор бесплатный; готовое ТЗ не обязательно. Обсудить свою задачу.