An RFP response presentation should let an evaluator trace a requirement to your answer, evidence, and delivery commitment. Keep the buyer’s requirement IDs, distinguish “met” from “partly met” and “not met,” and explain any exception before the evaluator discovers it. A deck that makes comparison easy is more persuasive than a list of broad capabilities.
For this walkthrough, imagine a retailer asking for a support platform. The requirement excerpts and supplier answers are invented to demonstrate the method; they are not claims about Presenti or another product.
After the response team has agreed on those answers, Presenti can help arrange the sales brief into an editable presentation. Keep the requirement IDs and evidence references in the input so the deck follows the buyer’s evaluation path.
Begin with the buyer’s words, not your feature names
Copy the requirement ID and exact text into a working matrix. Do not rename “export audit events as CSV” to “advanced insights” or merge it with unrelated reporting features. Keep the response format, evaluation criteria, demonstration instructions, and deadline alongside the matrix. These are inputs to the presentation, not background reading. To see the decision from the other side of the table, the supplier evaluation presentation compares criteria, supporting evidence and unresolved gaps from the buyer’s perspective.
The sample retailer’s four requirements are:
| ID | RFP excerpt | Question to resolve before writing slides |
|---|---|---|
| REQ-01 | Forty agents must be able to work in a shared queue. | Which workspace and permission model will be demonstrated? |
| REQ-02 | Administrators must export audit events as CSV. | Which events and fields are included? |
| REQ-03 | Provide 24/7 telephone support. | Is this available under the proposed contract? |
| REQ-04 | Complete a six-week pilot using customer sample data. | What does “complete” mean, and who supplies the inputs? |
Write statuses that match the actual offer
The fictional supplier has a shared queue, exports some audit events, offers business-hours telephone support, and can propose a pilot if the retailer supplies sample data and reviewers. Its response should therefore look like this:
| ID | Status | Answer | Evidence or next action |
|---|---|---|---|
| REQ-01 | Met | Shared queue available for the proposed users and roles | E-01: dated demo of agent and supervisor access |
| REQ-02 | Partly met | CSV export includes login and record-change events; configuration changes are not included | E-02: sample export and field list; ask whether the missing events are mandatory |
| REQ-03 | Not met | The proposed offer has business-hours telephone support, not 24/7 coverage | State the gap; request discussion of an acceptable alternative |
| REQ-04 | Proposed | Six-week pilot plan, dependent on customer data and reviewer availability | E-03: plan with entry conditions and acceptance steps |
Do not turn REQ-02 into “met” by saying that the product has audit capabilities. Do not answer REQ-03 with a customer-success contact and imply that it is the requested support coverage. If a mandatory requirement is unmet, surface that on the summary slide as well as in the matrix.
Show one proof moment per important answer
For REQ-01, show the agent finding a ticket and the supervisor seeing the permitted queue. For REQ-02, show the export file’s column headers and an example row with synthetic data. The viewer should be able to relate the proof to the requirement without hearing a second sales pitch.
Give evidence references stable labels: E-01, E-02, and E-03 in this example. Include the document version or demo date, owner, and relevant condition. A slide can point to “E-02, sample export, fields 1–8” while the full file lives in the proposal package. Client logos and testimonial quotes do not substitute for proof of a specific requirement.
Make the pilot conditional in specific ways
A six-week bar across a timeline hides the work that can stop delivery. Break the fictional pilot into preparation, use-case testing, and acceptance. Preparation requires sample data, user roles, and a named customer reviewer. Testing runs the agreed agent journeys and export checks. Acceptance records which criteria passed, failed, or need another test.
Use an entry condition such as: “The pilot clock begins when sample data, test accounts, and reviewer dates are available.” The real RFP or contract may specify a different rule, so do not add this wording unilaterally. Put any proposed condition in the response for the buyer to accept or reject.
A deck order that keeps exceptions in view
- Response summary: buyer objective, proposed approach, and the mandatory gap.
- Requirement map: IDs, status, and where to find each answer.
- Shared-queue proof: REQ-01 and E-01.
- Audit-export boundary: REQ-02, E-02, and the missing events.
- Support exception: REQ-03 and the alternative to discuss.
- Pilot: REQ-04, responsibilities, entry conditions, and acceptance.
- Buyer questions: whether the partial match and support alternative are acceptable, plus who will confirm them.
The presentation and written proposal should use the same answer, scope, and commercial terms. If the slide simplifies a point, keep the reference to the fuller answer. Do not use a friendly live explanation to make an offer that the submitted documents do not contain.
Build the response deck in Presenti from the completed matrix. Keep the exceptions in the story; removing them may make the deck shorter, but it makes the buyer’s decision harder.
