Most proposals are full of features. Case management, a customer portal, dashboards, integration, 24-hour support. Every bidder on the shortlist offers something that sounds much the same, so the evaluator is left comparing lists that barely differ.
Features answer the question “what will we get?”. The question an evaluation panel actually has to answer is harder: “why should we choose this bidder over the others, and will we regret it?” This part of the series is about answering that second question on purpose.
We are still following the same fictional pursuit. Rivermark Water, a regional utility with about 380,000 customer accounts, has issued an RFP (request for proposal) for a customer self-service and case management platform. Ridgeline Digital, a 45-person delivery partner, is bidding with a partner that holds the qualifying reference. Both organisations are invented for this series, and all figures are illustrative.
Why a list of features does not win
Think about two property listings for the same kind of house. One says “three bedrooms, double garage, north-facing garden”. The other says “a ten-minute walk to the school your children already attend, with a garden that gets afternoon sun”. The house is identical. The second listing is written for a particular buyer’s situation, so it gives them a reason.
Proposals work the same way. A feature only becomes persuasive when it is connected to something the client needs, backed by evidence and tied to a result the client cares about. Without that connection, the evaluator has to do the linking themselves, and most will not.
There is a second problem with features. They are easy for competitors to copy. If Ridgeline writes “a modern customer portal”, every other bidder can write exactly the same sentence. A reason grounded in Rivermark’s own deadline, systems and constraints is much harder to imitate.
What a win theme actually is
A win theme is a short, provable argument for choosing you. It follows a simple pattern:
Because the client needs [priority], we propose [approach], supported by [evidence], producing [outcome or reduced risk].
Each part of that sentence does a job:
- Client priority is something the client has said matters, ideally in their own words. It comes from the RFP, the briefing session and the stakeholder work in Part 2.
- Proposed approach is what you will actually do about it. Not a product name, a decision.
- Evidence is the reason the evaluator should believe the approach will work: a reference, a prototype, a named person, a result from similar work.
- Measurable value is the result, described in a way someone could check later.
- Reduced decision risk is often the real prize. Evaluators are not only buying an outcome. They are protecting themselves from choosing a bidder who fails.
Here is a general example that fits Rivermark closely:
Because the service must launch before every legacy integration can be replaced, we propose an API-led bridge with controlled manual fallback. This separates launch from the longest dependency while preserving reconciliation and a defined retirement path.
In plain terms: do not make the launch date wait for the slowest, riskiest piece of work. Build a safe temporary connection instead, with a manual process for anything the connection cannot yet handle, and a clear plan for removing the temporary parts later.
Rivermark’s three win themes
In Part 3, discovery established that Rivermark’s 20-year-old billing system has no supported way for other systems to write data into it. It only offers read-only database views and a nightly file export. That single fact shaped the first theme.
Theme 1: Live before 1 July, without waiting for a new billing system. At the briefing session, Rivermark’s sponsor corrected Ridgeline’s playback: fault status matters even more than billing self-service, because repeat fault calls are the bigger load. So faults come first. But the tariff change on 1 July always triggers a spike in billing queries too, and replacing the billing system is a separate, future procurement. Ridgeline proposes putting fault reporting and status live first, then reading live balances from the billing views and placing payment-arrangement requests in a managed queue for Rivermark’s back office to post. The evidence is the partner’s 140,000-customer case management rollout and a working prototype. The risk removed is obvious to the sponsor: the launch no longer depends on a project that has not started.
Theme 2: One record of every fault, from first report to fix, with updates the customer does not have to chase. Today, fault reports arrive by phone, email and a WhatsApp number that three agents watch by hand. Duplicates are common and customers hear nothing until the water comes back. Ridgeline proposes a single case for each fault, automatic merging of duplicate reports for the same location, and status messages at each stage. The contact centre manager cares about this one most, because every “any news on my burst pipe?” call is a call that did not need to happen.
Theme 3: A service Rivermark can run after the build team leaves. The CFO worries about what the platform costs in year two. The IT manager fears inheriting another system nobody on staff understands. Ridgeline proposes a defined operating model, skills transfer during the build, and a managed service with a predictable monthly charge and clearly separated consumption costs such as messaging fees. The evidence is a named delivery lead who has run a managed service before.
Notice that each theme answers a different stakeholder, and none of them is a feature.
Words that are not win themes
Some phrases appear in almost every proposal and win almost nothing:
- “Innovative.” Innovative compared with what, for whom, and why does Rivermark need innovation rather than reliability?
- “Best of breed.” A claim every vendor makes about its own choices. It tells the evaluator nothing they can score.
- “Experienced team.” Every bidder says this. Experience only counts when it is named, relevant and checkable.
These words are not banned. They simply need proof attached before they become part of an argument. “Experienced team” becomes useful when it turns into “the delivery lead has run a 24-month managed service for a contact centre of similar size, and will be named in the contract”.
The story spine
A proposal is long, and different evaluators read different sections. The story spine is the sequence of questions the whole document must answer, in an order that makes sense to someone reading cold. There are nine. Here they are with the Rivermark answer in a line each.
| Question | Rivermark answer, in one line |
|---|---|
| What outcome is required? | Visible fault handling first, then self-service billing queries, before 1 July |
| What prevents it today? | Three unconnected channels, an ageing ticketing tool and a billing system with no write access |
| Which principles guide the response? | Launch without waiting for billing replacement; one record per fault; a service Rivermark can run |
| What solution is proposed? | Case management, a customer portal, WhatsApp and an agent console, bridged to billing |
| How will the organisation reach it? | Three safe stages that retire the old tools one at a time |
| How will it be secured, operated and governed? | Hosted in South Africa, POPIA controls, a named operating model |
| What will be delivered, when, by whom and for how much? | Eight work packages over 12 months, then 24 months of managed service |
| Why should the evaluator believe the team? | A comparable reference, a working prototype and named leads |
| What decision is required next? | Award, then a six-week discovery to confirm scope and baseline |
If a section of the proposal does not help answer one of these questions, it is probably padding.
Value, without inventing numbers
Value is the “so what” of a proposal. It helps to think about the kinds of value a client might receive:
| Value | Example measure | At Rivermark |
|---|---|---|
| Revenue | Conversion, retention or product uptake | Disputed bills resolved sooner, so amounts are corrected or collected sooner |
| Cost | Handling time, infrastructure spend or manual effort | Fewer repeat calls about the same fault |
| Risk | Control coverage, recovery and audit evidence | Closes the audit finding that complaints were not tracked end to end |
| Service | Turnaround, availability or first-contact resolution | Customers see fault status without calling |
| People | Adoption, less repetitive work or time to competence | Three agents no longer watching WhatsApp by hand |
| Strategic | Reusable platform, faster future launches or exit options | The future billing replacement plugs into the same channels |
The hard rule is simple: do not invent quantified benefits. It is tempting to write “reduces call volumes by 40%”. Unless Ridgeline has a baseline and a comparable result, that number is made up, and a sceptical evaluator will know it.
Rivermark does not currently measure how many calls are repeat calls about a fault already reported, so there is no baseline to improve on. Ridgeline’s proposal says exactly that, and does not quote a reduction. Instead it explains how the benefit will be measured: during discovery, agents tag each call as a new fault, a repeat call about a known fault or something else, for a representative period that includes at least one bad weather week. That gives Rivermark a real baseline, and the managed service reports the same measure every month after launch. If a proposal does need to show scale before a baseline exists, any scenario must be clearly labelled as illustrative, and it should never become a committed figure.
Proof: strongest first
Evaluators weigh evidence by how closely it resembles their own situation. That gives a clear order, from strongest to weakest:
- A comparable reference: similar client, similar scale, similar problem, and someone willing to confirm it.
- A working asset or prototype the evaluator can see or click through.
- Named delivery evidence: specific results from specific past work.
- Relevant people and certifications: named individuals with the right experience, and credentials that matter for this work.
- General company claims: size, history, awards, values.
Most proposals lead with the bottom of that list, usually on page two, under a heading like “About us”. Ridgeline’s strongest proof sits near the top instead.
There is an honesty point worth making. The 140,000-customer reference belongs to Ridgeline’s partner, not to Ridgeline. The proposal says so plainly, names the partner’s role in the delivery and explains how the two teams will work together. Presenting a partner’s reference as your own is the kind of thing that surfaces at a reference check and destroys trust in everything else.
What to take from this part
A win theme is an argument, not a feature. Priority, approach, evidence, value and reduced risk, in one provable sentence.
Each theme should answer a real stakeholder. Rivermark’s three themes speak to the sponsor, the contact centre manager, the CFO and the IT manager.
Never invent a number. Where the baseline is missing, as it is for Rivermark’s repeat fault calls, propose how it will be measured instead.
Lead with your strongest proof. A comparable reference and a working prototype beat a company history every time.
Next in the series: TOGAF, CAF and WAF without the framework theatre.
How CloudNala can help
We help bid teams turn a requirements list into two or three win themes that survive a sceptical evaluator: tracing each theme back to a client priority, checking that the evidence is real and relevant, and removing value claims that cannot be defended. It is usually a short working session, done early enough that the whole proposal can be written around the themes rather than decorated with them at the end.
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