Веб-приложение для контроля дедлайнов тендеров: статусы, документы, роли и напоминания. Пайплайн от поиска до результата и чек-листы.
Когда тендеров становится больше пары в месяц, чаще ломается не поиск, а подготовка. Сроки разъезжаются, документы живут в разных папках, последняя версия заявки теряется в переписке, а ответственность размазывается между людьми.
Таблица и почта помогают, пока все помещается в голове. Но как только два-три тендера идут параллельно, начинаются типовые провалы: кто-то обновил файл и не сообщил, важное разъяснение от площадки увидели поздно, дедлайн подачи перепутали с дедлайном запроса разъяснений, а в день Х внезапно выяснилось, что справка просрочена.
Поэтому инструмент для контроля тендеров должен фиксировать не «все подряд», а несколько вещей, которые реально спасают сроки и нервы:
Смысл не в дополнительной отчетности. Смысл в двух ответах за 10 секунд: что горит сегодня и что мешает подаче.
Успех измеряется просто: меньше просрочек и «пожаров» в последний день, быстрее подготовка заявки, меньше дублей и ошибок в документах, понятная история изменений. Если команда ведет 10-15 тендеров в месяц, даже минус 1-2 срыва сроков уже обычно окупает внедрение.
Если вы собираете такой инструмент в TakProsto, заранее договоритесь о минимальном наборе полей и действий. Тогда карточку тендера будут заполнять одинаково, без лишних обсуждений в чатах.
Пайплайн нужен, чтобы каждый тендер был в одном понятном состоянии, а дедлайны не жили в головах и переписках. На практике достаточно простой цепочки, где у каждого шага есть минимум обязательных полей.
На этом этапе важно быстро зафиксировать исходные данные, пока тендер не потерялся:
Именно здесь чаще всего срываются сроки, поэтому кроме дедлайна важны готовность и блокеры. Чтобы не было «серой зоны», полезны промежуточные состояния вроде «уточняем», «ждем разъяснений», «нужна правка от юристов», «ждем КП от поставщика».
Фиксируйте три вещи: что уже готово по документам, что мешает двигаться дальше, кто что согласовал. Комментарии держите короткими и фактологичными: «Нужна гарантия на 12 мес, проверяет юрист».
Важно запомнить не «мы отправили», а подтверждение: дата и время подачи, номер заявки/квитанции, кто отправил, были ли замечания площадки. Если была повторная подача, храните обе попытки.
Чтобы разбирать результаты без бюрократии, хватит двух полей: «результат» и «причина». Причину лучше выбирать из короткого списка (цена, документы, сроки, техчасть, обеспечение) и добавлять одну фразу пояснения.
Пример: «Проиграли: цена. Победитель ниже на 4%, мы не смогли снизить из-за маржи».
Чтобы карточка не превратилась в свалку заметок, она должна отвечать на три вопроса: что это за тендер, какие даты критичны и что уже готово для подачи.
Начните с реквизитов, которые помогают быстро найти тендер и понять контекст: номер/идентификатор, заказчик, площадка, предмет закупки, сумма. Источник фиксируйте как текст (например, название страницы и строка с адресом).
Отдельно держите один главный статус по пайплайну (нашли, готовим, подали, выиграли, проиграли) и короткую причину финала.
Даты лучше хранить не одной строкой, а набором полей. Минимальный набор:
Так проще строить напоминания и не путать «сегодня подать» и «завтра внести обеспечение».
Документы удобнее вести списком, где у каждого пункта есть: что именно требуется, статус готовности (не начато, в работе, готово, проверено), ответственный и версия/файл (например, «устав v3 от 12.01»). Это снимает хаос, когда в почте лежат три разных «финальных» файла.
Для прозрачности добавьте историю изменений: кто поменял поле, когда и зачем. Отдельно пригодятся поля для рисков, вопросов к заказчику и контактов.
Если вы собираете карточку через чат в TakProsto, попросите сразу заложить справочники статусов, шаблон документов и журнал изменений. Тогда структура будет одинаковой для всех тендеров.
Интерфейс тендерного учета живет или умирает на простом вопросе: можно ли за 30 секунд понять, что горит сегодня и кто за это отвечает. Если экран перегружен, люди возвращаются в таблицы и мессенджеры. Поэтому имеет смысл ограничиться несколькими рабочими экранами.
Главная страница должна быть списком с быстрыми фильтрами, а не «красивой аналитикой». Обычно достаточно фильтров по статусу, дедлайну (сегодня/3 дня/неделя), заказчику и ответственному, плюс поиск по названию и номеру. В строке тендера показывайте один главный дедлайн и индикатор готовности документов.
Для ежедневной работы многим удобен канбан по статусам. Лучше, когда это переключатель режима рядом со списком, а не отдельный «сложный раздел».
В карточке оставьте то, что помогает пройти путь «нашли -> готовим -> подали -> выиграли/проиграли». Обычно хватает трех блоков: дедлайны, документы с отметками готовности, лента комментариев и решений (включая согласования).
Быстрое добавление тендера должно быть «в один вдох». Поля, без которых нельзя начать работу:
Остальное (сумма, площадка, файлы, дополнительные даты) заполняется по мере подготовки.
Если учет уже ведется в Excel, начните с импорта как стартового шага: система создаст черновики карточек, а команда постепенно доведет их до рабочего вида. В TakProsto это удобно делать через чат: вы описываете поля и роли, а платформа собирает форму, список и карточку под ваш процесс.
Пример: менеджер нашел тендер и занес только номер, заказчика, дедлайн и себя как ответственного. Юрист отмечает готовность доверенности и заявки, руководитель фиксирует решение «подаем», после чего статус одной кнопкой уходит в «готовим».
MVP должен решать одну задачу: чтобы команда каждый день видела, что горит, что готово и кто отвечает за следующий шаг.
За 30 минут зафиксируйте роли и статусы. Статусы должны быть проверяемыми: что означает «готовим», какие признаки «подали», что именно считается «проиграли». На этом же листе отметьте обязательные даты.
Сделайте простой прототип экранов: список тендеров с фильтрами по статусу и дедлайну, карточка тендера, блок документов, календарь или лента событий. Это можно набросать как схему, а затем перенести в приложение. В TakProsto удобно описать такие экраны прямо в чате и получить рабочий черновик.
Добавьте уведомления, но начните с базового: за 3 дня и за 24 часа до подачи, плюс сигнал при просрочке. Если сразу покрыть все даты, уведомления начнут игнорировать.
Включите «защиту от хаоса»: логичные переходы статусов (нельзя «подали», если не заполнена дата подачи), обязательные поля, минимальные проверки по документам (например, без коммерческого предложения недоступно «готово к подаче»).
Запустите пилот на 10-20 тендерах на 1-2 недели и собирайте обратную связь: какие поля не нужны, какие статусы путают, где не хватает напоминаний.
Уведомления должны быть редкими, но точными. Люди быстро привыкают игнорировать постоянные напоминания, поэтому лучше заложить понятный ритм и правило подтверждения.
Практичный набор напоминаний по одному ключевому дедлайну (подача заявки):
Каналы выбирайте по «силе сигнала». Внутри приложения удобно показывать ленту задач и маркер на карточке тендера. Email подходит для 7 и 3 дней. Корпоративный мессенджер уместен для 24 и 2 часов, когда нужна быстрая реакция.
Чтобы не слать лишнее, добавьте подтверждение готовности: ответственному приходит уведомление, и он отмечает «в работе» или «готово». Если на критичных сроках отметки нет в течение нескольких часов, включается эскалация. Это должно быть про помощь снять блокер, а не про наказание.
Отдельно обрабатывайте изменения. Если дедлайн сдвинулся или документ обновился, система пересчитывает напоминания, помечает тендер как «требует пересборки» и просит подтверждение заново.
Не забывайте про обеспечение: по обеспечению заявки и по обеспечению контракта часто живут отдельные сроки и отдельные ответственные. В TakProsto это удобно оформить как дополнительные даты в карточке тендера и разнести ответственность (финансы, юрист).
Хаос в тендерах почти всегда начинается с документов: один файл устарел, второй «где-то у юриста», третий сделали, но забыли приложить. Лучше держать документы как отдельные сущности со статусами, а не как «папку на диске».
Соберите типовой набор категорий, который подходит большинству закупок: уставные и регистрационные, финансовые, подтверждение опыта, сведения о персонале, лицензии и допуски. Для каждого документа хватит простых полей: формат, срок действия или дата обновления, ответственный за актуальность, место хранения и пометка «когда требуется».
Чтобы всем было понятно, где затык, используйте короткую шкалу и не допускайте «своих вариантов»:
Если документ после «проверен» возвращается в «в работе», должна быть причина. Это сигнал, что требования изменились или найдено несоответствие.
Перед кнопкой «Отправить» полезен короткий чек «готовность к подаче». Он не про красоту, а про обязательные вещи:
Версии проще вести как v1, v2, v3, при этом «актуальная» должна быть только одна. Если в карточке видно, что v1 неактуальна и не может получить статус «приложен», ошибка не пройдет дальше.
Если вы собираете MVP через TakProsto, попросите добавить шаблон чек-листа по типам процедур и правило: при смене статуса на «подали» система проверяет, что обязательные документы закрыты по статусам.
Даже простой учет быстро превращается в хаос, если не зафиксировать: кто двигает статус, кто правит документы, а кто только смотрит. Роли нужны не для бюрократии, а чтобы каждый шаг был предсказуемым.
Чаще всего распределение такое: инициатор (нашел тендер и понимает, зачем он компании), тендер-менеджер (ведет карточку и сроки), юрист (требования и договор), финансы (обеспечение, платежи, цена), технический специалист (ТЗ и подтверждения), руководитель (решение участвовать и финальное утверждение).
Права лучше задавать по действиям:
Чтобы согласования не терялись в чатах, заведите короткий «журнал решений» в карточке: дата, автор, решение (участвуем/не участвуем), причина и кто утвердил.
Замены на время отпуска лучше оформлять заранее. Минимальный порядок передачи:
Если вы делаете это через TakProsto, роли и права стоит обсудить в начале и сразу заложить в структуру карточки и действия кнопок. Тогда статусы, документы и напоминания работают как единый процесс.
Менеджер по продажам находит закупку на поставку оборудования и заводит карточку. Сразу фиксирует ключевые даты: крайний срок запроса разъяснений, крайний срок подачи, дату рассмотрения/аукциона (если есть), сроки обеспечения и подписания. Ставит «нашли», затем переводит в «готовим», чтобы всем было видно, что работа началась.
Дальше назначаются роли и ожидаемые результаты прямо в карточке: какой файл должен появиться, какая отметка должна быть поставлена, какое решение зафиксировано.
Пока идет подготовка, команда ведет чек-лист документов. За день до дедлайна система отправляет напоминание ответственному, а руководителю - только если остаются пункты со статусом «нужно исправить» или «в работе».
В день подачи менеджер проходит «чек-лист подачи», затем переводит тендер в «подали» и фиксирует номер заявки, дату и время, подтверждение (квитанцию или скрин). Это важно при разборе спорных ситуаций: всегда видно, что и когда отправляли.
Когда приходит результат, карточка закрывается как «выиграли» или «проиграли» и добавляется короткий разбор: причина, следующее действие и что улучшить в процессе.
Главная причина, почему система не приживается: людям неудобно вносить данные, а руководителю нечего смотреть.
Слишком строгая карточка тендера. Если при создании нужно заполнить 20 полей, тендеры заводят «потом», а потом уже поздно. Держите входной порог низким: номер, заказчик, крайний срок, ответственный. Остальное - по мере подготовки.
Файлы и версии живут «где-то». В итоге никто не уверен, какая версия заявки финальная. Нужен один источник правды: файлы в карточке, понятные названия, отметка версии/даты и правило «финал кладем только сюда». Если используете TakProsto, удобно фиксировать состояние снапшотом перед подачей, чтобы было к чему откатиться.
Напоминания без владельца. Уведомление пришло всем, но действие не сделал никто. Любое напоминание должно быть привязано к роли и конкретному человеку.
Смешанные статусы. Когда «готовим» и «подали» фактически в одном этапе, непонятно, что уже отправлено, а что еще черновик.
Рабочий минимум обычно выглядит так:
Перед тем как команда начнет жить в новом инструменте, пройдите короткую проверку.
Для каждого тендера должна быть одна точка правды: дата и время подачи, часовой пояс и конкретный ответственный. Если ответственный «отдел» или «мы», на практике это значит «никто». Лучше требовать эти поля при создании карточки.
Проверьте согласованность процесса. Статусы должны переходить одинаково у всех, иначе отчеты и напоминания станут бесполезными. Хорошее правило: статус меняется только когда есть измеримый факт (документ готов, заявка подана, получен протокол).
Короткий чек-лист запуска:
Мини-сценарий для проверки: возьмите один реальный тендер и проведите его по всем шагам в тестовом режиме. Если на этапе «готовим» возникает вопрос «а где это отметить», интерфейс еще не готов.
Не начинайте с «идеальной системы». Начните с одного понятного описания процесса, которое примет вся команда, и сразу проверьте его на реальных тендерах.
Соберите пайплайн и роли в одном сообщении и согласуйте формулировки: «нашли -> готовим -> подали -> выиграли/проиграли», плюс кто отвечает за каждый шаг и что считается «готово».
В этом первом сообщении стоит зафиксировать:
Дальше сформулируйте требования к экранам так, как вы объяснили бы это новому сотруднику: карточка тендера, список, календарь дедлайнов, журнал изменений. Соберите первую версию и прогоните неделю на 5-15 живых тендерах. Спрашивайте команду не «нравится ли», а где теряли время, что забывали и какие поля стабильно не заполняли.
После теста добавляйте только то, что экономит минуты каждый день: отчеты по воронке и просрочкам, шаблоны и проверки комплекта, автоматизацию рутинных шагов, снимки и откат.
Если нужно быстро собрать рабочий прототип через чат, TakProsto (takprosto.ai) подходит для таких задач: можно описать пайплайн, роли и чек-листы словами и получить основу приложения, которую затем проще доработать под ваш реальный порядок работы.
Начните с одного главного дедлайна — срока подачи — и добавьте рядом 3–5 ключевых дат: запрос разъяснений, вскрытие/итоги, обеспечение заявки, обеспечение контракта, подписание. Даты храните отдельными полями, чтобы не путать «подачу» и «вопросы» и чтобы уведомления считались автоматически.
Минимально достаточно цепочки: «нашли → готовим → подали → выиграли/проиграли». Важно, чтобы у каждого статуса был понятный факт перехода: нашли — зафиксировали данные и ответственного; готовим — ведем документы и блокеры; подали — есть квитанция/номер; результат — есть протокол и короткая причина.
Держите порог входа низким: номер или название, заказчик, главный дедлайн, статус и ответственный. Остальное заполняйте по мере работы через чек-лист и комментарии, иначе тендеры будут заводить «потом» и терять сроки.
Сделайте документы отдельным списком с понятными статусами: «нужен», «в работе», «готов», «проверен», «приложен». У каждого документа должны быть ответственный, дата проверки и срок действия (если он важен), чтобы в последний день не выяснялось, что справка просрочена.
Примите правило: «актуальная версия всегда одна» и она явно помечена (например, v3 от 12.01). Черновики могут быть сколько угодно, но статус «приложен» разрешайте только актуальной версии, иначе в подачу уйдет случайный файл из переписки.
Начните с двух уведомлений по подаче: за 24 часа и за 2 часа, плюс сигнал о просрочке. Дальше добавьте за 7 и за 3 дня, когда команда уже привыкла, иначе напоминания начнут игнорировать и смысл пропадет.
У каждого напоминания должен быть один владелец — конкретный человек, а не «отдел». Хорошая практика — подтверждение статуса («в работе/готово»), а при молчании включается эскалация руководителю как просьба снять блокер, а не как наказание.
Разделите права по действиям: тендер-менеджер ведет карточку и сроки, профильные роли правят свои документы, руководитель подтверждает финальные переходы («подали», «выиграли/проиграли»). Так статус не «размазывается» по людям, и всегда понятно, кто отвечает за следующий шаг.
Запишите измеримые критерии: какие документы должны быть хотя бы в «проверен», какие поля заполнены, что считается «подали» (время, квитанция, номер). Если нет факта, статус не меняется — это защищает от ситуации «вроде подали», а по факту нет подтверждения.
Сделайте два поля: «результат» и «причина» из короткого списка (цена, документы, сроки, техчасть, обеспечение), плюс одна фраза пояснения. Этого хватает, чтобы разбирать ошибки и улучшать процесс без лишней бюрократии.
