Спецификация трекера продления контрактов для напоминаний и согласований

Что должен решать трекер продлений

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

Трекер должен отвечать на базовые вопросы за секунды:

• Что продлевается (поставщик/клиент, контракт, услуга)
• Когда это происходит (крайний срок уведомления, дата окончания, дата автоматического продления)
• Кто должен действовать (бизнес‑владелец, юристы, финансы, procurement)
• Что будет дальше (обзор, согласование, подпись, оплата)
• Что изменилось (заметки, принятые решения и кто их утвердил)

Цель — предсказуемые продления без сюрпризов и авралов. Для этого нужны надежные даты, ясный ответственный и статус, отражающий реальность. Если контракт помечен как "Under review", люди должны видеть, что именно блокирует движение и кто отвечает за следующий шаг.

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

Заинтересованные стороны и ответственности

Трекер работает только если владение явно обозначено. Если все "ответственные", то фактического ответственного нет.

У большинства команд складывается небольшой набор ролей:

• Contract owner: ведёт продление, подтверждает потребности, согласовывает условия и держит даты в актуальном состоянии.
• Requester: человек или команда, использующая услугу; решает, продлевать, уменьшать тариф или отменять.
• Finance: проверяет бюджет, условия оплаты, настройки поставщика и изменения затрат.
• Legal: проверяет условия, вносит правки и оценивает риски; подтверждает применимый шаблон или набор клаузул.
• Department head: финальный бизнес‑утвердитель, когда расходы или объём превышают порог.

Отделяйте утверждающих от тех, кого просто информируют. Утверждающие могут изменить исход (утвердить, отклонить, запросить изменения). Информируемые получают обновления, но не блокируют процесс.

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

Не игнорируйте сторону поставщика. Храните контакты поставщика по ролям, а не одним общим емейлом, поскольку разные люди решают разные вопросы. Большинству команд нужны как минимум контакт по продажам (коммерческие условия), контакт по выставлению счетов (инвойсы и оплаты) и служба поддержки (вопросы по сервису и эскалации).

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

Сущностная модель: какие таблицы действительно нужны

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

Основные таблицы

Начните с небольшого набора таблиц и практичных полей:

• Vendors: юридическое название, регистрационные данные, адрес, уровень риска, флаг активности.
• Contracts: vendor_id, название услуги, дата начала, дата окончания, условия продления (автопродление, период уведомления), стоимость контракта, валюта, владелец.
• Contacts: внутренние и внешние контакты с типом (vendor/internal), ролью (юрист, финансы, владелец сервиса), предпочитаемым каналом (email/SMS/Telegram), is_primary.
• Documents: метаданные файлов плюс тип (оригинал, поправка, котировка на продление, заметка) и краткое описание.
• RenewalCases: contract_id, начало/окончание цикла, целевая дата решения, текущая стадия/статус, причина (продлить, пересогласовать, расторгнуть).

На практике Contracts меняются медленно. RenewalCases фиксируют, что произошло в этом цикле: кто согласовал, какую котировку получили и когда принято решение.

Отношения, которые предотвращают беспорядок в данных

Смоделируйте отношения так, чтобы можно было без догадок ответить «кого уведомлять?» и «что мы решили в прошлый раз?»:

• Vendors 1‑ко‑многим Contracts, Contracts 1‑ко‑многим RenewalCases
• Contracts многие‑ко‑многим Contacts (через соединительную таблицу типа ContractContacts с ролью)
• RenewalCases 1‑ко‑многим Documents (котировки и заметки привязаны к циклу)

Пример: SaaS‑контракт с периодом уведомления 60 дней должен иметь одну запись Contract, но новый RenewalCase каждый год. Случай 2025 хранит котировку, согласования и дату решения, не перезаписывая 2024.

Даты, условия и статусы, управляющие продлениями

Трекер работает только если даты и статусы однозначны. Рассматривайте даты как источник истины, а каждый статус должен отражать, что команда должна делать дальше.

Начните с небольшого набора обязательных дат:

• Start date и current term end date
• Notice deadline (дата окончания минус период уведомления)
• Cancellation deadline (иногда совпадает с notice deadline, иногда нет)
• Next auto‑renew date (только если включено автопродление)
• Last renewed on

Храните AutoRenew как булево значение (AutoRenew = true/false), затем поддерживайте это понятными условиями: длина срока продления (например, 12 месяцев), порядок продлений (ежемесячно, ежегодно, многолетний) и считается ли дата продления от даты окончания или от даты выставления счета.

При вычислении следующей даты продления используйте одно правило на контракт (месячный — +1 месяц, годовой — +12 месяцев, многолетний — +N лет). Если продление произошло досрочно, заранее решите, как вычисляется новая дата окончания: старый конец плюс срок или дата продления плюс срок. Сохраните этот выбор, чтобы он позже не сдвигался.

Статусы должны соответствовать реальным рабочим шагам и всегда подразумевать владельца следующего действия. Простой набор обычно достаточен: upcoming (запланировано), in review (на рассмотрении), waiting approval (ожидает согласования), approved (согласовано), renewed (продлён), canceled (отменён).

Обрабатывайте крайние случаи явно:

• Unknown end date: помечайте как "date missing" и блокируйте напоминания до исправления.
• Evergreen contracts: нет даты окончания, но добавляйте периодические даты обзора.
• One‑time purchases: нет продления, но сохраняйте для истории расходов.

Пример: 12‑месячный контракт с автопродлением и 60‑дневным сроком уведомления может перейти в статус "upcoming" за 90 дней до окончания, а затем эскалировать, если крайний срок уведомления пройдет без решения.

Согласования: стадии и правила маршрутизации

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

Обычный набор стадий:

• Owner review
• Manager approval
• Finance approval
• Legal approval
• Security or Procurement approval (только при необходимости)

Маршрутизация должна быть основана на правилах, а не на ручном выборе. Стоимость контракта, уровень риска поставщика и тип контракта покрывают большую часть случаев. Например, низкорискованные продления ниже небольшого порога могут требовать только Manager и Finance. Для более дорогих или рискованных — добавляйте Legal и Security.

Определите четкие триггеры начала согласований. Типичные триггеры: создание RenewalCase, получение котировки или изменение цены. Рассматривайте изменение цены или ключевых условий как сброс согласований. Если котировка меняется после начала согласований, повторно откройте необходимые стадии, чтобы финальная подпись соответствовала текущим условиям.

Действия согласования должны быть явными: approve, reject или request changes. "Request changes" приостанавливает поток и возвращает задачу владельцу с обязательными комментариями. Отклонение должно содержать причину и следующий шаг (переговоры, отмена, смена поставщика).

Пример: продление SaaS на $30k с высоким уровнем риска маршрутизируется Owner -> Manager -> Finance -> Legal -> Security.

Правила напоминаний и эскалаций

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

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

Простой график по каждой вехе:

• 90 дней до
• 60 дней до
• 30 дней до
• 14 дней до
• 7 дней до

Эскалация должна срабатывать из‑за отсутствия действий, а не только по времени. Определите, что считается действием, например подтверждение владельцем, выбор решения (продлить, отменить, пересогласовать) или отправка запроса на согласование.

Практичная цепочка эскалаций:

• Если нет действий в течение 3 рабочих дней после напоминания — уведомить резервного владельца.
• Если всё ещё нет действий в течение ещё 5 рабочих дней — уведомить менеджера владельца.
• Если до крайнего срока уведомления остаётся 7 дней и решения нет — уведомить общий почтовый ящик Legal/Procurement.
• Для дорогостоящих продлений также уведомлять Finance за 30 дней.

Отправляйте сообщения в рабочее время в часовом поясе владельца (например, 9:00–17:00 по рабочим дням). Если часовой пояс владельца неизвестен, используйте часовой пояс бизнес‑единицы контракта.

Условия остановки должны быть строгими. После пометки RenewalCase как Approved, Renewed, Canceled или Replaced все будущие напоминания для этого случая должны прекращаться немедленно. Если владелец выбирает "Renegotiate" за 60 дней до крайнего срока, приостановите напоминания об уведомлении и переключитесь на напоминания по переговорам и согласованиям.

Правила содержания уведомлений и шаблоны

Уведомления работают, когда нужные люди получают нужное сообщение в нужное время. Держите содержание согласованным для email, in‑app и чатов, чтобы никто не спрашивал, о чём сообщение.

Типичные аудитории по шагам:

• Владелец контракта: всегда, на каждой вехе
• Текущий(ие) согласующий(ие): только когда требуется действие
• Наблюдатели (legal, procurement, аккаунт‑команда): при изменениях статуса и завершении согласований
• Finance: когда нужен PO или расход превышает порог
• Менеджер эскалации: только после пропуска сроков или зависших согласований

Обязательные поля сообщения

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

• Название контракта и поставщик
• Дата продления (и сколько дней осталось)
• Текущий статус и владелец стадии
• Следующее действие (утвердить, просмотреть котировку, подтвердить PO, вести переговоры)
• Где действовать (имя экрана или идентификатор записи)

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

Шаблоны

Используйте две версии: краткую для мобильных/чатов и детальную для email или in‑app.

SHORT (chat/push)
[Renewal due in {days_left} days] {contract_name} - {vendor}
Status: {status}. Next: {next_action}.
Record: {contract_id}

DETAILED (email/in-app)
Subject: Action needed: {contract_name} renewal by {due_date}

Vendor: {vendor}
Due date: {due_date} ({days_left} days)
Current status: {status}
Next action: {next_action}
Owner: {owner_name}
Approver(s): {approver_list}
Price: {current_price} ({currency})
Last renewal: {last_outcome} on {last_renewal_date}
Quote: {quote_available}
Notes: {key_notes}
Record: {contract_id}

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

Шаг за шагом: реализуйте рабочие процессы

Начните с фундамента: надёжной модели данных и чёткого владения.

1) Сначала постройте сущности

Создайте основные таблицы и свяжите их жёстко: Contracts, Vendors, внутренние Stakeholders (пользователи или команды) и RenewalCases. Contracts должны ссылаться на Vendor и Owner. RenewalCases должны ссылаться на Contract, содержать текущий статус продления и ключевые даты для напоминаний.

Практическое правило: один Contract может иметь много RenewalCases со временем, но только один активный случай одновременно.

2) Определите статусы и правила валидации

Решите, какие статусы существуют и какие поля обязательны на каждом этапе. Будьте строгими. Не разрешайте "Legal review", если не прикреплены черновые условия продления и соответствующий документ. Не разрешайте "Approved", если не указаны согласующий, дата согласования и итоговые даты срока.

3) Создайте рабочие процессы статусов

Реализуйте процессы, которые:

• Автоматически создают RenewalCase, когда контракт входит в окно продления
• Переводят случай через стадии (Draft, Review, Approved, Sent, Closed)
• Маршрутизируют задачи на основе поставщика, типа контракта, стоимости, уровня риска или отдела
• Фиксируют каждое изменение статуса как событие аудита
• Закрывают случай и обновляют Contract, когда продление завершено

Пример: если контракт принадлежит Operations и годовая сумма выше порога, требуйте Legal review до Finance approval.

4) Добавьте плановые проверки напоминаний и эскалаций

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

5) Подключите каналы и логируйте доставки

Отправляйте уведомления через каналы, которые люди действительно читают (email, SMS, Telegram). Логируйте каждую попытку доставки с временной меткой, каналом, получателем и результатом, чтобы можно было доказать отправку напоминаний и отладить пропуски.

Экраны и отчёты, которые люди будут использовать ежедневно

Люди поддерживают трекер в актуальном состоянии, когда ежедневные экраны отвечают на один вопрос быстро: что мне нужно сделать дальше? Сделайте несколько представлений, которые соответствуют реальным привычкам, вместо одного гигантского дашборда.

Календарь продлений (вид команды)

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

Входящие владельца (мои продления)

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

Небольшой набор полей достаточен:

• Название контракта + поставщик
• Крайний срок уведомления + дата продления
• Статус + следующий шаг
• Уровень риска + оценочная ежемесячная стоимость

Очередь согласований (мои согласования)

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

Вид по поставщику (всё по одному вендору)

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

Ежедневные отчёты, которые люди действительно читают

Держите отчёты простыми и планируемыми: предстоящие расходы по месяцам, продления под риском (крайний срок уведомления в пределах X дней) и просроченные действия по владельцам.

Базовые права доступа и аудит

Трекер работает, когда люди ему доверяют. Это достигается двумя вещами: нужные люди видят нужные данные, и каждое важное изменение записано.

Ролевой доступ (что люди могут видеть и делать)

Начните с небольшого набора ролей и расширяйте по необходимости:

• Viewer: видит базовые детали и даты, но не видит цену и вложения.
• Contract Owner: редактирует свои контракты, загружает документы, запрашивает согласования.
• Approver (Legal/Finance/Procurement): утверждает или отклоняет, добавляет комментарии, видит значения контрактов и ключевые клаузулы.
• Admin: управляет ролями, изменяет правила маршрутизации, работает с архивами.

Держите чувствительные поля отдельно от общих. Обычно ограничивают: стоимость контракта, прайс‑листы, банковские данные и подписанные PDF. Если документ нужно широко расшарить, храните редактированную/редактированную версию отдельно.

Журнал аудита (что нужно логировать)

Считайте изменения статусов, согласования и обновления документов аудируемыми событиями. Фиксируйте, как минимум:

• Changed by (пользователь), changed at (временная метка)
• Поле или действие (статус, владелец, дата продления, срок, загрузка документа)
• Старое значение и новое значение
• Комментарий (обязателен при отклонении, расторжении или изменении даты)
• Источник (UI, автомат, импорт), если доступно

Для документов храните версии и помечайте один файл как current signed copy. Не перезаписывайте. Храните имя файла, номер версии, кто/когда загрузил и опциональную метку вроде "Signed v3.".

Предпочитайте архивирование вместо жёсткого удаления. Архивные контракты должны оставаться доступными для отчётности и истории продлений.

Прежде чем контракт может двигаться дальше, требуйте нескольких проверок: vendor, owner, backup owner, start/end даты (или флаг evergreen), тип продления (auto или manual), период уведомления и срок продления.

Распространённые ошибки и как их избежать

Самый быстрый способ потерять доверие к трекеру — пропустить срок, который вы считали отслеживаемым.

Одна распространённая ошибка — иметь одно поле "renewal date" и считать задачу решённой. Реальные продления завязаны на период уведомления (например, "дайте 60 дней уведомления или автопродление на год"). Исправьте это, отслеживая, по крайней мере: дату вступления в силу, дату окончания срока, флаг автопродления, крайний срок уведомления и вычисляемую дату следующего действия, которая управляет напоминаниями.

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

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

Уведомления игнорируют, когда не дают следующего шага. Каждое напоминание должно содержать одно следующее действие (просмотреть, утвердить, пересогласовать, отменить), дату и последствие (автопродление, повышение цены, приостановка сервиса).

Команды также забывают записывать результаты, так что каждый цикл начинается с чистого листа. Фиксируйте исход (renewed, terminated, renegotiated), новые условия и короткую заметку "что изменилось".

Быстрые проверки и следующие шаги

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

Быстрые проверки (возьмите 3 тестовых контракта)

Создайте три примерных контракта с разными условиями:

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

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

Затем протестируйте согласования end‑to‑end. Пропустите один контракт через путь согласований, а другой — через путь отклонения. Убедитесь, что аудит фиксирует кто, когда и почему принял решение. Если логи не отвечают на вопрос "что произошло?" за 10 секунд, они не помогут в авральной ситуации.

Следующие шаги

Начните с малого и расширяйтесь только когда основа станет скучной:

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

Если вы хотите реализовать это как внутреннее операционное приложение без разработки, AppMaster (appmaster.io) — один из вариантов для моделирования данных, построения рабочих процессов согласований и отправки уведомлений по каналам.

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