> For the complete documentation index, see [llms.txt](https://docs.stackai.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stackai.com/getting-started/learning/stackai-building-challenges/5.-analyze-an-rfp.md).

# 5. Analyze an RFP

## Challenge overview

Build a chatbot for analyzing one RFP at a time.

The user uploads an RFP, provides an 8-digit internal ID, and then asks follow-up questions grounded in that document.

### Scenario

> Our team receives a high volume of RFPs and needs a faster way to understand and evaluate them.
>
> We need a chatbot that allows a user to upload a single RFP document and interact with it conversationally.
>
> At the start of each conversation, the user should upload one RFP and provide an internal RFP ID number (an 8-digit number such as 12345678).
>
> The chatbot should automatically run an initial analysis of the document and extract key information, including the scope of work, project context, submission requirements and timeline, evaluation criteria, and contract terms or risk factors.
>
> The chat conversation should also be renamed to the provided RFP ID so it can be easily identified in the chat interface.
>
> After this initial analysis, the user should be able to ask follow-up questions about the RFP and receive answers grounded in the document with clear citations.

### Sample files

{% file src="/files/Z0IVkU2C3ju8BX6N8nIf" %}

{% file src="/files/ijgRvM8ug8IE5P6XMv9P" %}

{% file src="/files/ckYJj1SgtoLpdRRnFJJ7" %}

### Required inputs

{% hint style="info" %}
The workflow must validate two conditions before analysis starts:

* Exactly one RFP document has been uploaded.
* A valid 8-digit RFP ID has been provided.
  {% endhint %}

### Initial analysis requirements

Extract at least:

* Scope of work
* Project context
* Submission requirements and timeline
* Evaluation criteria
* Contract terms or risk factors

### Required interaction patterns

Your workflow should handle these cases:

1. One RFP + valid ID → run analysis
2. Not exactly one RFP + missing or invalid ID → ask for both
3. One RFP only → ask for ID → then run analysis
4. Valid ID only → ask for RFP → then run analysis

The workflow must accept inputs in any order.

### What to build

Your workflow should:

1. Accept chat input and file uploads.
2. Validate that one active RFP is present.
3. Validate that the ID is exactly eight digits.
4. Pause and request whatever is missing.
5. Run the initial RFP analysis.
6. Rename the conversation to the RFP ID.
7. Answer follow-up questions with citations.

### Key considerations

{% hint style="info" %}

* Distinguish the initial setup step from later chat turns.
* Decide how to persist both text and file inputs across the conversation.
* Handle validation failures with clear instructions.
* Keep follow-up answers grounded in the active document.
  {% endhint %}

### Extension

#### Improve the chat interface

Make the interface description explicit about the required inputs.

Use two left-aligned bullets:

* Upload exactly one RFP document
* Provide an 8-digit RFP ID

#### Support document replacement

If a new RFP is uploaded later in the same conversation:

* Re-run analysis on the newest RFP
* Keep using the existing RFP ID
* Keep the conversation title unchanged
* Treat the newest uploaded RFP as the active document

### Helpful docs

* [Files Node](/workflow-builder/inputs/files-node.md)
* [Chat Assistant](/interface-and-deployment/end-user-interfaces/chat-assistant.md)
* [Detecting the First Run](/guides-and-tips/stackai-hacks/detecting-the-first-run.md)
* [Knowledge Bases](/workflow-builder/core-nodes/knowledge-bases.md)
* [Handling Errors & Fallback](/guides-and-tips/stackai-hacks/handling-errors-and-fallback.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.stackai.com/getting-started/learning/stackai-building-challenges/5.-analyze-an-rfp.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.