---
tags:
  - PRD
Hub:
  - "[[📇 Product Requirements Documents]]"
---
Tender Reference Manager — Product Requirements Document

A governed repository for qualifying, selecting, approving, and presenting company references in public and private tender responses

|                       |                                                                   |
| --------------------- | ----------------------------------------------------------------- |
| **Document status**   | **Draft**                                                         |
| **Product stage**     | Discovery / MVP definition                                        |
| **Primary platforms** | Responsive web application; desktop companion considered post-MVP |
| **Target release**    | To be determined after discovery                                  |
| **Owner**             | Product team                                                      |
# 1. Executive Summary

The product will help bid and sales teams manage reusable customer and project references used to demonstrate eligibility, technical capacity, sector experience, and delivery credibility in tender processes. It will centralize validated reference evidence, match references to tender criteria, manage customer-contact and disclosure approvals, assemble compliant reference packs, and preserve an auditable record of what was submitted, for which opportunity, and under which authorization. The MVP will prioritize trusted data, fast qualification, controlled reuse, and deadline-safe collaboration.

## 1.1 Product Vision

Vision: enable every tender team to find the strongest eligible references quickly, prove compliance with traceable evidence, and reuse them only with the right approval.

# 2. Problem Statement and Opportunity

·         Customer and project references are scattered across CRM records, past proposals, contract files, spreadsheets, and individual knowledge.

·         Reference data is often incomplete or outdated, making it difficult to prove that eligibility thresholds, delivery dates, values, scope, geography, or technology criteria are met.

·         Bid teams spend significant time asking colleagues for suitable projects and rebuilding reference sheets under deadline pressure.

·         Customer permission, confidentiality restrictions, named contact consent, and evidence validity are not consistently controlled.

·         The same reference may be described differently across bids, creating quality, compliance, and audit risks.

·         Organizations lack visibility into reference coverage gaps across sectors, capabilities, contract sizes, and procurement requirements.

# 3. Target Users and Jobs to Be Done

|   |   |   |
|---|---|---|
|**Persona**|**Primary need**|**Critical job to be done**|
|**Bid manager**|Rapid, compliant reference selection|Match tender criteria to approved references and assemble a submission-ready evidence pack before the deadline.|
|**Sales or account manager**|Customer relationship control|Confirm whether a customer, contact, logo, project description, and commercial data may be disclosed.|
|**Solution expert or practice lead**|Evidence of capability|Identify projects that demonstrate the required technologies, services, certifications, scale, and outcomes.|
|**Contract or delivery manager**|Accurate execution data|Validate scope, dates, value, performance, deliverables, and supporting documents.|
|**Legal, privacy, or compliance reviewer**|Controlled disclosure|Review confidentiality, personal data, contractual restrictions, and approval evidence before submission.|
|**Reference data steward**|Quality and governance|Maintain canonical records, ownership, freshness, duplicates, taxonomies, and auditability.|
|**Sales leadership**|Portfolio insight|Identify evidence gaps that limit qualification for strategic opportunities.|

# 4. Goals, Non-Goals, and Success Metrics

## 4.1 Product Goals

1.      Reduce the time required to identify references that satisfy mandatory and scored tender criteria.

2.      Increase the completeness, freshness, consistency, and traceability of reference data.

3.      Prevent unauthorized disclosure of customer names, contacts, logos, commercial details, or confidential deliverables.

4.      Generate reusable, tender-specific reference sheets and evidence packs from approved source data.

5.      Provide an auditable history of validation, approval, use, submission, expiry, and withdrawal.

6.      Expose portfolio coverage gaps early enough to support sales and delivery strategy.

## 4.2 Non-Goals for MVP

·         Managing the complete tender lifecycle, pricing model, qualification decision, or proposal authoring process.

·         Replacing the CRM, contract repository, project management system, or document management platform.

·         Automatically deciding legal eligibility or guaranteeing compliance with procurement law.

·         Contacting customers automatically without an explicit workflow and authorized sender.

·         Inventing, embellishing, or inferring project outcomes not supported by validated evidence.

## 4.3 Proposed Success Metrics

|   |   |   |
|---|---|---|
|**Metric**|**MVP target**|**Measurement**|
|**Time to qualified shortlist**|Median under 15 minutes for a tender with defined criteria|Time from criteria entry to saved shortlist|
|**Mandatory-criteria coverage**|100% of shortlisted references show pass, fail, or review needed for every mandatory criterion|Coverage status at shortlist approval|
|**Core-data completeness**|At least 90% for references marked reusable|Required-field quality score|
|**Approval validity**|100% of submitted references have valid disclosure status or a recorded exception approval|Pre-submission control|
|**Reference-pack preparation time**|At least 50% lower than the discovery baseline|Measured across comparable bids|
|**Stale-reference rate**|Below 10% of active records after stabilization|Records beyond their review date|
|**Submission traceability**|100% of exported packs linked to an opportunity, version, approver, and timestamp|Audit-log validation|

# 5. MVP Scope and Functional Requirements

|   |   |   |   |
|---|---|---|---|
|**ID**|**Priority**|**Requirement**|**Acceptance criteria**|
|**REF-01**|Must|Create and maintain a canonical customer/project reference with structured commercial, contractual, technical, delivery, and outcome data.|A reusable record cannot be published until all mandatory fields, owner, source evidence, confidentiality class, and review date are present.|
|**REF-02**|Must|Support controlled statuses: Draft, Under Validation, Approved, Approved with Restrictions, Expired, and Withdrawn.|Only appropriately authorized roles can change status; every transition records actor, date, rationale, and resulting restrictions.|
|**IMP-01**|Should|Import or synchronize candidate data from CRM, contract repositories, project systems, spreadsheets, and past tender content.|Imported records retain provenance, map fields visibly, flag conflicts, and never overwrite validated values silently.|
|**QUAL-01**|Must|Capture tender reference criteria, including sector, country, customer type, scope, technology, service, dates, duration, contract value, language, certifications, and required evidence.|Each criterion is typed as mandatory or scored and includes an operator, target value, unit, and explanatory note.|
|**MATCH-01**|Must|Match and rank references against tender criteria.|Each candidate shows pass, fail, or review needed per criterion, with the underlying field or evidence and no unsupported certainty.|
|**SHORT-01**|Must|Create an opportunity-specific shortlist and assign validation actions.|The shortlist records selected and rejected references, rationale, owner, due date, status, and comments.|
|**APP-01**|Must|Manage authorization to disclose customer identity, logo, contact person, project details, values, and supporting documents.|Authorization includes scope, approver, evidence, effective date, expiry date, conditions, and allowed opportunities or territories.|
|**APP-02**|Must|Block export when a required approval is missing, expired, or incompatible with the intended disclosure.|The export check lists every blocker and permits override only to an authorized role with mandatory justification.|
|**EVD-01**|Must|Attach and classify contracts, acceptance certificates, customer attestations, purchase orders, invoices, project summaries, and contact confirmations.|Each document has type, version, source, date, confidentiality, validity, and access permissions.|
|**GEN-01**|Must|Generate tender-specific reference sheets from approved data and templates.|Generated content identifies its source fields, applies disclosure restrictions, and can be regenerated without changing the canonical record.|
|**GEN-02**|Should|Assemble a reference evidence pack for a lot, selection criterion, or award criterion.|The pack contains selected sheets and authorized evidence with an index, version, opportunity ID, and generation timestamp.|
|**SEA-01**|Must|Search and filter the portfolio by customer, sector, geography, capability, technology, service, dates, value, status, approval, evidence, and prior use.|Filters can be combined, saved, shared according to role, and exported with the result set.|
|**GOV-01**|Must|Assign data owners and periodic review cycles.|Owners receive review tasks before expiry; overdue records are visibly stale and excluded from automatic recommendation unless explicitly included.|
|**AUD-01**|Must|Maintain immutable audit history for sensitive changes, approvals, exports, and tender use.|Authorized users can trace who used which record version, for which opportunity, when, and under which approval.|
|**REP-01**|Should|Report portfolio coverage and gaps.|Dashboards show reusable references by sector, capability, geography, value band, age, evidence status, and upcoming expiry.|
|**SEC-01**|Must|Apply role-based access and field/document-level restrictions for confidential and personal data.|Permissions are enforced in views, search, export, API access, and audit retrieval.|

## 5.1 Core User Stories

·         As a bid manager, I want to translate tender requirements into structured criteria so that every proposed reference can be justified.

·         As a bid manager, I want a ranked shortlist with criterion-level evidence so that I can focus review effort on genuine gaps.

·         As an account manager, I want to control what may be disclosed about my customer so that the bid does not damage the relationship or breach an obligation.

·         As a delivery owner, I want to validate project facts and supporting evidence so that claims remain accurate and defensible.

·         As a compliance reviewer, I want exports blocked when authorization is insufficient so that restricted information is not submitted accidentally.

·         As a data steward, I want expiry alerts and duplicate detection so that the portfolio remains trustworthy.

·         As a sales leader, I want to see coverage gaps so that future projects can be documented strategically.

# 6. Information Architecture and Data Model

|   |   |
|---|---|
|**Entity**|**Purpose and essential attributes**|
|**Reference**|Stable ID, customer, project or contract title, description, legal entities, sector, geography, dates, duration, status, value and currency, scope, technologies, services, outcomes, owner, quality score, review date.|
|**Customer organization**|Legal and display names, public/private classification, country, sector, account owner, confidentiality constraints, logo-use status.|
|**Customer contact**|Name, role, business contact details, preferred language, consent or authorization scope, validity, contact protocol, access restrictions.|
|**Capability and taxonomy term**|Controlled vocabulary for services, technologies, products, sectors, procurement categories, certifications, delivery models, and outcomes.|
|**Evidence document**|Type, file or link, source, version, date, validity, language, confidentiality, verified facts, checksum, access rights.|
|**Approval**|Disclosure category, scope, approver, evidence, conditions, territory, opportunity limitations, effective and expiry dates, status.|
|**Tender opportunity**|Opportunity ID, contracting authority, title, lots, procedure, geography, language, submission deadline, owner, source-system link.|
|**Reference criterion**|Opportunity or lot, mandatory/scored status, field, operator, target, unit, period, evidence requirement, weighting, interpretation note.|
|**Match assessment**|Reference, criterion, result, score, evidence, reviewer, rationale, exception, timestamp.|
|**Shortlist and usage**|Opportunity, lot, selected reference version, purpose, decision, approvers, generated outputs, final submission status.|
|**Template**|Reference-sheet type, language, placeholders, conditional clauses, branding, version, owner, approval state.|
|**Audit event**|Actor, action, target, before/after version, opportunity context, timestamp, outcome, security context.|

# 7. Key User Flows

1.      **Onboard and govern:** configure taxonomies, roles, approval categories, review cycles, templates, and source-system mappings.

2.      **Create and validate a reference:** import or enter project data; assign owners; attach evidence; validate facts; classify confidentiality; obtain disclosure approval; publish for reuse.

3.      **Qualify a tender:** create or synchronize the opportunity; capture reference criteria by lot; mark them mandatory or scored; define interpretation and evidence expectations.

4.      **Match and shortlist:** run matching; inspect criterion-level results; resolve unknowns; compare candidates; select primary and fallback references.

5.      **Approve and generate:** request missing customer or internal approvals; complete the pre-export control; generate localized reference sheets and evidence packs.

6.      **Submit and trace:** freeze the used record versions; record the final pack and submission outcome; retain a complete audit link to the opportunity.

7.      **Maintain the portfolio:** review expiring records, withdraw invalid references, consolidate duplicates, and analyze capability coverage gaps.

# 8. Non-Functional Requirements

|   |   |
|---|---|
|**Area**|**Requirement**|
|**Performance**|Search and filtering should remain responsive across the expected enterprise portfolio; shortlist generation should complete quickly enough for live bid workshops, with scale targets finalized from discovery data.|
|**Reliability**|Imports, approval actions, generation, and exports must be resumable or safely repeatable; no validated record version or audit event may be lost silently.|
|**Availability**|Define a service objective that covers tender deadline periods, with communicated maintenance windows and a documented continuity procedure.|
|**Security**|Encrypt data in transit and at rest; enforce least privilege, strong session controls, malware scanning, dependency management, event logging, and tested incident response.|
|**Privacy**|Minimize customer-contact and project personal data; enforce purpose limitation, retention, correction, deletion, restricted export, and documented lawful handling where applicable.|
|**Confidentiality**|Support field- and document-level classification, need-to-know access, watermarking or labeling of generated outputs where configured, and prevention of unauthorized inclusion in exports.|
|**Accessibility**|Core workflows must meet WCAG 2.2 AA, including keyboard operation, visible focus, labels, contrast, error announcements, and zoom support.|
|**Localization**|Support Unicode data, multilingual reference descriptions and templates, locale-aware dates, numbers, and currencies, and clear distinction between translated and source-language content.|
|**Interoperability**|Use stable identifiers, documented APIs and mappings, and portable exports; preserve provenance and identify any lossy transformation.|
|**Auditability**|Retain tamper-evident history for validation, approval, sensitive access, generation, export, override, withdrawal, and opportunity use according to policy.|
|**Observability**|Monitor service health, integration failures, stale data, approval delays, matching uncertainty, generation failures, and access anomalies without exposing sensitive content in logs.|

# 9. Integrations and Extensibility

·         **CRM:** synchronize customers, opportunities, account owners, contract values, and source identifiers while preserving system-of-record ownership.

·         **Document and contract repositories:** link or ingest controlled evidence, metadata, permissions, and retention labels.

·         **Project and service-management systems:** retrieve delivery dates, scope, milestones, service levels, and validated outcomes.

·         **Identity and access management:** support enterprise single sign-on, group-based roles, least privilege, and joiner/mover/leaver controls.

·         **Proposal workspace:** export structured data and generated reference sheets to the approved tender collaboration environment.

·         **Notifications and tasks:** issue review, approval, expiry, and deadline reminders through configured enterprise channels.

·         **API:** provide governed read/write access with scoped permissions, versioning, rate limits, and full auditability.

# 10. Delivery Approach and Release Criteria

|   |   |   |
|---|---|---|
|**Phase**|**Outcome**|**Indicative scope**|
|**Discovery**|Validated procurement workflows, governance, and data sources|Bid-team interviews, reference inventory, tender-criteria analysis, approval mapping, data classification, integration assessment.|
|**Alpha**|End-to-end controlled reference workflow|Canonical records, evidence, statuses, search, manual criteria, matching rationale, shortlist, basic template generation.|
|**Private beta**|Real tender use with governance|Approvals, expiry, audit, role restrictions, CRM import, evidence packs, multilingual templates, portfolio dashboard.|
|**Production MVP**|Deadline-safe operational service|Security hardening, backup and restore, enterprise identity, submission traceability, support procedures, quality and performance targets.|
|**Post-MVP**|Broader automation and intelligence|Criteria extraction from tender documents, additional source systems, semantic matching with explainability, outcome analytics, API ecosystem.|

## 10.1 MVP Release Gate

·         All Must requirements pass acceptance tests using representative tender scenarios and data.

·         No unresolved critical or high-severity security vulnerabilities.

·         Every generated pack passes the approval, confidentiality, personal-data, evidence-validity, and completeness controls.

·         Backup restoration and export of canonical records, evidence metadata, approvals, and audit history are successfully tested.

·         CRM import, criteria matching, search, generation, and access-control targets are met during beta.

·         Data owners, approval authorities, support boundaries, retention rules, and incident procedures are formally assigned.

·         Known matching limitations and all override paths are documented and visible to users.

# 11. Risks and Mitigations

|   |   |   |
|---|---|---|
|**Risk**|**Impact**|**Mitigation**|
|**Outdated or overstated reference data**|Disqualification, clarification requests, or reputational harm|Named owners, evidence-backed fields, expiry, versioning, review workflows, and visible quality scores.|
|**Unauthorized customer disclosure**|Contractual, privacy, and relationship damage|Granular approvals, field-level restrictions, export blocking, expiry controls, and auditable overrides.|
|**Ambiguous tender criteria**|False-positive matching and weak qualification|Require typed criteria, reviewer interpretation, explainable results, and human confirmation.|
|**Integration data conflicts**|Loss of trust in the canonical record|Define system-of-record ownership by field, preserve provenance, flag differences, and prohibit silent overwrite.|
|**Evidence unavailable near deadline**|Reference cannot be used in time|Track evidence readiness, maintain fallback references, alert owners early, and expose portfolio gaps.|
|**Personal data retained or shared excessively**|Compliance and security exposure|Data minimization, lawful-purpose review, restricted contact fields, retention rules, and export controls.|
|**Overreliance on automated ranking**|Inappropriate reference selection|Show criterion-level reasoning and source evidence; retain mandatory human approval for shortlist and export.|
|**Over-broad MVP**|Delayed deployment and weak adoption|Prioritize trusted records, matching, approval, generation, and audit before advanced extraction or analytics.|

# 12. Open Decisions for Product Discovery

1.      Which reference types are required: customer projects, contracts, staff CV references, certificates, partner references, or all of these?

2.      Which sectors, procurement regimes, countries, languages, and tender templates define the initial scope?

3.      Which system is authoritative for customer, opportunity, contract, delivery, and contact data?

4.      Which fields and evidence are mandatory before a reference becomes reusable?

5.      Who can validate facts, approve customer disclosure, grant exceptions, and withdraw a reference?

6.      Must the platform manage customer approval requests directly, or only record approvals obtained elsewhere?

7.      How are turnover, contract value, delivery period, consortium share, subcontracting share, and framework call-offs represented?

8.      Should matching operate separately by lot, selection criterion, award criterion, and exclusion condition?

9.      Which output formats and proposal-workspace integrations are launch-critical?

10. What retention, data residency, confidentiality, personal-data, and audit obligations apply?

11. What matching volume, portfolio size, concurrent bid load, and deadline peaks must the service support?

12. Which reports are required for management: usage, win contribution, coverage gaps, approval lead time, or reference ageing?

# 13. Discovery Research Plan

·         Interview bid managers, account managers, delivery owners, data stewards, legal/privacy reviewers, and sales leaders; observe at least three real reference-selection workflows.

·         Sample recent tender documents and classify their reference criteria, evidence demands, lot structures, languages, and evaluation methods.

·         Inventory current reference sources, spreadsheets, CRM fields, proposal libraries, approval evidence, and ownership gaps.

·         Prototype criterion capture, explainable matching, shortlist comparison, approval control, and reference-sheet generation with representative data.

·         Measure the baseline time to find, validate, approve, and package references; record common failure and rework causes.

·         Define the canonical data model, field ownership, taxonomy, approval matrix, retention model, and migration approach.

·         Convert validated findings into ranked requirements, integration decisions, an MVP estimate, and a pilot plan tied to live tender activity.