Prepare the source pack
Choose the proposal kind and supply the buyer brief, approved evidence, delivery assumptions and commercial terms. For RFP work, retain the issued requirements and separate known answers from missing evidence.
An RFP is not just a prompt. Treat it as the control document for the proposal: map the requirements, add your approved source material, draft against the buyer's structure, and review every important claim before export.
To turn RFP documents into a proposal: upload the RFP (PDF or DOCX) with all attachments and addenda, add supporting context like past proposals and case studies, build a requirement map from the buyer's sections and evaluation criteria, draft the response against that map, then review coverage — marking each requirement answered, partial, or missing — before exporting as a formatted PDF or DOCX. This treats the RFP as the control document rather than a one-line prompt, so the buyer's structure and terminology shape the output instead of a generic sales proposal.
Read a real exported proposal alongside the brief Arc received. The example keeps supplied scope, commercial assumptions and reviewer responsibility visible.
A response to a council's request for proposals, written for an invented bidder: a cover letter, an executive summary, an answer to each of the ten mandatory and three desirable requirements, the team, two local-authority references, and a price built from the bidder's day rates and unit rates, with every line showing its days or units.
Respond to Marlow Borough Council's request for proposals RFP 2026-14 on behalf of Larkfield Analytics Ltd. Answer each mandatory requirement R1 to R10 and each desirable requirement D1 to D3 in turn, using the supplied evidence file for the company, delivery team, past performance, rates, assurance and declarations. Then add a short section that shows where the response answers each evaluation criterion (method, delivery team, past performance, data protection and security) and price. Build every price line from the standard rates in the evidence file (the days of each role times the day rate, or the units times the unit rate) and show the days or units behind each line. Add nothing the evidence file does not state, and do not refer to appendices or attachments that the response does not contain. Put a notice on the cover page that the buyer and the bidder are fictional and the response is a worked example. Inputs: the buyer's document (rfp-marlow-council.md); the bidder's evidence file (larkfield-evidence.md); commercial terms: value 296,000 to 318,000 GBP, valid for 60 days, payment terms 'Invoiced monthly in arrears, payable within 30 days.'; deal context: The buyer and the bidder in this response are fictional, and this response is a worked example. The response is for a 24-month contract with an option to extend for 12 months, within the buyer's budget ceiling of 330,000 pounds excluding VAT.
A separate reviewer agent read its 150 claims against the bidder's evidence file, the council's RFP and the deal terms: 132 are supported, 16 go a little beyond an input, 2 are in no input (it calls the price fixed, and it cites a 1,950-word limit nobody set) and none contradicts one. Every price line recomputes. It is not a person's review.
Choose the proposal kind and supply the buyer brief, approved evidence, delivery assumptions and commercial terms. For RFP work, retain the issued requirements and separate known answers from missing evidence.
Inspect scope, exclusions, requirements and price assumptions. Use reviewable edits and saved comparisons; an unresolved buyer question needs an owner or an explicit qualification.
Inspect the actual PDF, Word or HTML output. Tracked delivery activity and a recorded deal outcome answer different questions; verify the recipient, permissions and current approval state before sharing.
Keep buyer RFP files separate from bidder evidence and approved reusable answers. Inspect extraction coverage, requirement source locations, questionnaire previews and submission limits. Response work can carry an SME owner, due date, escalation owner and required reviewer decisions. Compare an addendum with the source before changing a response.
Review each line's quantity, rate, unit, optional status and one-off, monthly or annual recurrence. Inspect recurrence totals and the estimated first-year total separately. Currency, supplied tax input and commercial assumptions need review. When importing Business metrics, select and review the source values before applying them to the schedule.
Choose the current saved response or an approved edition. Inspect retained attachments, filled questionnaires, the compliance matrix and the package preview. A release manifest identifies stored delivery bytes. For tracked links, review recipient access, expiry, password and permissions separately from delivery activity and the recorded opportunity outcome.
A draft or readiness check is not approval of pricing, legal terms or a delivery commitment. Arc proposal drafting does not imply CRM, CPQ or tax-calculation automation.
Choose the proposal type, add the RFP, brief, notes, or prior work, then review a structured first draft before it reaches a client.
The document conversion workflow. Gixo helps turn the RFP and supporting files into a first draft, while your team checks coverage, pricing, claims, and submission fit.
Upload the RFP Document
Upload your RFP as PDF or DOCX. Include any attachments, addenda, or supplementary materials that contain scope details or evaluation criteria.
Add Supporting Context
Upload past proposals, capability statements, case studies, or team bios. These files give the AI concrete details to weave into your response rather than generating generic content.
Build the requirement map
Select the RFP Response proposal type, then use the buyer's sections, obligation language, evaluation criteria, and submission instructions as the response map.
Review coverage and edit
Walk through the draft section by section. Confirm that mandatory requirements, proof points, pricing assumptions, exclusions, and commitments are supported by the RFP and your source files.
Export and Submit
Export as a formatted PDF or DOCX. The output preserves your structure, headings, and professional formatting for direct submission.
| Step | What you do | Why it matters |
|---|---|---|
| 1. Upload the RFP document | Upload as PDF or DOCX, including attachments and addenda | Scope details and evaluation criteria often live in supplementary files |
| 2. Add supporting context | Upload past proposals, capability statements, case studies, team bios | Gives concrete details to draw from instead of generic content |
| 3. Build the requirement map | Select the RFP Response proposal type; use the buyer's sections, obligation language, evaluation criteria, and submission instructions | The map becomes the coverage checklist for the whole response |
| 4. Review coverage and edit | Walk through the draft section by section against the map | Confirms mandatory requirements, proof points, pricing, exclusions, and commitments are supported |
| 5. Export and submit | Export as formatted PDF or DOCX | Preserves structure, headings, and formatting for direct submission |
A strong RFP-to-proposal workflow preserves the buyer's structure instead of forcing the document into a generic sales proposal.
| RFP signal | How it should shape the proposal |
|---|---|
| Mandatory requirements | Become coverage rows your team can mark as answered, partial, or missing. |
| Evaluation criteria | Determine where the proposal needs the strongest proof, detail, and reviewer attention. |
| Submission instructions | Control format, deadline, attachments, signatures, page limits, and delivery method. |
| Scope and assumptions | Shape the solution narrative, pricing model, exclusions, and implementation plan. |
| Buyer terminology | Keeps the response aligned with how the evaluator describes the problem. |
Add the buyer's RFP addendum with the Buyer addendum source role, keeping the earlier request and its revision context available for comparison. Arc can compare extracted requirements from retained earlier and later sources and show new, changed or removed requirements and affected answers.
Inspect each change against the issued documents. Existing authored answers are preserved while affected responses can be flagged for review; Arc does not silently rewrite your commitments. Review the answer, owner, evidence, deadline and required attachments, then save and complete the current-revision checks before creating a release.
Requirement matching uses extracted numbering and text. Unread ranges, extraction limits and differently expressed changes can leave gaps, so this is a review aid rather than an exhaustive document diff. Addenda are supplied by the team; Arc does not monitor a procurement portal for them.
Does Gixo help parse the RFP content?
Yes. Arc uses the uploaded RFP document to identify sections, requirements, evaluation criteria, and submission instructions. Your team should still review the map before relying on it for a final response.
What if my RFP has multiple attachments?
Upload all relevant attachments alongside the main RFP document. The AI processes all uploaded files as context, so addenda, appendices, and supplementary materials are all factored into the generated response.
Can I reuse parts of past proposals?
Upload previous proposals as source files. The AI draws from that content -- methodology descriptions, team qualifications, case studies -- and adapts it to fit the new RFP's requirements and structure.
How should I verify requirement coverage?
Compare the draft against the RFP requirement map, then mark each item as answered, partially answered, or missing. Use the proposal analyzer for an extra mechanical coverage pass before submission.
What proposal sections does the AI generate?
Typical sections include executive summary, understanding of requirements, technical approach, methodology, qualifications, timeline, pricing, and terms. The exact structure adapts based on the RFP's requirements.
How do I turn RFP documents into a proposal?
Upload the RFP as PDF or DOCX with all attachments and addenda, add supporting context such as past proposals and case studies, build a requirement map from the buyer's sections and evaluation criteria, draft the response against that map, review coverage by marking each requirement answered, partial, or missing, then export as a formatted PDF or DOCX for submission.
What sections does a proposal built from an RFP typically include?
Typical sections include executive summary, understanding of requirements, technical approach, methodology, qualifications, timeline, pricing, and terms. The exact structure adapts based on the RFP's requirements.
Upload the RFP, add your source material, draft against the requirement map, and check coverage before export.
Convert RFP to ProposalUpdated