Rejected RFP Feedback Corpus for AI
Rejected RFP Feedback Corpus for AI
Purpose: consolidate feedback from rejected RFP issues so it can be used as context for:
- Meiran's sourcing / fit reports, so the tool learns what not to surface and what to flag as high risk
- Datopian proposal-writing workflows, including AI-assisted proposal drafts and human review checklists
Scope: rejected or effectively lost RFP/RFQ/RFI issues from roughly the last 12 months, with a few older-but-recently-closed issues included where they contain useful feedback. Most source material is in datopian/sales issue comments. This is a working corpus, not a final statistical report.
Last updated: 2026-07-22
Snapshot Context
The dated RFP analysis snapshot from 2026-06-05 reviewed 30 submitted RFPs:
- Full-set win rate:
3/30 = 10% - Known-outcome win rate:
3/18 = 17% - Invited / relationship-led known-outcome win rate:
3/8 = 38% - Proactive known-outcome win rate:
0/10 = 0%
Here, "known outcome" means issues where the result was recorded as accepted or rejected, excluding pending and unknown issues. The 17% figure is not a live win-rate claim; it is 3 accepted bids divided by 18 accepted-or-rejected outcomes in the 2026-06-05 snapshot. Since then, more rejected outcomes have appeared and no new wins have been recorded in the reviewed set, so a refreshed calculation would likely be worse, not better.
High-Confidence Patterns
1. Responses are often not specific enough to the scored question
Seen in #653, #657, #450, #646, #775, and #776.
Common symptoms:
- generic platform or company capability instead of a direct answer to the scored criterion
- several shallow examples instead of one strong, directly relevant case study
- weak mapping from Datopian evidence to the buyer's exact context
- good content hidden behind page-limit or formatting mistakes
AI proposal rule:
For every scored criterion, draft in this order:
- direct answer to the criterion
- buyer-specific interpretation of what they need
- one or two directly relevant examples
- measurable proof, such as uptime, users, datasets, integrations, delivery dates, or service levels
- explicit mapping back to the scoring words
Do not add generic Datopian capability text unless it earns points against the criterion.
2. Domain and buyer-specific fit matters more than generic data-platform strength
Seen in #615, #657, #705, #740, #775, #776, and #790.
Datopian can be technically credible but still lose when the buyer cares about domain operations, local context, incumbent knowledge, or a very specific implementation pattern.
AI proposal rule:
Before drafting, classify the opportunity by required domain fit:
strong direct fit: we have a close reference and can prove itadjacent fit: we need to explicitly bridge the gapweak fit: we need a partner, a no-bid decision, or a very deliberate strategic reason
If fit is only adjacent, the proposal must explain the bridge. If fit is weak and no partner closes the gap, the default recommendation should be no-bid.
3. Compliance and mandatory requirements need a separate control
Seen in #780, #653, #678, #471, #790, and likely relevant to #661.
Failure modes:
- missing mandatory criteria
- failing an essential criterion before the rest of the proposal is evaluated
- unclear security, accessibility, disaster recovery, or certification evidence
- later-stage logistics, such as in-person presentations, not treated as bid constraints
AI proposal rule:
Maintain a mandatory compliance table before writing begins and again before submission:
| Requirement | Evidence | Owner | Status | Risk |
|---|---|---|---|---|
| Mandatory criterion / certification / logistics item | Exact document, paragraph, certificate, or plan | Named person | met / gap / unclear | low / medium / high |
The draft should not proceed to final review while any mandatory item is gap or unclear unless the bid lead has explicitly accepted that risk.
4. Pricing must be credible, not only low or high
Seen in #678, #780, and #790.
Losses point in both directions:
#6783PODS: price was judged inadequately low and not credible#780UAE: price was understood internally as commercially uncompetitive#790Toulouse: Datopian/Multi was more expensive than the winning OpenDataSoft-Huwise offer while also scoring much lower technically
AI proposal rule:
Every price should include a short internal pricing rationale:
- why this price is competitive for this buyer and region
- why it is credible for the scope
- which assumptions protect margin
- how the staffing plan proves deliverability
- whether price is a strength, weakness, or neutral factor
Do not treat low price as automatically good. Do not treat high price as safe unless the value story is explicit and the buyer can plausibly pay for it.
5. The bid process does not end at submission
Seen in #661, #678, #624, #705, #740, and multiple issues with missing feedback.
Common gaps:
- presentation or interview constraints discovered late
- clarification responses and financial evidence handled under pressure
- feedback requested but not captured in the repository
- outcome labels updated later than the useful learning moment
AI proposal rule:
Every submitted issue should have a post-submission section:
- expected award / shortlist date
- presentation or interview requirements
- follow-up owner and date
- feedback request sent
- feedback received and pasted or linked
- lessons for future AI context
Sourcing Signals for Meiran's Tool
Use these as ranking / warning signals when deciding whether an opportunity should be surfaced, prioritized, or downranked.
Up-rank
- CKAN / open data portal hosting, support, maintenance, migration, or upgrade
- existing-client or relationship-led opportunity
- buyer already knows Datopian, CKAN, Frictionless Data, PortalJS, or our public-sector data work
- scope is close to data portal operations, metadata, API publishing, dataset workflows, data catalogues, or managed platform support
- opportunity allows remote delivery, or any in-person requirements are realistic for the team
Downrank or Flag
- incumbent-replacement tender where the incumbent appears deeply embedded and the buyer is optimizing for continuity
- strong local-presence requirement without a partner who closes the gap
- mandatory certifications we do not have or cannot obtain before contract start
- domain-specific operational requirements where we only have generic platform evidence
- strict GDS, OpenShift, ISO, accessibility, cyber, disaster recovery, language, or public-sector compliance requirements that are not obviously covered
- tenders that require certified translations or heavy local-language delivery without a qualified partner
- later-stage in-person presentations or interviews that the team cannot attend
- opportunities where the best evidence would require a case study we do not have
Require Human Review Before Bid
- price-sensitive incumbent replacement
- custom new-build platform outside CKAN / data portal operations
- partner-led bids where Datopian is a subcontractor and does not control the narrative
- bids where the only reason to proceed is headline contract size
- opportunities surfaced by the tool where no one can explain why Datopian is likely to win
Issue-Level Feedback
| Issue | Opportunity | Result / feedback strength | Feedback captured | AI lesson |
|---|---|---|---|---|
| #790 | Toulouse Metropole open data SaaS via Multi.coop | Strong feedback, rejected July 2026 | Datopian/Multi scored 41/100, ranked 4th. Winner OpenDataSoft-Huwise scored 85/100. Datopian/Multi technical value was 23/60 = 38%; price score was 18/40 = 45%. Winner technical value was 59/60 = 98%; price score was 26/40 = 65%. Buyer noted weak admin/back-office description, too few visualization types, missing security detail, missing DRP/MFA, weak RGAA accessibility, missing data.gouv.fr harvesting, and weak environmental answer. | Competitor-displacement bids need a specific displacement strategy. If the incumbent/competitor is cheaper and much stronger technically, we lose twice. Cover security, accessibility, harvesting, admin, visualizations, and environmental criteria explicitly. |
| #624 | A*STAR Singapore | Rejected after shortlist/demo; weak debrief | Submitted April 2026, shortlisted to demo, rejected June 2026 to Metadataworks. No substantive feedback captured beyond award to another tenderer. | Shortlisting is not enough. Capture debrief after demo, and review why the AI-assisted proposal and demo did not convert. |
| #782 | WIPO Innovation Capabilities Data Explorer | Rejected; weak debrief | Internal note says the proposal was weak, which was expected given limited time. No detailed buyer feedback captured. | Last-minute submissions should be treated as high-risk. If there is not enough time for architecture, evidence, pricing, and review, default to no-bid unless there is a strategic reason. |
| #780 | UAE Ministry of Investment data, analytics and AI portal | Rejected; strong internal learning | Notes/offsite discussion identify missed mandatory criteria and commercially uncompetitive pricing. | Add mandatory compliance checks and pricing rationale before submission. Invited bids can still fail on basics. |
| #776 | Code for Canada Notification Services | Rejected; useful debrief | Datopian project example scored 5/10 = 50%: good infrastructure and monitoring, but not a direct notification case study and lacked actual service-level metrics. Resource response scored 7.5/10 = 75%; evaluator wanted more OpenShift-specific examples. | Case studies must match the service type. Include service-level metrics and platform-specific evidence where requested. |
| #775 | Code for Canada Workflow Services | Rejected; useful debrief | Datopian project example scored 6.7/10 = 67%: solid platform evidence, but only moderate relevance to BC Single Digital Gateway workflow services and weak workflow orchestration / common-component alignment. Resource scores were stronger: 4.6/5 = 92% and 4.1/5 = 82%. | Strong people evidence can help, but weak project fit still costs points. For workflow bids, show workflow-engine patterns and ecosystem alignment. |
| #740 | Saint Lucia open data portal RFI / EOI | Rejected July 2026; no debrief yet | Consortium with InfoLytics submitted in November 2025. Rejection notice received July 2026 and feedback was requested. Issue does not yet contain the detailed debrief. | Local/regional experience was known as a possible gap. When using a partner to close local fit, make the partner's role and evidence concrete. Add debrief if received. |
| #721 | Scotland national open data platform | Rejected; feedback exists externally | Lost to Storm ID. Issue points to an external feedback document and notes a poor score, but detailed feedback is not pasted into the issue. | Import external feedback into this corpus. Do not rely on Drive links alone if the feedback should train AI context. |
| #705 | Energy Poverty Dashboard | Rejected; no buyer debrief | Partner-led bid; feedback was requested but no useful response captured. Pre-bid notes flagged Canadian/local requirements, synthetic data weakness, and policy/domain fit risks. | If local policy, data science, or jurisdiction-specific requirements matter, the partner must close the gap in the proposal. |
| #697 | ARCEP France data collection portal | Rejected; feedback exists externally | Issue links an external translated feedback document. Comments show language/certified translation requirements and partner architecture alignment challenges. | Import external feedback. Flag language, certified translation, and partner-architecture constraints during sourcing and bid/no-bid. |
| #678 | 3PODS - Third Party Observation Data Service | Disqualified; strong process/commercial feedback | Buyer challenged abnormally low development/delivery cost and requested detailed staffing/effort justification. Final loss reasons recorded as inadequately low pricing and financial stability concerns. Clarifications also touched ISO certification language and financial-risk documentation. | Pricing must be defensible with people/days and delivery logic. Assess financial qualification and certification language before submission. Finish complex bids at least two days before deadline. |
| #663 | DHSC MedTech Compass Alpha | Not shortlisted; no detailed debrief | Rejection invited request for a breakdown, but no detailed breakdown is captured in the issue. | Capture debrief. For alpha/service-design bids, make sure methodology, user research, public-sector delivery, and assurance evidence are direct. |
| #657 | UKRI SDR UK Data Catalogue | Rejected; strongest detailed feedback | Datopian score recorded as 56.89; winning supplier score as 82.27. Weaknesses included limited academic research catalogue fit, page-limit overrun, generic methodology, weak context-specific risks, high-level timeline, and weak measurable innovation/social value. | Use concise, compliant answers. Show academic/research context, stakeholder onboarding, detailed timeline, risk owners/ratings, measurable social value, and future-ready architecture. |
| #653 | DfT Local Transport Data | Rejected at essential criterion; strong feedback | Failed essential GDS alpha/beta/service-assessment evidence. Feedback wanted one convincing example showing direct adherence to GDS standards and service assessment, not multiple shallow references. | For essential criteria, use one deep directly relevant case study. If we cannot prove the essential requirement, no-bid or qualify the risk explicitly. |
| #646 | Executive Council EEIA website and data portal | Rejected; weak but useful feedback | Debrief came too late, but buyer advised to respond to what the solicitation asks for and ask clarifying questions while open. Internal interpretation: responses may not have been relevant enough. | Draft from the solicitation, not from reusable boilerplate. Ask clarification questions while the window is open. |
| #632 | Westminster City Council data hub implementation partner | Not shortlisted; weak feedback | Datopian did not appear on the Spark DPS shortlist after the buyer's filtering exercise. No details on filtering criteria were provided. | For framework/DPS opportunities, check whether Datopian appears under the buyer's likely filters before treating the opportunity as real. |
| #615 | Leicester Air Quality Monitoring Stations | Rejected; strong feedback | Winner had closer operational fit: AQMS hardware/on-site maintenance coordination, DEFRA-compliant reporting and validation, and real-time environmental sensor / telemetry experience. | Do not treat operational domain bids as generic data-platform bids. Add a domain partner or no-bid when the strongest evidence is hardware/operations-specific. |
| #592 | UKRI Sustainable Research Methods Hub | Not shortlisted; no debrief captured | Feedback was requested, but no substantive feedback is captured in the issue. | Missing feedback should be closed out. Similar UKRI bids need research-domain evidence and concise scored answers. |
| #588 | Kyrgyz open data portal | Rejected; no debrief captured | Selected another vendor. No detailed explanation captured. | Record outcome, but do not infer loss reason without evidence. |
| #513 | Stanford Natural Capital Project | Rejected; limited feedback | Buyer cited a competitive pool. Internal note observed that Datopian rarely wins tenders where there has been no client call before submission. | Push for a discovery call on invited opportunities. If all interaction is email-only, relationship strength may be too weak. |
| #471 | IDB open data platform | Rejected; no formal debrief but useful pre-bid signal | Issue contains extensive pre-bid questions on PoolParty, recurring costs, PortalJS, connectors, HA/DR, SLA, POC, SEO, multilingual metadata, DOI, DCAT/schema.org, validation, versioning, APIs, ESRI indexing, SOC2, incident response, encryption, access controls, pen tests, and security governance. No detailed rejection feedback captured. | Enterprise open-data platform bids need a reusable security/compliance/integration evidence pack. Avoid answering critical controls ad hoc. |
| #450 | Ofwat Programme Ocean data platform | Rejected; strong feedback | Not shortlisted because responses were inadequate on data transformation leadership, metadata management plus cultural change, agile methodology/tools/governance, and capability building. | For transformation bids, cover operating model, culture change, agile governance, trust, dependency management, knowledge transfer, and client self-sufficiency, not just technology. |
Proposal-Writing Checklist for AI and Humans
Use this checklist before every final proposal review.
- Does every scored question have a direct answer in the first paragraph?
- Does the answer repeat the buyer's own scoring language where useful?
- Is there at least one directly relevant case study, not just a nearby one?
- Are all mandatory criteria in a separate pass/fail table?
- Are page, word, character, file, and formatting limits explicitly checked?
- Is pricing backed by a credible staffing plan and assumptions?
- Does the proposal explain domain fit, local fit, and buyer-context fit?
- Are security, accessibility, disaster recovery, privacy, compliance, and certifications addressed where relevant?
- Are risks context-specific, with owners, ratings, timings, mitigations, and residual risk?
- Does the timeline include milestones, dependencies, critical path, launch, support, and maintenance?
- Are social value / innovation commitments measurable and reportable where scored?
- Are presentation/interview/travel requirements understood before submission?
- Is there a plan to request and capture feedback after the result?
Reusable Prompt Context
Paste or reference this section in proposal-writing AI workflows.
Datopian's recent rejected RFP feedback shows recurring avoidable weaknesses:
- Proposals can be too generic against scored criteria.
- Evaluators reward direct, buyer-specific evidence over broad capability statements.
- One deep, relevant case study is often better than multiple shallow examples.
- Domain fit must be proven, especially in research, health, transport, environmental, workflow, and public-sector transformation bids.
- Mandatory criteria, certifications, accessibility, security, disaster recovery, and presentation logistics need explicit compliance checks.
- Pricing must be both competitive and credible; an unsupported low price can lose as surely as an expensive one.
- Risk registers, timelines, social value, innovation, and capability-building sections need measurable, context-specific detail.
- Feedback and debriefs must be captured and reused; do not let Drive links or email threads remain outside the learning corpus.
When drafting a proposal, optimize for evaluator scoring. For each criterion, state the answer directly, map it to the buyer's requirement, prove it with a relevant example, quantify the evidence, and remove boilerplate that does not earn points.
Follow-Up Backlog
These items should be closed so this corpus becomes more complete:
- Import the detailed feedback for #721 Scotland from the linked external document.
- Import the translated feedback for #697 ARCEP from the linked external document.
- Add any received feedback for #740 Saint Lucia, because feedback has been requested but is not yet in the issue.
- Check whether detailed feedback was ever received for #624 A*STAR, #663 DHSC MedTech, #705 Energy Poverty, #592 UKRI Sustainable Research Methods Hub, #588 Kyrgyz, and #471 IDB.
- Feed this document into Meiran's sourcing/ranking prompt and the Datopian proposal-writing prompt.
- Add new rejected-RFP feedback here as part of issue closeout, not months later.
