Every proposal is built on facts, and some of those facts are wrong. The only question is whether you find out during the bid, when it costs a clarification question, or during delivery, when it costs a change request, an unhappy client and a margin that disappears.
Discovery is the work of finding the facts that matter. It is easy to confuse with gathering information, and the difference is important. A long questionnaire produces a lot of answers. Good discovery produces the handful of answers that change the solution’s shape, the effort to deliver it, the risk, or the price. Everything else is useful background.
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, wants a customer self-service and case management platform live before a 1 July tariff change. Ridgeline, a delivery partner, is bidding with a teaming partner and has already mapped the people judging the bid in Part 2.
Discovery during a tender is constrained
In a consulting engagement, discovery can mean weeks of workshops. In a formal tender, access is limited. Ridgeline had four sources: the RFP documents, the compulsory briefing session, written clarification questions (closing at the end of week 3, with answers shared with all bidders), and what could be learned from public information about the utility.
That makes each question valuable. The groups below are a checklist to choose from, not a list to send in full.
Start with outcomes
Before asking anything technical, pin down what must improve.
- What result must improve, and who experiences the problem?
- What is the current baseline, and which measure would prove improvement?
- What deadline is real, what drives it, and what must actually be working by that date?
- What happens if nothing changes?
At Rivermark, the baseline existed for some measures (peak call waits of about 14 minutes, billing disputes taking about 21 days) and not for others. Nobody could say how many fault calls were repeat calls about the same leak. That gap matters, because “fewer repeat calls” is one of Ridgeline’s intended benefits, and a benefit without a baseline cannot be proven. The honest response is to propose how it will be measured, not to invent a number.
Business and users
- Which journeys, capabilities and decisions are in scope?
- Who are the users: customers, agents, administrators, support staff, people who need assistance?
- What are the volumes, peaks, languages, locations and accessibility needs?
- Which decisions must remain with a person rather than being automated?
- What adoption or organisational change is required?
For Rivermark, the storm-week peak of about 30,000 fault reports matters more than the monthly average, because a system sized for an average week fails on the day it is needed most. And one decision clearly has to stay human: whether a reported burst near a road is a safety risk.
Current state
- Which systems perform the process today?
- Which spreadsheets, emails and manual workarounds fill the gaps?
- Where is the authoritative source for each kind of data?
- Is the pain caused by technology, process, policy, data or unclear ownership?
- Which existing investments must be reused, retired or replaced?
Ridgeline found that field teams are allocated jobs from a spreadsheet, even though they already carry a licensed mobile job app with a supported API. That is a reuse opportunity hiding in plain sight, and it would have been missed by a team that only asked about the systems named in the RFP.
Integration and data
An API, or application programming interface, is a supported way for one system to ask another for data or to make it do something. Whether an API exists, and what it allows, often decides how hard a project really is.
- Are supported APIs available, or do systems exchange files, events, direct database access or manual re-keying?
- What volumes, speeds and consistency are needed? How are records reconciled, meaning checked to confirm that two systems agree?
- Who owns each data domain, and each data quality problem?
- Which information is personal, confidential, regulated or restricted by contract?
- Where may it be stored, processed, backed up and supported from?
This group produced the answer that changed Ridgeline’s bid.
The answer that changed the bid
Ridgeline’s early solution hypothesis assumed that the new platform could write payment arrangements directly into the billing system. It seemed reasonable. Modern systems usually allow it.
Ridgeline submitted a carefully worded clarification question about how bidders could integrate with billing. The written answer, shared with all bidders at the end of week 3, was short: the billing system has no supported API for writing data. Read-only database views exist, and a nightly batch file export feeds other systems.
One sentence, and four parts of the proposal had to change.
This is what discovery is for. The same fact found after contract signature would have meant a delay, a dispute about who should have known, and work that was never priced.
Quality, delivery and operations
These questions are about how well the service must work and who keeps it working. Two acronyms appear constantly. The RTO, or recovery time objective, is how long a service may be unavailable after a failure. The RPO, or recovery point objective, is how much recent data may be lost, expressed as time. An RPO of 15 minutes means losing at most the last 15 minutes of changes.
- What availability, RTO and RPO apply to each capability, not just the platform overall?
- From which user location is performance measured?
- What scale, concurrency and seasonal peaks exist?
- Which audit, retention, encryption and separation-of-duties controls apply?
- Is an offline or degraded mode needed when a dependency fails?
- Which teams, suppliers, licences, approvals, test data and environments does delivery depend on?
- Who owns the service, its content, its integrations, its support and its cost after launch?
- What evidence will allow go-live?
For Rivermark, the degraded-mode question turned out to matter a great deal. If the billing system is down, what should a customer see? That question resurfaces at the presentation in Part 11.
Commercial and procurement
- Is the work fixed scope, outcome-based, time and materials, or discovery-led?
- Which prices must be fixed, and which remain consumption-based, such as cloud usage or message fees?
- Are cloud, licences and third-party services included in the bid price?
- Which warranties, penalties, insurance and contract terms apply?
- Which price template must be used?
Asking clarification questions well
Because answers are shared with every bidder, how a question is written matters.
Ask for facts, not solutions. “Does the billing system support writing payment arrangements through an API?” gets a factual answer. “Would the utility accept our API-led bridge approach?” tells competitors your strategy.
Make the answer easy to give. Offer options where possible: “Is billing data available through an API, database views, file exports, or a combination?”
Explain the impact. “The answer affects integration effort and price” encourages a considered reply rather than a quick one.
Ask early. A question sent on the last day of the window may be answered too late to change anything.
Classify the unknowns
Some questions will never be answered before submission. The mistake is to treat all of them the same. Ridgeline sorted Rivermark’s open questions into four classes.
| Class | What it means | What to do |
|---|---|---|
| Blocking | Different answers create a materially different solution or liability | Ask, and do not commit until it is answered |
| High impact | Affects scope, estimate, schedule or risk | Ask; if there is no answer, use a bounded assumption |
| Design detail | Can be settled later without changing the commercial boundary | Record it as a planned decision |
| Preference | Improves the experience without changing the commitment | Recommend, then validate with the client |
At Rivermark, whether the WhatsApp provider processes message data outside South Africa was blocking, because the RFP requires hosting in South Africa and the answer could change the channel design or the contract. Storm-week volumes were high impact, so without a firm answer they became a bounded assumption. The portal’s colours were a design detail. Whether to add a chatbot was a preference.
Keep an evidence register
An evidence register is a simple table of the statements your proposal relies on, where each one came from, and what happens if it turns out to be wrong. It stops a rumour from a meeting becoming a fact in the proposal.
| ID | Statement | Status | Source | Impact if wrong | Owner and action |
|---|---|---|---|---|---|
| E-01 | Billing read-only views can be queried in near real time | Unverified | Briefing session Q&A | Customers may see balances up to a day old; design and testing change | Lead architect to request confirmation |
| E-02 | Peak fault reports stay under 30,000 a week | Assumption | Rivermark’s storm-week figure | Capacity, messaging costs and price change | Validate in discovery; bound in the proposal |
| E-03 | Field job app API supports creating jobs | Confirmed | Vendor documentation and clarification answer | Field integration effort changes | None |
Watch E-01. It was still unverified when the first draft was written, and in Part 12 the red team catches it written in the proposal as if it were fact.
The CRIT record: one brief for everyone helping
A bid draws in people for short bursts: a security specialist for a day, a reviewer for an afternoon, a pricing analyst for a week. Each needs the same context, and repeating it verbally wastes time and introduces errors. A CRIT record is a short, structured brief with four sections: Context, Role, Interview and Task.
| Section | What it holds | Rivermark example |
|---|---|---|
| Context | The client and partner boundary, the opportunity, the desired outcome, the audience, sources, confirmed facts and assumptions | Rivermark’s self-service and case management RFP; outcome before 1 July; evidence register E-01 to E-03 |
| Role | Who leads (the proposal lead or lead solution architect) and who supports (business and domain, security, data and integration, delivery and commercial review) | Lead architect leads the solution volume; the teaming partner supports case management design |
| Interview | The blocking and high-impact questions still open | WhatsApp data processing location; storm-week volumes |
| Task | Deliverables, definition of done, approval path, submission deadline and anything unresolved | Integration section and diagrams, reviewed by the bid owner, due end of week 4 |
The same record works as the brief for an AI drafting assistant. Pasting it in before asking for a first draft gives the tool the context, the boundaries and the open questions, which is far safer than a one-line prompt. The facts and assumptions still need to come from your register, not from the tool. There is more on where automation helps and where people must stay in control in AI agents for proposals and RFPs.
What to take from this part
Discovery looks for facts that change the answer. Shape, effort, risk and price. Everything else is background.
One answer can reshape a bid. Rivermark’s “no write API” changed the solution, the work, the risks and the price.
Write clarification questions for an audience of competitors. Ask for facts, offer options and ask early.
Classify unknowns instead of worrying about all of them. Blocking questions stop commitments; the rest are bounded, planned or validated.
Keep an evidence register and a CRIT record. They stop rumours becoming facts and keep everyone working from the same brief.
Next in the series: Make it easy to award the point: requirements, assumptions and traceability.
How CloudNala can help
We run short discovery sprints alongside bid teams: reviewing the RFP for the questions that change the answer, drafting clarification questions that ask for facts without revealing strategy, and setting up the evidence register so every claim in the proposal has a source and an owner.
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