Picture the person scoring your proposal. They have a spreadsheet with the RFP’s requirements down the left, a column for scores, several proposals to get through, and a deadline. For each requirement they need to find your answer, decide whether it meets the need, and write a score they can defend if another bidder challenges the result.
If your answer to requirement FR-012 is buried on page 47 inside a section called “Our Innovative Platform”, you are relying on a tired evaluator to go looking. Many will not. The point is not lost because the solution is weak. It is lost because nobody could find the evidence.
This part is about making the point easy to award, and about the discipline that sits underneath: being exact about what you are claiming, what you are assuming and what you are promising.
We are following one fictional pursuit throughout this series. Rivermark Water and Ridgeline Digital are fictional, and all figures are illustrative. Rivermark wants a customer self-service and case management platform; Ridgeline is bidding with a teaming partner and, in Part 3, learned that Rivermark’s billing system has no API for writing data.
Use the client’s structure, not yours
Rivermark’s RFP numbers its requirements. Functional requirements, describing what the system must do, start with FR. Non-functional requirements, describing how well it must do it, start with NFR. For example:
- FR-012 Customers can report a fault and receive a reference number.
- FR-031 Customers can see the status of their fault.
- NFR-004 The service is available 99.5% of each month.
Ridgeline’s response uses exactly those numbers, in exactly that order, in the response format the RFP specifies. Where the story needs explaining at more length, the answer to FR-012 states the response in one line and points to the section with the detail. The evaluator never has to search.
Most RFPs ask bidders to state compliance for each requirement using fixed terms. The usual ones are comply (fully met as asked), partially comply (met with a stated limitation), do not comply, and sometimes alternative proposed (met in a different way, with an explanation). Be honest here. A “comply” that turns out to be partial damages trust in every other answer, and in a contract it becomes a promise.
Four kinds of statement
Every sentence in a proposal is one of four things, and mixing them up is where many disputes begin.
| Statement | What it means | Rivermark example |
|---|---|---|
| Fact | Supported by an authoritative source | The billing system has no write API (written clarification answer) |
| Assumption | Needed because material information is missing | Storm-week fault reports stay under 30,000 |
| Recommendation | The bidder’s proposed decision | Read balances through the read-only views rather than the nightly export |
| Commitment | A promise that becomes contractual if accepted | Fault reporting and status live before 1 July, subject to the stated assumptions |
The rule is simple. Never present a recommendation as a client fact, and never present an assumption as an unconditional commitment. “Rivermark’s billing views support real-time queries” is a fact claim. If Ridgeline only believes it, the sentence must say so.
The traceability matrix
A traceability matrix is a table that links each requirement to everything that answers it. Think of it as the thread that connects what the client asked for to what will be designed, built and tested.
| Req ID | Requirement | Response | Evidence | Solution element | Delivery item | Acceptance | Status |
|---|---|---|---|---|---|---|---|
| FR-012 | Report a fault and receive a reference number | Comply | Section 5.2 | Case management, portal, WhatsApp channel | WP-03 | UAT-07 | Confirmed |
| FR-031 | See the status of a fault | Comply | Section 5.3 | Case management, notifications, portal | WP-03 | UAT-09 | Confirmed |
| NFR-004 | 99.5% monthly availability | Partially comply | Section 7.1 | Platform, monitoring | WP-02 | NFR-T02 | Open: billing dependency |
A few terms in the headings. A work package (WP) is a defined chunk of delivery work with its own outcome, covered properly in Part 10. UAT is user acceptance testing: the tests the client runs to confirm the work does what was agreed. Acceptance is the evidence that lets the client sign off.
The matrix does two jobs. For the evaluator, it proves coverage. For the bid team, it exposes two classic gaps:
- A requirement with no solution coverage. When Ridgeline built its matrix, FR-044, a monthly complaints report for Rivermark’s board, had no reporting component and no work package. It had simply been overlooked. Given the audit finding about complaints tracking, that was a point Rivermark cared about.
- A component with no requirement. Ridgeline’s first architecture diagram included a chatbot. No requirement asked for one. It added cost and risk and could earn no points, so it moved to an optional section with its own price.
Notice NFR-004. Ridgeline marked it “partially comply” with a clear reason: the platform can be engineered for 99.5%, but customers checking a balance also depend on Rivermark’s old billing system, which Ridgeline does not control. Being open about it in the matrix is far better than committing to a number that someone else’s system can break. (The first draft did not say this, and Part 12 shows who caught it.)
Strong assumptions
Assumptions are not a sign of weakness. Every proposal needs them, because no bidder knows everything at submission. What matters is how they are written.
A useful assumption has six qualities:
- Necessary. It is there because something material is unknown, not to shift risk for the sake of it.
- Specific. It names the system, the data, the people or the quantity.
- Observable. Anyone can tell whether it turned out to be true.
- Owned. It says who must act.
- Bounded. It promises no more than it has to.
- Paired with its impact. It says what changes if it proves false.
Here is the weak version most proposals contain:
Rivermark will provide all required access.
It cannot be tested, nobody owns it, and when access is late the argument about what “required” meant has already begun. Here is the version Ridgeline wrote:
Rivermark will provide read-only access to the billing system’s customer and balance views for two named Ridgeline engineers by the end of week 4 of discovery. If access is more than five working days late, integration testing and the Bridge 1 go-live date move by the same amount. Production access follows Rivermark’s privileged-access process.
(Bridge 1 is the first stage of the transition plan, when fault reporting moves onto the new platform. Part 9 explains the bridge states.)
The strong version is also fairer to the client. It tells Rivermark exactly what to prepare and when, so a delay becomes a planning conversation rather than a surprise.
Never assume silently
Some assumptions are too important to leave buried in a list at the back. If any of the following are uncertain, they belong in the main response, the risk register and the price explanation:
- Compliance, such as what POPIA obliges each party to do.
- Data geography: where data is stored, processed, backed up and supported from. For Rivermark, where WhatsApp message data is processed.
- Recovery: what happens, and how fast, after a failure.
- API readiness: whether an interface really exists and does what is needed.
- Data quality: whether the data is clean enough to migrate or rely on.
- Volume: how much, how often and at what peak.
- Licences: who buys them, how many and for how long.
- Funding: whether the budget is approved.
- Support ownership: who supports what after launch.
- Third-party costs, such as SMS and WhatsApp message fees.
- Approvals and acceptance: who signs off and on what evidence.
Each item on that list is a place where a silent assumption later becomes a dispute. An assumption that changes the price, the date or who carries the risk should be visible to the person approving the bid, not only to the person who wrote page 83.
Exclusions and client responsibilities
Exclusions clarify where the offer stops. They should not hollow it out. Ridgeline excluded the replacement of the billing system, which the RFP itself placed out of scope, and the redesign of Rivermark’s tariff structure. It did not exclude testing, security monitoring or data migration of open tickets, because a platform without them cannot be run safely, however low the headline price looks.
Client responsibilities are the things the client must do for delivery to succeed. For Rivermark they included providing subject matter experts for workshops, test data with personal information masked, timely access, approval of customer-facing content, and a named service owner. These belong in the delivery schedule and the risk model, with dates, not only in small print. A responsibility nobody has scheduled is a delay waiting to happen.
What to take from this part
Answer in the client’s structure and numbering. An evaluator cannot award a point they cannot find.
Know which kind of statement you are making. Facts, assumptions, recommendations and commitments must never be blurred.
Build a traceability matrix and read it both ways. It finds requirements with no coverage and components with no requirement.
Write assumptions that are specific, owned and paired with their impact. “All required access” is not an assumption; it is a future argument.
Put material assumptions and client responsibilities where decision-makers will see them. Not in the small print.
Next in the series: Features are not reasons: win themes, value and proof.
How CloudNala can help
We build and check traceability matrices with bid teams, reading them in both directions to find uncovered requirements and unrequested components, and we rewrite the assumptions list so every item is specific, owned and tied to its impact. It is detailed work, and it is often where the easiest points are won back.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Bid Review or write to us at consult@cloudnala.co.za