Как сделать ИИ-агента для тендеров, RFP и коммерческих предложений

Что получится в результате

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

Первая рабочая версия будет делать так:

1. пакет RFP попадает в папку `rfp_inbox`;
2. n8n создает строку в `rfp_queue`;
3. агент копирует оригиналы в `rfp_archive`;
4. извлекает текст из PDF, DOCX, XLSX, email и приложений;
5. определяет тип запроса: RFI, RFQ, RFP, тендер, vendor questionnaire, security questionnaire или запрос КП;
6. выделяет сроки, формат подачи, критерии оценки и обязательные документы;
7. разбивает требования в `requirements_matrix`;
8. проверяет соответствие продукта и услуг;
9. спорные пункты отправляет в `approval_queue`;
10. вопросы заказчику пишет в `question_log`;
11. черновики разделов КП сохраняет в `proposal_sections`;
12. финальную готовность проверяет через `submission_checklist`;
13. решения и изменения пишет в `audit_log`.

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

Что понадобится

• n8n Cloud или self-hosted n8n.
• Google Drive, SharePoint или другое хранилище RFP-пакетов.
• Google Sheets для очередей, матрицы требований, вопросов и логов.
• Google Docs или Word для черновика КП.
• LLM API для разбора требований и генерации черновиков.
• База прошлых КП, ответов на анкеты, описаний продукта и типовых документов.
• Ответственные: sales, presales, delivery, legal, finance, security.
• 5-10 тестовых RFP или запросов КП.

Шаг 1. Ограничьте первый сценарий

Не начинайте с “любой тендер из любого источника”.

Для первого прототипа выберите сценарий:

входящий RFP от B2B-клиента на внедрение продукта или услуги

Входит:

• PDF или DOCX с требованиями;
• таблица требований;
• дедлайн подачи;
• критерии оценки;
• черновик КП;
• вопросы заказчику;
• внутреннее go/no-go;
• согласование цены, сроков, юридических рисков.

Не входит:

• автоматическая подача заявки на портал;
• электронная подпись;
• изменение цены без finance;
• юридическое принятие договора;
• обещание сроков без delivery;
• генерация фейковых кейсов или сертификатов.

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

Шаг 2. Создайте структуру папок

В хранилище создайте:

RFP AI agent
  rfp_inbox
  rfp_archive
  extracted_text
  working_drafts
  customer_questions
  review
  final_package
  lost_or_declined
  test_rfp

Правила:

оригиналы всегда копируются в rfp_archive
черновики лежат в working_drafts
финальная версия появляется только после approval

Проверка: тестовый RFP можно положить в `rfp_inbox`, а копия появляется в `rfp_archive`.

Шаг 3. Создайте таблицу проекта

Создайте Google Sheet:

RFP tender AI agent

Добавьте листы:

rfp_queue
rfp_documents
requirements_matrix
capability_catalog
risk_rules
question_log
proposal_sections
approval_queue
submission_checklist
route_log
audit_log
error_log
test_cases
settings

Проверка: n8n имеет доступ к таблице на чтение и запись.

Шаг 4. Настройте rfp_queue

В `rfp_queue` добавьте колонки:

rfp_id
created_at
source_channel
customer_name
project_name
request_type
deadline_at
submission_format
status
go_no_go
risk_level
owner_sales
owner_presales
owner_delivery
owner_legal
final_package_url
last_error
updated_at

Статусы:

new
registered
extracting
analyzing
requirements_review
questions_prepared
drafting
internal_review
ready_to_submit
submitted
declined
lost
won
error

Проверка: новый RFP получает ID и статус `registered`.

Шаг 5. Создайте rfp_documents

В `rfp_documents` храните все файлы пакета.

Колонки:

rfp_id
document_id
file_name
file_type
file_url
archive_url
document_role
text_file_url
status
created_at

Роли документов:

main_rfp
requirements_table
contract_draft
technical_spec
pricing_template
security_questionnaire
legal_attachment
clarification
other

Проверка: пакет из нескольких файлов не теряется и каждый файл имеет роль.

Шаг 6. Создайте capability_catalog

`capability_catalog` нужен, чтобы агент сравнивал требования с реальными возможностями, а не фантазировал.

Колонки:

capability_id
area
capability_name
description
status
limitations
proof_url
owner
updated_at

Статусы:

available
partially_available
roadmap
not_available
requires_partner

Пример:

api_sso | security | SSO SAML | Поддерживается для Enterprise | available | требуется настройка IdP | ссылка | security
sla_24_7 | support | Поддержка 24/7 | Только на отдельном тарифе | partially_available | нужен контракт | ссылка | support

Проверка: каждое “можем” в КП должно ссылаться на запись в capability_catalog или утверждение владельца.

Шаг 7. Создайте risk_rules

В `risk_rules` добавьте правила риска.

Колонки:

rule_id
risk_name
risk_level
trigger
owner_role
recommended_action
is_active

Первый набор:

deadline_too_close | high | дедлайн меньше 3 рабочих дней | sales | go/no-go
unlimited_liability | high | неограниченная ответственность | legal | проверить договор
penalty_sla | high | штрафы за SLA | legal,delivery | оценить риск
custom_development | medium | требуется кастомная разработка | delivery | оценить трудозатраты
missing_budget | medium | нет бюджета или цены | sales | уточнить
security_questionnaire | medium | есть security questionnaire | security | назначить владельца
mandatory_certification | high | требуется сертификат, которого нет | sales | уточнить или decline
data_residency | high | требование хранения данных в стране | security,legal | проверить возможность

Проверка: у каждого риска есть владелец и действие.

Шаг 8. Настройте входящий workflow

Создайте workflow:

RFP intake

Минимальные узлы:

1. `Google Drive Trigger`, `IMAP Email Trigger` или `Webhook`;
2. `Create rfp_id`;
3. `Copy originals to rfp_archive`;
4. `Append row to rfp_queue`;
5. `Append files to rfp_documents`;
6. `Set status = extracting`.

Формат ID:

RFP-2026-0001

Проверка: входящий пакет создает строку в `rfp_queue` и строки по файлам в `rfp_documents`.

Шаг 9. Извлеките текст и таблицы

Создайте workflow:

RFP extraction

Правила:

• PDF - извлечь текст и страницы;
• сканы - OCR;
• DOCX - текст и заголовки;
• XLSX - листы и таблицы требований;
• email - тело письма и вложения;
• ZIP - распаковать и зарегистрировать файлы.

Сохраняйте результат в `extracted_text`.

Проверка: для каждого важного файла есть текст или таблица, пригодная для анализа.

Шаг 10. Определите тип запроса

Создайте LLM-узел `Classify RFP package`.

Prompt:

Определи тип входящего запроса.
Верни только JSON.

Допустимые типы:
rfi, rfq, rfp, tender, vendor_questionnaire, security_questionnaire, commercial_proposal_request, unknown.

Формат:
{
  "request_type": "",
  "customer_name": "",
  "project_name": "",
  "deadline_at": null,
  "submission_format": "",
  "confidence": 0.0,
  "needs_review": true|false
}

Проверка: RFP с таблицей требований не превращается в простой запрос КП.

Шаг 11. Извлеките ключевые параметры

Создайте LLM-узел `Extract RFP facts`.

Prompt:

Извлеки ключевые параметры RFP.
Верни только JSON:
{
  "deadline_at": null,
  "submission_channel": "",
  "required_documents": [],
  "evaluation_criteria": [],
  "pricing_requirements": [],
  "legal_terms": [],
  "technical_scope": [],
  "implementation_terms": [],
  "questions_deadline": null,
  "must_not_miss": []
}

Проверка: дедлайн, формат подачи и обязательные документы видны в `rfp_queue` или `submission_checklist`.

Шаг 12. Создайте requirements_matrix

В `requirements_matrix` добавьте колонки:

requirement_id
rfp_id
source_document
source_section
requirement_text
requirement_type
priority
compliance_status
capability_id
gap_description
owner_role
answer_draft
risk_level
status
created_at

Типы требований:

functional
technical
security
legal
commercial
delivery
support
integration
document
format

Статусы соответствия:

meets
partially_meets
does_not_meet
unclear
needs_owner_review

Проверка: каждое важное требование RFP стало отдельной строкой.

Шаг 13. Разберите требования в JSON

Создайте LLM-узел `Extract requirements`.

Prompt:

Разбей RFP на отдельные требования.
Верни JSON array.
Каждый объект:
{
  "requirement_text": "",
  "requirement_type": "",
  "priority": "must|should|optional|unknown",
  "source_document": "",
  "source_section": "",
  "source_quote": ""
}

Не объединяй разные требования в одно.
Если требование неясное, все равно выдели его и пометь priority=unknown.

Проверка: таблица требований не содержит длинных абзацев “обо всем сразу”.

Шаг 14. Сопоставьте требования с capability_catalog

Для каждой строки `requirements_matrix` найдите подходящую capability.

Prompt:

Сравни требование RFP с каталогом возможностей.
Верни JSON:
{
  "compliance_status": "meets|partially_meets|does_not_meet|unclear|needs_owner_review",
  "capability_id": null,
  "gap_description": "",
  "owner_role": "",
  "answer_draft": "",
  "risk_level": "low|medium|high"
}

Не обещай возможности, которых нет в capability_catalog.

Проверка: требование, которого нет в продукте, получает `does_not_meet` или `needs_owner_review`.

Шаг 15. Рассчитайте go/no-go

Создайте простой расчет:

high risk count
must requirements not met
deadline risk
legal risk
delivery capacity
strategic fit

Статусы:

go
go_with_risks
no_go
needs_decision

Правила:

есть must does_not_meet -> needs_decision
есть high legal risk -> needs_decision
дедлайн меньше 3 рабочих дней -> needs_decision
все must meets/partially_meets и риски low/medium -> go_with_risks

Проверка: агент не заставляет команду писать КП, если есть явный no-go.

Шаг 16. Создайте question_log

В `question_log` собирайте вопросы заказчику.

Колонки:

question_id
rfp_id
requirement_id
question_text
why_needed
owner_role
status
customer_answer
created_at
answered_at

Вопросы нужны, если:

• требование неясное;
• срок непонятен;
• формат подачи не указан;
• нужна интеграция без деталей;
• есть противоречие в документах;
• цена зависит от объема;
• legal условие спорное.

Проверка: каждый вопрос объясняет, зачем он нужен для КП.

Шаг 17. Создайте approval_queue

В `approval_queue` отправляйте решения, которые нельзя принять автоматически.

Колонки:

approval_id
rfp_id
requirement_id
approval_type
question
owner_role
owner_name
risk_level
status
decision
decision_comment
created_at
closed_at

Типы approval:

price
legal_terms
delivery_scope
security
custom_development
go_no_go
case_study
discount

Проверка: цена, сроки, скидки и юридические условия не утверждаются моделью.

Шаг 18. Подготовьте proposal_sections

В `proposal_sections` храните черновики разделов КП.

Колонки:

section_id
rfp_id
section_name
source_requirements
draft_text
owner_role
status
approved_by
updated_at

Разделы:

executive_summary
understanding_of_needs
solution_overview
requirements_response
implementation_plan
team_and_roles
pricing_notes
risks_and_assumptions
case_studies
attachments

Проверка: каждый раздел КП связан с требованиями, а не написан “из воздуха”.

Шаг 19. Сгенерируйте черновик ответа по требованиям

Prompt:

Подготовь черновик ответа на требования RFP.
Используй только requirements_matrix, capability_catalog и решения approval_queue.
Не обещай то, что помечено does_not_meet.
Если статус partially_meets, явно укажи ограничение.
Если нужен review, оставь пометку [НУЖНО СОГЛАСОВАТЬ].
Стиль: деловой, конкретный, без маркетинговой воды.

Проверка: черновик не скрывает ограничения и спорные пункты.

Шаг 20. Соберите submission_checklist

В `submission_checklist` добавьте колонки:

check_id
rfp_id
item
required
owner_role
status
file_url
comment
updated_at

Первый список:

форма КП
цены
техническое описание
календарный план
анкета поставщика
security questionnaire
сертификаты
кейсы
проект договора
подпись уполномоченного лица
формат файла
способ подачи
дедлайн подачи

Проверка: перед отправкой видно, чего не хватает.

Шаг 21. Настройте route_log

В `route_log` пишите, кому ушла задача.

Колонки:

route_event_id
rfp_id
target_role
target_owner
task_type
task_text
status
created_at
closed_at

Типы задач:

answer_requirement
approve_price
review_legal
estimate_delivery
answer_security
prepare_attachment
final_review

Проверка: работа по RFP распределена по людям, а не висит в одном чате.

Шаг 22. Сформируйте финальный пакет

Когда все approvals закрыты:

1. соберите КП;
2. приложите обязательные документы;
3. проверьте формат файлов;
4. проверьте дедлайн;
5. проверьте подписи;
6. сохраните в `final_package`;
7. запишите ссылку в `rfp_queue.final_package_url`;
8. поставьте `status = ready_to_submit`.

Проверка: финальный пакет можно открыть и сверить с `submission_checklist`.

Шаг 23. Ведите audit_log

В `audit_log` добавьте колонки:

event_id
rfp_id
event_type
actor
source
details
created_at

Логируйте:

• регистрацию RFP;
• загрузку файлов;
• извлечение текста;
• разбор требований;
• срабатывание риска;
• создание вопроса;
• approval;
• изменение go/no-go;
• создание черновика;
• сбор финального пакета;
• отправку или отказ от участия.

Проверка: можно восстановить, почему команда приняла решение участвовать или отказаться.

Шаг 24. Настройте error_log

В `error_log` добавьте колонки:

error_id
rfp_id
workflow_name
node_name
error_type
error_message
input_snapshot
status
owner
created_at

Типы ошибок:

file_not_found
unsupported_format
extraction_failed
llm_json_invalid
requirements_empty
capability_not_found
approval_owner_missing
deadline_missing
package_incomplete
notification_failed

Проверка: если workflow сломался, понятно, что чинить и кто владелец.

Шаг 25. Создайте test_cases

В `test_cases` добавьте тестовые пакеты.

Колонки:

test_id
rfp_package_url
expected_request_type
expected_go_no_go
expected_required_documents
expected_high_risks
expected_questions_count
last_run_at
last_result

Первый набор:

simple_rfp
rfq_price_only
security_questionnaire
rfp_with_contract_risk
rfp_with_missing_deadline
rfp_with_unmet_must_requirement
large_pdf_rfp
xlsx_requirements_table
email_cp_request
zip_package

Проверка: изменение prompt не ломает базовое извлечение требований и go/no-go.

Шаг 26. Прогоните полный путь на одном RFP

Порядок:

1. загрузите пакет в `rfp_inbox`;
2. проверьте строку в `rfp_queue`;
3. проверьте `rfp_documents`;
4. проверьте извлеченный текст;
5. проверьте тип запроса;
6. проверьте `requirements_matrix`;
7. проверьте `question_log`;
8. закройте один approval;
9. сформируйте черновик в `proposal_sections`;
10. заполните `submission_checklist`;
11. соберите `final_package`;
12. проверьте `audit_log`.

Проверка: от входящего пакета до готового черновика КП команда не копирует требования вручную.

Минимальная проверка результата

Прототип работает, если выполняются все пункты:

• RFP-пакет создает строку в `rfp_queue`;
• все файлы попадают в `rfp_documents`;
• текст и таблицы извлекаются;
• тип запроса определяется;
• требования попадают в `requirements_matrix`;
• соответствие проверяется по `capability_catalog`;
• риски создают approval;
• вопросы заказчику попадают в `question_log`;
• черновики разделов сохраняются в `proposal_sections`;
• финальная комплектность проверяется через `submission_checklist`;
• задачи распределяются через `route_log`;
• вся история пишется в `audit_log`;
• ошибки пишутся в `error_log`;
• тестовые RFP проходят после изменения prompt.

Что нельзя автоматизировать в первой версии

• отправку финального КП заказчику;
• изменение цены и скидок;
• юридическое принятие условий;
• обещание сроков внедрения без delivery;
• подписание документов;
• генерацию несуществующих кейсов, сертификатов и возможностей;
• скрытие ограничений продукта;
• участие в RFP с high-risk условиями без go/no-go;
• загрузку документов на тендерный портал без человека.

Частые вопросы

Чем RFP-агент отличается от агента для обычного КП?

RFP-агент сначала разбирает требования, риски, формат подачи, обязательные документы и критерии оценки. Обычное КП часто можно собрать из потребности клиента, а RFP требует строгой матрицы соответствия и контроля комплектности.

Можно ли сразу подключить PandaDoc или Docusign?

Можно, но в первой версии лучше использовать их только после approval: подготовить документ, пакет или envelope. Отправка и подпись должны оставаться ручным действием.

Как не пообещать лишнего в КП?

Свяжите каждый ответ с `capability_catalog`. Если возможности нет или она частичная, агент обязан поставить `partially_meets`, `does_not_meet` или `[НУЖНО СОГЛАСОВАТЬ]`.

Что делать, если RFP содержит противоречивые требования?

Записать вопрос в `question_log` и отправить владельцу. Агент не должен сам выбирать удобную трактовку, если от нее зависят цена, сроки или юридические обязательства.

Какой минимум нужен для запуска?

`rfp_queue`, `rfp_documents`, `requirements_matrix`, `capability_catalog`, `risk_rules`, `question_log`, `approval_queue`, `proposal_sections`, `submission_checklist`, `audit_log`, `error_log` и 5 тестовых RFP.