CRM тендерного отдела: комплект готов, но заявка не подана

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

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

Согласуйте значение завершённого этапа

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

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

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

Две даты должны отвечать на разные вопросы

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

Для учебного примера выберем внешний срок 15:00 и внутреннюю проверку в 13:30 одного условного дня. Эти значения придуманы для обсуждения интерфейса, а не взяты из настоящей закупки. В 13:30 документы собраны, цена не согласована, а подачи ещё не было. Корректный итог контроля — открытые условия с ответственными, а не автоматическая зелёная отметка всей карточки.

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

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

Документ относится к версии, а не только к папке

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

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

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

Не объединяйте подготовку и подтверждение внешнего действия

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

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

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

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

Экран руководителя должен показывать препятствие

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

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

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

Принимайте CRM на изменениях перед сроком

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

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

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