Answer an RFP with business context

Workflow Map

The workflow has three lanes. Keeping them separate prevents the LLM from treating an old proposal, a generic offer, or a reference architecture as if it were the current customer requirement.

Where to Put Each File

Use these snapshots as the placement rule before uploading. If a document describes this live RFP, it belongs in the active client project. If it should help many future RFPs, it belongs in Workspace Context.

One-Time Company Setup

Do this before the first RFP arrives. The goal is to make company knowledge reusable so the team does not rebuild the same proposal context for every client.

When a New RFP Arrives

Each RFP should become an active client project. The project is the source of truth for that opportunity; workspace Business Context is the reusable library around it.

Technical Diagrams and Schemas

Technical diagrams are first-class context. Upload them as project context when they describe the current client or incoming RFP, and as Business Context only when they are reusable reference material.

Source Priority for the LLM

Put this policy in the Business Response Playbook and repeat it in your RFP prompt. This keeps proposal drafts grounded when templates and current client sources disagree.

Example MCP Sequence

The dashboard can perform the same workflow visually. Integrators, companion scripts, and advanced users can automate it through MCP.

Create the active project

await callSniparaTool("rlm_create_client_project", {
  name: "ACME ERP Integration RFP",
  slug: "acme-erp-integration-rfp",
  project_mode: "active_client",
  external_client_id: "acme"
});

Sync the RFP and current diagrams

await callSniparaTool("rlm_sync_documents", {
  documents: [
    {
      path: "clients/acme/current/rfp.md",
      content: "# ACME RFP\n...",
      kind: "DOC",
      format: "md",
      metadata: {
        assetClass: "BUSINESS_DOCUMENT",
        usageMode: "current_truth",
        clientId: "acme",
        sourceKind: "sharepoint",
        sourcePath: "Sales/2026/ACME/RFP.docx",
        sourceModifiedAt: "2026-04-28T09:00:00Z",
        sourceSnapshotAt: "2026-04-28T09:15:00Z"
      }
    },
    {
      path: "clients/acme/current/diagrams/target-architecture.vsdx",
      content: "base64:<payload>",
      kind: "BINARY",
      format: "vsdx",
      metadata: {
        assetClass: "DIAGRAM",
        usageMode: "current_truth",
        clientId: "acme",
        sourceKind: "sharepoint",
        sourcePath: "Sales/2026/ACME/Architecture.vsdx",
        sourceSnapshotAt: "2026-04-28T09:15:00Z"
      }
    }
  ],
  reindex: true
});

Prompt Your LLM Should Use

Use this prompt from Claude Code, Cursor, ChatGPT with MCP, or any MCP-compatible client after the RFP and diagrams are indexed.

We need to respond to the ACME ERP Integration RFP.

Use Snipara before drafting.

Load and compare:
1. The Business Response Playbook.
2. The active ACME project context.
3. The current RFP and annexes.
4. The current technical diagrams and architecture schemas.
5. Offer Templates.
6. Business Library and Company Presentations.
7. Reference Diagrams and similar past projects.

Rules:
- Current RFP and active client context override templates.
- Current technical diagrams override reference diagrams.
- Cite the source path for every important requirement, assumption, risk, and claim.
- If sources conflict, stop and list the conflict.
- Do not invent pricing, compliance claims, certifications, integrations, or delivery capacity.
- Start with analysis, not final prose.

Produce:
1. Compliance matrix: requirement, answer, evidence, gap, owner.
2. Missing questions for the client.
3. Assumptions and exclusions.
4. Technical feasibility notes based on the diagrams.
5. Risks and dependencies.
6. Proposed solution outline.
7. Delivery plan and responsibilities.
8. Draft response sections ready for human review.

Recommended Output Order

For high-stakes proposals, do not ask the LLM for the final document first. Ask for these outputs in order so humans can catch missing context early.

1. Source inventory and context health summary.
2. Compliance matrix against the RFP.
3. Technical diagram interpretation and architecture fit.
4. Clarifying questions and missing source list.
5. Assumptions, exclusions, risks, and dependencies.
6. Solution narrative and delivery plan.
7. Executive summary and final proposal language.

After Submission

Once the response is reviewed or submitted, decide what should become durable memory. Good candidates are approved positioning, reusable risk language, client-specific decisions, and validated diagram interpretations. Keep rejected assumptions, private pricing, and temporary negotiation details out of durable memory unless your policy explicitly requires them.