Most RFP templates in circulation were downloaded from the internet and used without modification. You can tell. They have the right headings, a placeholder or two, and almost no guidance on what should actually go inside each section. Vendors fill them in inconsistently. Evaluators compare responses that aren't comparable. The process drags. Decisions get made on gut feel anyway.

This post is a section-by-section walkthrough of a complete enterprise RFP — what each section must contain, what to avoid, and concrete examples of language that works versus language that wastes everyone's time. Use it as a working reference, not a ceremonial checklist.

What it must contain:

• RFP title and a unique reference number
• Issuing organization name and department
• Issue date and proposal due date (with time zone)
• Submission method (email, portal, physical address) and format requirements
• Primary point of contact for questions, with a deadline for submitting questions
• A clear statement that late submissions will not be accepted

What to avoid: Burying submission instructions in the body of the document. If vendors miss the deadline because they couldn't find the due date, that is a process failure, not a vendor failure.

What it must contain:

• A two-to-four paragraph overview of why the RFP is being issued
• The business problem or opportunity driving the procurement
• The approximate scale of the engagement (budget range, contract term, number of users/locations)
• What a successful outcome looks like in plain language

What to avoid: Treating this as a formality. Vendors use the executive summary to decide whether to respond. A vague summary produces vague proposals. A specific summary attracts vendors who understand the problem.

What it must contain:

• Company size (revenue, headcount, or both)
• Industry and relevant regulatory environment
• Relevant technology stack and existing vendor relationships
• Organizational structure as it relates to this procurement (who will use the solution, who will own it)
• Any known constraints: data residency requirements, security certifications required, procurement policies

What to avoid: A generic "About Us" paragraph copied from the company website. Vendors need operational context, not marketing copy.

This is the most important section in the document. It is also the most commonly mishandled.

What it must contain:

• A clear description of what the vendor is being asked to deliver
• Functional requirements, separated from technical requirements
• Non-functional requirements (performance, availability, security, scalability)
• Integration requirements with named systems
• A clear distinction between mandatory requirements (must-have) and preferred requirements (nice-to-have)
• Any out-of-scope items that vendors might otherwise assume are included

What to avoid: Requirement lists that mix priorities without labeling them. If everything is listed equally, vendors cannot make trade-offs and evaluators cannot score meaningfully. Avoid vague verbs like "support," "enable," and "facilitate" without defining what they mean in practice.

Structure recommendation: Use a numbered requirements table with three columns — Requirement ID, Requirement Description, and Priority (Required / Preferred). This forces clarity and makes evaluation tractable.

What it must contain:

• Every criterion that will be used to score proposals
• The relative weight of each criterion, expressed as a percentage
• A brief description of what "good" looks like for each criterion
• Whether price is scored as part of the evaluation or handled separately

What to avoid: Publishing criteria without weights. Unweighted criteria signal that the evaluation is not structured, which erodes vendor trust and invites challenges to the outcome. Avoid criteria so broad they cannot be scored consistently ("overall fit," "cultural alignment").

Common weighting structure for enterprise software:

What it must contain:

• Exact structure vendors must follow (section numbers, section names, order)
• Page or word limits per section, if applicable
• File format requirements (PDF, Word, Excel for pricing)
• Font, margin, and page numbering requirements if you need them
• Instructions for labeling confidential or proprietary content

What to avoid: Leaving format open-ended. When vendors structure responses differently, evaluators spend time reformatting rather than evaluating. Inconsistent formats also make it easier for a well-formatted weak proposal to outperform a poorly formatted strong one.

What it must contain:

• Required certifications or compliance documentation (SOC 2, ISO 27001, etc.)
• Financial stability documentation (audited financials, D&B report)
• Client references — number required, recency, and relevance criteria
• Subcontractor disclosure requirements
• Signature and authorization requirements
• Any required forms (conflict of interest, non-disclosure, insurance certificates)

What to avoid: Asking for documentation you will not review. If you request three years of audited financials but only look at the most recent year, remove the requirement. Unnecessary requirements increase vendor burden and signal process theater.

What it must contain:

• Preferred contract structure (SaaS subscription, time-and-materials, fixed fee, etc.)
• Contract term and renewal options
• Payment terms
• Key contractual requirements: SLA minimums, data ownership, termination for convenience, liability caps
• Pricing format instructions — what line items to break out, whether multi-year pricing is required
• Whether the issuing organization's standard terms will govern or whether vendor paper is acceptable

What to avoid: Leaving commercial terms entirely to negotiation. Publishing your baseline expectations reduces late-stage surprises and lets vendors self-select out if your terms are incompatible with their model.

What it must contain:

• All key dates: RFP issue, questions deadline, answers published, proposals due, shortlist notification, demos/orals, final selection, contract execution target
• Whether a shortlist will be created and approximately how many vendors will advance
• Whether an oral presentation or product demonstration is required
• How and when vendors will be notified of the outcome (including unsuccessful vendors)
• The right to cancel or modify the RFP

What to avoid: Timelines with no buffer. Build in at least three business days between the Q&A response publication and the proposal deadline. Vendors cannot finalize proposals until they have answers to their questions.

What it must contain (as applicable):

• Appendix A: Required response structure / table of contents template
• Appendix B: Pricing workbook template (Excel)
• Appendix C: Current-state environment details (data volumes, integration inventory, user counts by role)
• Appendix D: Glossary of terms used in the RFP
• Appendix E: Required forms (NDA, conflict of interest declaration, insurance requirements)
• Appendix F: Sample contract or standard terms and conditions

What to avoid: Appendices that duplicate body content. Each appendix should contain material that would interrupt the flow of the main document if embedded inline — reference data, forms, and templates.

Before sending the RFP, answer these twelve questions. Any "no" is a reason to revise before release.

1. Does every requirement have a priority label (Required or Preferred)?
2. Are all evaluation criteria published with numeric weights that sum to 100%?
3. Is the submission deadline specific — date, time, and time zone?
4. Is there a named point of contact and a deadline for submitting questions?
5. Does the required response format specify section order, page limits, and file format?
6. Have you removed or resolved any requirements that are internally contradictory?
7. Is the budget range or contract value disclosed, even as a range?
8. Are the commercial baseline terms (SLA, payment, data ownership) stated explicitly?
9. Does the timeline include a gap of at least three business days between Q&A publication and proposal due date?
10. Have you confirmed that every piece of documentation you are requesting will actually be reviewed?
11. Is there a clear statement of how and when unsuccessful vendors will be notified?
12. Has legal or compliance reviewed the document before release?

If you can answer yes to all twelve, the RFP is ready to issue.

A well-structured RFP template is one part of a larger sourcing process. For related guidance:

• Not sure whether you need an RFP at all? Start with RFP vs. RFI vs. RFQ to choose the right instrument for your situation.
• If you are drafting from scratch rather than adapting a template, How to Write an RFP covers the process end to end.
• For a deeper treatment of how to define and weight criteria before you issue, see RFP Evaluation Criteria.
• Once proposals are in, How to Score RFP Responses walks through building a defensible, consistent scoring process.