Bid teams talk about “the client” as if it were one person with one opinion. It almost never is. The executive who wants change quickly may be sitting next to the operations manager who is dreading having to support it. Users may prefer one approach while procurement rewards strict compliance with the forms. The person who explains the problem in a meeting may never see the scoring sheet.
A proposal written for “the client” in general ends up persuading nobody in particular. This part is about working out who is actually judging, what each of them is worried about, and how to hear the concerns that never make it into the RFP.
We are following one fictional pursuit throughout this series. Rivermark Water and Ridgeline Digital are fictional, and all figures are illustrative. Rivermark, a regional water utility with about 380,000 customer accounts, has issued an RFP for a customer self-service and case management platform. Ridgeline, a 45-person delivery partner, has just decided to bid alongside a teaming partner, as described in Part 1.
Everyone who judges the bid
Different people read the same proposal looking for different things. The table below is a general guide. It lists who usually sits around the decision, what they care about, and the kind of evidence that reassures them.
| Stakeholder | Usually cares about | Evidence that reassures them |
|---|---|---|
| Executive sponsor | Outcome, timing, value, accountability and risk | A clear recommendation, a roadmap and a short risk summary |
| Business owner | How the work changes, adoption and benefit | A journey or process flow, and a measured baseline and target |
| Enterprise architect | Strategic fit, standards, dependencies and how the change happens | Context, capability, target and roadmap views |
| Technical architect | Whether it will work, integration, and qualities such as speed and availability | Component, integration, deployment and data views |
| Security and risk | Trust, data, controls, and the risk that remains | Trust boundaries, a control matrix and a responsibility model |
| Operations | Monitoring, incidents, support, service levels and change | An operating model, runbooks, observability and handover plan |
| Delivery lead | Scope, sequence, people, dependencies and acceptance | Work packages, milestones and a log of risks, assumptions, issues and dependencies |
| Finance and procurement | Price, compliance, comparability and contract clarity | A pricing schedule, visible assumptions and a compliance matrix |
| End user | Usability, continuity and practical change | Journeys, prototypes, training and help for people who need assistance |
Two terms in that table come up throughout the series. A runbook is a written procedure for a routine or emergency task, such as restarting a service or handling an outage. Observability means the service produces enough logs, metrics and traces that people can see what it is doing and diagnose problems.
The point is not to produce a separate proposal for each person. It is to make sure every one of them can find their own answer somewhere, quickly.
The Rivermark map
Ridgeline’s bid owner turned that general table into a specific map after the compulsory briefing session and two follow-up conversations. Eight groups emerged, each with a distinct worry.
A few of these deserve a closer look.
The Head of Customer Services is the executive sponsor, and the 1 July tariff change is personal. If billing queries swamp the contact centre again this year, it will be discussed at board level. What reassures this person is a dated plan that looks achievable, not a long list of features.
The CFO asked only one question at the briefing, and it was about year two. A platform that is affordable to build but expensive to run is a problem that arrives after the project team has gone home.
The IT manager has a small team and an old estate. Every new system Rivermark has bought has ended up being supported internally, whatever the contract said.
The information security officer asked, three separate times and in three different ways, where customer data would be stored and who could see it. When a question keeps coming back, it is not a question. It is a concern that has not been answered yet.
Procurement was clear that bids not following the RFP’s structure and forms exactly would be marked down or disqualified, and that all communication must go through the single named contact.
Customers never attend a briefing session, but they are the reason for the RFP. Their need is simple: to know that the leak they reported is being dealt with.
Procurement is a stakeholder, not an obstacle
Technical teams sometimes treat procurement rules as paperwork to get through. That is a mistake, because procurement protects fairness, and fairness is what makes the evaluation defensible.
Most formal RFPs, including Rivermark’s, work in similar ways. They name a single contact person. Questions must be submitted in writing before a deadline, and the answers are shared with every bidder. Contacting evaluators directly during the evaluation period can disqualify a bid. The structure of the response, the numbering and the forms are specified because evaluators compare bids side by side.
Understanding this changes behaviour. It means clarification questions should be phrased carefully, because competitors will read the answers. It means the proposal should mirror the RFP’s structure even when a different order would tell a better story. And it means relationship-building has to happen through the legitimate channels: the briefing session, the clarification process and, later, the presentation.
Read the signals
The RFP records what the client chose to formalise. Other signals reveal the context around the decision. Watch for:
- Concerns repeated in meetings. At Rivermark, data location came up again and again.
- Deadlines tied to something external, such as regulation, an audit, funding or a public commitment. The 1 July tariff change is one.
- Unusually detailed wording in one section. Rivermark’s RFP spent a full page on complaints tracking, which points straight at the audit finding.
- Repeated questions about ownership, support or accuracy. The IT manager kept returning to who supports the platform.
- Tension between business and technology people. Customer services wants speed; IT wants something it can maintain.
- Requests for simpler architecture after a previous proposal was too dense. Someone at the briefing mentioned that a previous bidder’s submission had been “too technical”.
- Questions that ask for reassurance rather than features. “Can customers see progress?” is not a request for a status field. It is a request for fewer angry repeat calls.
- Responsibilities nobody owns. Nobody could say who would maintain the content customers see.
- Wording aligned closely to one incumbent or platform. Worth checking, although Rivermark’s RFP looked neutral.
The question beneath the question
The most useful habit in this part is simple. When someone asks a question, ask yourself what worry would make a reasonable person ask it. Then make sure the proposal answers the worry, not only the words.
This is not manipulation. Nobody is being tricked. Listening in this way identifies decision risk: the reasons a client might hesitate to choose you, even if your solution is sound. A proposal that addresses those reasons directly is simply more complete.
What “too technical” usually means
The comment about a previous proposal being too technical is worth dwelling on, because bid teams often misread it as “use fewer words” or “remove the diagrams”.
It can mean several different things:
- The diagram answered a question nobody in the room was asking.
- Vendor product names replaced the client’s own language for its services.
- Optional ideas looked like mandatory scope, so the proposal seemed bigger and riskier than it was.
- The presenter skipped the business context and went straight to the platform.
In each case the solution may not need less substance. The audience needs progressive disclosure: start with the outcome and the context, then show who does what, then the flows, and only then the technical detail, so each level makes the next one easier to follow. Part 7 covers how to build an architecture pack that works this way. For Rivermark, Ridgeline decided its executive response would open with Rivermark’s situation, in Rivermark’s words, before a single system was named.
How to behave in the meeting
A briefing session or discovery conversation is short, and the habits below make it far more useful.
- Confirm the purpose of the session and the decisions it needs to support.
- Let the client describe the problem before anyone presents a platform.
- Reflect back what you heard and invite correction. At Rivermark’s briefing, Ridgeline’s lead architect summarised: “So the priority is billing self-service before 1 July, with fault reporting close behind?” The sponsor corrected it. Fault status mattered more, because repeat fault calls were the bigger load. That one correction changed the order of the delivery plan.
- Separate confirmed facts, interpretations and open questions in your notes.
- Use simple sketches to test understanding. A rough drawing of how a fault report travels today often surfaces a spreadsheet nobody mentioned.
- Name contradictions respectfully. “We heard both that data must stay in South Africa and that WhatsApp is essential. Could you help us understand how those fit together?”
- Confirm owners, dates and evidence sources before leaving.
- Do not promise timing, savings, accuracy or integration without validation. Enthusiasm in a meeting becomes an expectation in the evaluation.
At a compulsory briefing, also make sure the attendance register is signed. Missing it can be a disqualification in its own right.
What to take from this part
There is always more than one client. Map everyone who evaluates, influences, approves or could block the decision.
Each stakeholder needs different evidence. The CFO needs running costs; the security officer needs a data flow. Make each answer easy to find.
Treat procurement as a stakeholder. Its rules protect fairness, and following them exactly is part of winning.
Answer the concern beneath the question. Repeated questions and unusually detailed RFP sections point to decision risk.
“Too technical” rarely means “too much substance”. It usually means the wrong starting point. Disclose detail progressively.
Next in the series: Discovery: the questions that change the answer.
How CloudNala can help
After a briefing session, we help bid teams turn their notes into a stakeholder map and a short list of concerns beneath the questions, then check that the planned proposal gives each stakeholder a clear place to find their answer. It is a half-day exercise that often changes what the executive response leads with.
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