Мониторинг тендеров: фильтры поиска, уведомления и проверка подходящих закупок

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

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

Что входит в мониторинг тендеров

Мониторинг состоит из трёх операций:

1. Найти новое извещение в выбранных источниках.
2. Сопоставить его с профилем подходящей закупки и объяснить решение.
3. При следующем сборе отличить неизменный повтор от новой версии.

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

Первичный отбор отвечает на вопрос: «Стоит ли сейчас открыть эту закупку и изучить подробнее?» Он не отвечает на вопрос: «Можно ли участвовать и как подготовить заявку?» Для второго вопроса нужно читать документацию выбранной закупки, проверять требования и принимать профессиональное решение. Это соседний процесс, который разобран в руководстве по планированию и обработке закупочной работы.

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

Как задать профиль подходящих закупок

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

Для учебного примера зададим синтетический профиль:

• товар — «промышленный насос»;
• синонимы — «насосное оборудование», «насосная установка»;
• исключающие слова — «бытовой», «ремонт»;
• территория исполнения — Москва;
• срок подачи — не раньше 20.10.2026;
• заказчик — организация из согласованного компанией перечня.

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

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

Полезно разделить правила на три группы:

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

Если правило нельзя объяснить одной строкой и одинаково применить к нескольким примерам, его рано передавать автоматизации.

Как выбрать источники и собрать выдачу

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

Проверку удобно проводить на контрольном списке известных извещений:

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

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

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

Единую выдачу лучше приводить к общей структуре:

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

Как убрать дубли и отследить изменения

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

Упрощённая модель использует два ключа:

• ключ карточки — notice_id;
• ключ события — сочетание notice_id + version.

При каждом сборе система действует последовательно:

1. Ищет карточку по notice_id.
2. Если карточки нет, создаёт новую и фиксирует источник.
3. Если карточка есть и версия не изменилась, обновляет время проверки без нового уведомления.
4. Если появилась новая версия, сравнивает значимые поля и создаёт событие изменения.

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

Важно не считать версию отдельным тендером. Если у извещения SYN-002 появились версии v1 и v2, в очереди остаётся одна карточка и два связанных события. Иначе повторный сбор раздует список и скроет действительно новые закупки.

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

Учебный отбор двух извещений

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

Профиль допускает Москву и срок подачи не раньше 20.10.2026. Первый сбор находит две карточки.

Расширенная запись решения выглядит так:

Начальный расчёт: 2 найденных извещения − 1 исключённое = 1 подходящее извещение. Ключевое слово сработало в обеих карточках, но только одна прошла региональный фильтр.

При повторном сборе неизменённая версия SYN-002-v1 не создаёт нового уведомления. Позже источник показывает SYN-002-v2: идентификатор остаётся прежним, а срок меняется с 20.10.2026 на 23.10.2026. Разница составляет 3 календарных дня.

Ожидаемый текст учебного уведомления:

SYN-002: срок подачи изменён с 20.10.2026 на 23.10.2026; разница +3 календарных дня; откройте первоисточник и перепроверьте актуальную версию.

Это ожидаемое поведение синтетического сценария, а не сообщение, которое уже отправил реальный сервис. После обновления новых закупок — 0, существенных изменений — 1, уведомлений об изменении — 1. Активная подходящая карточка по-прежнему одна.

Контрольные величины всего примера:

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

Как выбрать сервис и канал уведомлений

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

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

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

Полезное уведомление содержит:

• идентификатор извещения;
• пометку «новое» или «изменение»;
• причину попадания в очередь;
• изменившееся поле со старым и новым значением;
• ссылку на первоисточник;
• требуемое действие и ответственного.

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

Как проверить поиск и подключить автоматизацию

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

Затем автоматический отбор прогоняют на той же выборке и сравнивают три набора данных:

1. Ручную разметку специалиста.
2. Очередь, сформированную по профилю.
3. Журнал новых и повторных уведомлений.

Без реальной выборки не нужно придумывать проценты. Заранее можно определить формулы:

• полнота = найденные системой подходящие извещения / все подходящие по ручной разметке;
• точность = верно отобранные извещения / все отобранные системой;
• доля повторных уведомлений = дубли / все уведомления.

Отдельно проверяют понятность причин. Если система исключила карточку, специалист должен увидеть конкретное правило и исходное значение, например: «регион исполнения — Казань; профиль допускает Москву». Ответ «не соответствует» не помогает найти ошибку настройки.

Минимальный набор проверок включает:

После контрольной проверки можно обсуждать автоматизацию одной операции. Switch On AI может спроектировать ИИ-помощника, бота или обычную интеграцию: вариант зависит от того, нужно ли интерпретировать документы, вести диалог или выполнять фиксированную последовательность обмена данными.

Например, интеграция может собирать доступные поля, сопоставлять версии и направлять уведомления. ИИ-помощник уместен, если требуется подготовить объяснение по тексту документа, но его вывод всё равно проверяет специалист. Система не определяет юридическую пригодность участия и не отправляет заявку автоматически.

Перед проектированием нужно проверить данные, API, права доступа, тарифы и ограничения каждого выбранного сервиса. Упоминание Тендерплана в статье не означает партнёрство, проверенную совместимость или уже выполненное внедрение.

Чтобы обсудить прототип, подготовьте профиль подходящей закупки, несколько обезличенных примеров включения и исключения, перечень источников и ожидаемое уведомление об изменении. На странице разработки ИИ-агентов описаны границы такого проекта. Затем можно разобрать одну операцию со Switch On AI и согласовать проверяемый прототип без обещания полного отраслевого внедрения или гарантированного эффекта.