# Opportunity Qualification (Bid/No-Bid): [Opportunity name]

> Qualification record for a sales or tender opportunity, written by the
> pursuit team before significant bid effort is spent. It scores strategic
> fit, customer access, solution fit, competitive position, commercial
> viability and delivery risk, estimates the cost of bidding, and records a
> Bid, Bid with conditions, Defer or No-bid decision with named owners. The
> structure follows common capture and bid decision practice as taught by
> the Association of Proposal Management Professionals (APMP Body of
> Knowledge, topics on opportunity qualification and the bid/no-bid
> decision) and is written from the point of view of the solution architect
> who must say whether the company can credibly design, price and deliver a
> winning solution. Replace every `[bracketed]` value and every row marked
> *Example*.

<!--
Guidance: How to use this template
- Start this record the day the opportunity is identified, not the day the
  RFP arrives. Qualification is a series of gates; each gate updates the
  same file and adds a revision row.
- Score from evidence, not from optimism. Every score of 4 or 5 needs a
  line in the evidence column that a sceptical reviewer can check.
- Knock-out criteria (section 11.1) override the weighted score. A single
  failed knock-out means No-bid, unless the decision owner records a
  strategic exception (section 12) or a condition removes the knock-out
  before Gate 2.
- The solution architect owns sections 5, 9 and the technical part of 10;
  the account or capture lead owns sections 3, 6 and 7; finance owns
  section 8. The decision owner signs section 12.
- Related documents: RFI (`business/rfi`), RFP (`business/rfp`), RFP
  Technical Response (`business/rfp-technical-response`), RFP Compliance
  Matrix (`business/rfp-compliance-matrix`), Solution Estimate
  (`project/solution-estimate`), SWOT (`business/swot`), Solution Options
  Analysis (`architecture/solution-options-analysis`), Statement of Work
  (`business/statement-of-work`), RAID Log (`project/raid-log`).
-->

## Document control

<!-- Guidance: Identify the opportunity and the gate this version supports. A new gate decision is a new minor version; a change of decision is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [OPP-QUAL-001] |
| Opportunity ID (CRM) | [CRM reference] |
| Customer | [Customer legal name] |
| Version | [0.1] |
| Status | [Draft / In review / Decided / Superseded] |
| Current gate | [Gate 0 Pursue / Gate 1 Bid / Gate 2 Submit] |
| Owner | [@capture-lead] |
| Solution architect | [@solution-architect] |
| Approvers/reviewers | [@sales-director], [@delivery-director], [@finance-partner], [@legal-counsel] |
| Decision owner | [@decision-owner] |
| Last updated | YYYY-MM-DD |
| Classification | [Confidential: commercial in confidence] |
| Related documents | [Account plan], [Capture plan], [RFP reference] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Decision owner | [@name] | [Bid / Bid with conditions / Defer / No-bid] | YYYY-MM-DD |
| Sales director | [@name] | [Support / Object] | YYYY-MM-DD |
| Delivery director | [@name] | [Support / Object] | YYYY-MM-DD |
| Finance | [@name] | [Support / Object] | YYYY-MM-DD |
| Legal and contracts | [@name] | [Support / Object] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft at Gate 0 |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Updated after RFP release; scorecard re-run at Gate 1 |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Decision recorded: Bid with conditions |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Opportunity summary](#1-opportunity-summary)
2. [Qualification gates](#2-qualification-gates)
3. [Customer and buying context](#3-customer-and-buying-context)
4. [Strategic fit](#4-strategic-fit)
5. [Solution fit and capability gaps](#5-solution-fit-and-capability-gaps)
6. [Competitive position](#6-competitive-position)
7. [Win probability factors](#7-win-probability-factors)
8. [Commercial viability](#8-commercial-viability)
9. [Delivery risk](#9-delivery-risk)
10. [Bid cost and resource ask](#10-bid-cost-and-resource-ask)
11. [Weighted scorecard](#11-weighted-scorecard)
12. [Decision and conditions](#12-decision-and-conditions)
13. [Actions and capture handoff](#13-actions-and-capture-handoff)
14. [Post-decision review](#14-post-decision-review)
15. [Glossary and references](#15-glossary-and-references)

## 1. Opportunity summary

<!-- Guidance: One screen that lets an executive understand the opportunity in two minutes. Questions: what is being bought, by whom, for how much, by when, and through which procurement route? Pitfall: copying the customer's marketing language instead of stating the actual scope. -->

| Field | Value |
|---|---|
| Opportunity name | [Name] |
| Customer and business unit | [Customer], [Division] |
| Sector and region | [Sector], [Country or region] |
| What the customer wants to buy | *Example:* Replacement of a 15-year-old claims platform with a configurable SaaS product, including data migration and five integrations |
| Why now (compelling event) | *Example:* Current vendor ends support on YYYY-MM-DD; regulator finding requires audit trail improvements |
| Estimated total contract value (TCV) | *Example:* USD 4,800,000 over 3 years |
| Contract type | [Fixed price / Time and materials / Managed service / Subscription plus services] |
| Procurement route | [Direct award / Competitive RFP / Framework call-off / Public tender] |
| Source of the opportunity | [Existing account / Partner referral / Public notice / Inbound] |
| Key dates | RFI YYYY-MM-DD, RFP release YYYY-MM-DD, submission YYYY-MM-DD, award YYYY-MM-DD, start YYYY-MM-DD |
| Our relationship status | [Incumbent / Existing customer, new area / New logo] |
| Partners or subcontractors | [Partner name and role] |

**Opportunity statement:** In two or three sentences, state the customer
problem, the outcome they expect, and why the company is or is not a
natural supplier. Write it so that someone outside the account team can
judge whether the pursuit makes sense.

## 2. Qualification gates

<!-- Guidance: Decide the gates in advance and record which one this version supports. Questions: what evidence is required at each gate, and who can stop the pursuit? Pitfall: holding one meeting after the RFP lands and calling it qualification. -->

Qualification is continuous. The same record is reviewed at each gate, the
scorecard is re-run with new evidence, and the decision can change. A
pursuit that keeps passing gates only because effort has already been
spent is a sunk-cost decision; the gate owner must be able to stop it.

```mermaid
flowchart LR
  ID[Opportunity identified] --> G0{Gate 0<br/>Pursue?}
  G0 -->|No| X0[Record and close]
  G0 -->|Yes| CAP[Capture: shape need,<br/>meet stakeholders]
  CAP --> G1{Gate 1<br/>Bid?}
  G1 -->|No-bid| X1[Inform customer,<br/>record lessons]
  G1 -->|Defer| CAP
  G1 -->|Bid or Bid with conditions| BID[Prepare response]
  BID --> G2{Gate 2<br/>Submit?}
  G2 -->|Conditions unmet| X2[Withdraw]
  G2 -->|Approved| SUB[Submit]
  SUB --> PDR[Post-decision review]
```

| Gate | Timing | Question | Minimum evidence | Decision owner |
|---|---|---|---|---|
| Gate 0 Pursue *(Example)* | When the opportunity is first identified | Is this worth investing capture effort in? | Opportunity summary, strategic fit, initial customer contact | Sales director |
| Gate 1 Bid *(Example)* | On RFP release or when the scope is firm | Should we prepare a full response? | Sections 3 to 11 complete, solution concept, rough estimate | Business unit head |
| Gate 2 Submit *(Example)* | Before final pricing is released | Is the response compliant, priced and deliverable? | Compliance matrix, approved estimate, risk register, legal review | Business unit head and finance |
| [Gate] | [Timing] | [Question] | [Evidence] | [@owner] |

## 3. Customer and buying context

<!-- Guidance: Show that the team understands how this customer will decide. Questions: who signs, who influences, what do they each care about, and how will responses be evaluated? Pitfall: knowing only the procurement contact. -->

### 3.1 Need and drivers

| Driver ID | Business driver | Evidence | Source |
|---|---|---|---|
| DRV-001 *(Example)* | Regulator requires a complete audit trail of claim decisions within 18 months | Published supervisory letter, discussed with the head of compliance | Meeting YYYY-MM-DD |
| DRV-002 *(Example)* | Reduce cost to process a claim | Annual report states a cost reduction target | Public filing |
| DRV-003 *(Example)* | Current platform vendor exits the market | Vendor notice shared by customer IT | Email YYYY-MM-DD |
| [DRV-NNN] | [Driver] | [Evidence] | [Source] |

### 3.2 Budget and funding

| Question | Answer | Confidence |
|---|---|---|
| Is the budget approved, and at what amount? | *Example:* Capital budget approved for the current financial year; amount not disclosed, estimated from the business case range | Medium |
| Which budget line pays (capital, operating, shared)? | [Answer] | [High / Medium / Low] |
| Is funding conditional on another event? | [Answer] | [Confidence] |

### 3.3 Decision process and stakeholders

| Stakeholder | Role in decision | Main concern | Our access | Attitude to us |
|---|---|---|---|---|
| *Example:* Chief Operating Officer | Economic buyer, signs the contract | Cost per claim and delivery certainty | One meeting in the last 6 months | Neutral |
| *Example:* Head of Claims | Business sponsor and main user | Adjuster productivity during transition | Regular contact | Supportive |
| *Example:* Chief Information Officer | Technical approver | Integration with the policy system, cloud policy compliance | Through partner only | Unknown |
| *Example:* Procurement lead | Runs the evaluation | Compliant, comparable responses | Formal channel only | Neutral |
| [Name or role] | [Economic buyer / Technical approver / User / Influencer / Gatekeeper] | [Concern] | [Access] | [Supportive / Neutral / Opposed / Unknown] |

Record the full engagement plan in the Stakeholder Register
(`project/stakeholder-register`) once the pursuit passes Gate 0.

### 3.4 Evaluation criteria and timeline

| Item | Known value | Source |
|---|---|---|
| Published evaluation weighting | *Example:* Technical 50 %, price 30 %, social value and delivery 20 % | Draft RFP |
| Mandatory requirements known so far | [Number and summary] | [Source] |
| Evaluation method | [Points-based / Pass-fail plus price / Best value] | [Source] |
| Presentations or demonstrations | [Yes, date / No] | [Source] |
| Contract start and first milestone | [Dates] | [Source] |

## 4. Strategic fit

<!-- Guidance: Test the opportunity against company strategy, not just against the sales target. Questions: would we be glad to have this customer and this work in two years? Does it build a reference or a capability we want? Pitfall: treating every revenue line as strategic. -->

| Question | Assessment | Evidence |
|---|---|---|
| Is the sector and region a target market in the current plan? | *Example:* Yes, insurance is one of three priority sectors | Annual sales plan |
| Does the work use offerings we want to grow? | *Example:* Yes, SaaS implementation and managed integration service | Offering roadmap |
| Will a win create a referenceable customer? | *Example:* Likely; customer allows case studies after go-live | Previous contract |
| Does it open follow-on work? | *Example:* Phase 2 policy administration replacement planned | Customer roadmap presentation |
| Does it conflict with another customer, partner or bid? | *Example:* No conflict found | Conflict check YYYY-MM-DD |
| Does it carry reputational or ethical concerns? | [Assessment] | [Evidence] |
| What is the opportunity cost (what else would this team work on)? | [Assessment] | [Evidence] |

## 5. Solution fit and capability gaps

<!-- Guidance: The solution architect's core section. Questions: can we design a credible, compliant solution from what we already have? Where are the gaps, and how would we close them? Pitfall: assuming a gap can be closed by "partnering" without a named partner. -->

### 5.1 Requirement coverage

Read the RFP, RFI or the customer's statement of need and classify every
known requirement before scoring. Use the RFP Compliance Matrix
(`business/rfp-compliance-matrix`) once the formal document is released.

| Coverage class | Count | Share | Comment |
|---|---|---|---|
| Fully met by existing product or service *(Example)* | 142 | 71 % | Standard configuration |
| Met with configuration or minor extension *(Example)* | 38 | 19 % | Estimated in solution estimate |
| Met by a partner *(Example)* | 12 | 6 % | Document capture partner |
| Not met *(Example)* | 8 | 4 % | See section 5.2 |
| Total *(Example)* | 200 | 100 % | |

### 5.2 Capability gaps

| Gap ID | Requirement or capability | Gap description | Closure option | Cost or effort to close | Residual risk |
|---|---|---|---|---|---|
| GAP-001 *(Example)* | Data residency in the customer's country | Our SaaS region is outside the country | Use provider region launched last year; confirm product certification | 4 weeks product work | Medium |
| GAP-002 *(Example)* | Real-time integration with the legacy policy system | No adapter for the policy system's message format | Build adapter on the integration platform | 60 person-days | Medium |
| GAP-003 *(Example)* | Native-language user interface | Product supports 8 languages, not the required one | Partner translation, customer review | USD 30,000 | Low |
| [GAP-NNN] | [Requirement] | [Gap] | [Build / Partner / Roadmap / Negotiate out / Accept] | [Cost] | [L / M / H] |

### 5.3 Solution concept readiness

| Question | Answer |
|---|---|
| Is there a reference architecture or a previous implementation we can reuse? | *Example:* Yes, two similar implementations in the last three years |
| Are the critical non-functional requirements (availability, performance, security, residency) achievable with the standard platform? | [Answer, with any exceptions] |
| Is a proof of concept or demonstration likely to be required? | [Answer; if yes, plan with Proof of Concept (`architecture/proof-of-concept`) and Demo Script (`business/demo-script`)] |
| Are there credible alternative solution options? | [Answer; record them in Solution Options Analysis (`architecture/solution-options-analysis`)] |
| Which named architects and specialists are available to design and deliver? | [Names and availability] |

## 6. Competitive position

<!-- Guidance: Be honest about who else is bidding and why the customer would choose them. Questions: who is the incumbent, what will each competitor lead with, and what genuinely sets us apart? Pitfall: listing discriminators that every competitor can also claim. -->

| Competitor | Likely solution | Strengths in this deal | Weaknesses in this deal | Likely price position |
|---|---|---|---|---|
| *Example:* Incumbent vendor | Upgrade of the current platform | Knows the data and processes, low switching effort | End-of-support notice damaged trust | Lower |
| *Example:* Global integrator | Market-leading suite with heavy customisation | Brand, large team | Long timelines, high day rates | Higher |
| *Example:* Niche local supplier | Local product | Local language and presence | Limited scale, no SaaS certification | Lower |
| [Competitor] | [Solution] | [Strengths] | [Weaknesses] | [Lower / Similar / Higher] |

### 6.1 Discriminators

| Discriminator | Why it matters to this customer | Proof we can offer | Can competitors match it? |
|---|---|---|---|
| *Example:* Prebuilt audit trail meeting the regulator's requirement | Directly addresses DRV-001 | Reference customer audited last year | Partly; the incumbent needs an upgrade |
| *Example:* Fixed-price data migration with reconciliation evidence | Removes the customer's biggest transition fear | Two prior migrations of similar size | No evidence that they can |
| [Discriminator] | [Driver it addresses] | [Proof] | [Yes / Partly / No] |

### 6.2 Price to win

| Item | Value | Basis |
|---|---|---|
| Customer budget estimate | *Example:* USD 4,500,000 to 5,200,000 | Business case range shared informally |
| Expected winning price range | *Example:* USD 4,400,000 to 4,900,000 | Competitor analysis, previous public awards |
| Our expected price at target margin | *Example:* USD 4,800,000 | Rough estimate, section 8 |
| Gap and actions to close it | [Gap] | [Scope options, delivery model, partner pricing] |

## 7. Win probability factors

<!-- Guidance: Answer each question with evidence and a simple Yes, Partly or No. These answers feed the scorecard and keep it honest. Pitfall: answering "Yes" because the account manager has a good feeling. -->

| ID | Factor | Answer | Evidence |
|---|---|---|---|
| WPF-01 | Have we met the economic buyer in the last six months? | *Example:* Partly | One introductory meeting, no follow-up |
| WPF-02 | Did we influence the requirements before the RFP was written? | *Example:* Partly | Our RFI answer shaped the audit trail requirement |
| WPF-03 | Does the customer understand our discriminators? | *Example:* Yes | Head of Claims repeated them in the last meeting |
| WPF-04 | Is there an internal champion who will argue for us? | *Example:* Yes | Head of Claims |
| WPF-05 | Do we know the evaluation criteria and their weights? | *Example:* Yes | Draft RFP |
| WPF-06 | Is our solution compliant with every mandatory requirement? | *Example:* Partly | GAP-001 open |
| WPF-07 | Is our likely price within the expected winning range? | *Example:* Yes | Section 6.2 |
| WPF-08 | Do we have a relevant, referenceable customer? | *Example:* Yes | Two in the same sector |
| WPF-09 | Is the incumbent vulnerable? | *Example:* Yes | End-of-support notice |
| WPF-10 | Is the procurement genuinely open (not written for one supplier)? | *Example:* Yes | Requirements are product-neutral |
| [WPF-NN] | [Factor] | [Yes / Partly / No] | [Evidence] |

**Estimated win probability:** *Example:* 35 %. State how the estimate was
reached (factor count, comparable past bids, independent review), and do
not present it as more precise than the evidence allows.

## 8. Commercial viability

<!-- Guidance: Show whether a win is worth having. Questions: what margin, cash flow and contractual exposure would we accept? Pitfall: approving a bid on revenue alone and discovering after award that the contract terms make it unprofitable. -->

### 8.1 Deal economics

| Item | Value | Note |
|---|---|---|
| Total contract value (TCV) | *Example:* USD 4,800,000 | 3 years, subscription plus services |
| Estimated delivery and run cost | *Example:* USD 3,600,000 | From rough order of magnitude estimate in Solution Estimate (`project/solution-estimate`) |
| Gross margin | *Example:* USD 1,200,000 (25 %) | 4,800,000 minus 3,600,000; 1,200,000 divided by 4,800,000 |
| Company minimum margin for this offering | *Example:* 20 % | Pricing policy |
| Cash flow profile | *Example:* Milestone payments; negative cash position for the first 7 months | Finance model |
| Payment terms | [Terms] | [Note] |
| Currency and inflation exposure | [Exposure] | [Note] |
| Third-party costs and pass-through | [Licences, hosting, partners] | [Note] |

### 8.2 Contract and legal exposure

| Topic | Known position | Acceptable to us? | Action |
|---|---|---|---|
| Liability cap | *Example:* Customer draft proposes unlimited liability for data breaches | No | Propose cap at 12 months of fees, with insurance evidence |
| Service credits | *Example:* Up to 15 % of monthly fees | Yes | None |
| Intellectual property | [Position] | [Yes / No / Negotiable] | [Action] |
| Termination for convenience | [Position] | [Yes / No / Negotiable] | [Action] |
| Data protection and residency terms | [Position] | [Yes / No / Negotiable] | [Action] |
| Acceptance criteria and warranty | [Position] | [Yes / No / Negotiable] | [Action] |

### 8.3 Expected value check

Expected value is a sanity check, not a decision rule. *Example:* win
probability 35 % multiplied by gross margin USD 1,200,000 gives USD
420,000; subtracting the bid cost of USD 90,000 (section 10) gives an
expected value of USD 330,000. If the expected value is negative or close
to zero, the pursuit needs a strategic reason recorded in section 4.

## 9. Delivery risk

<!-- Guidance: The solution architect and delivery director judge whether the company can deliver what it would promise. Questions: what could make delivery fail or lose money, and can the risk be priced, mitigated or transferred? Pitfall: leaving delivery risk for the delivery team to discover after award. -->

| Risk ID | Category | Risk | Likelihood | Impact | Mitigation or pricing response | Owner |
|---|---|---|---|---|---|---|
| QR-001 *(Example)* | Technical | Legacy policy system has no documented interface; adapter effort may double | Medium | High | Fund a two-week technical discovery before fixed price; include assumption in the response | @solution-architect |
| QR-002 *(Example)* | Data | Source data quality unknown; migration effort uncertain | High | High | Price data cleansing as time and materials; offer a data profiling sprint | @data-lead |
| QR-003 *(Example)* | Schedule | Customer's go-live date leaves 9 months for a 12-month typical project | Medium | High | Propose phased go-live; state critical dependencies | @delivery-director |
| QR-004 *(Example)* | Resourcing | Two key product specialists committed to another programme until Q3 | Medium | Medium | Confirm release dates or hire contractors | @resource-manager |
| QR-005 *(Example)* | Regulatory | Residency certification for the new region not yet complete | Low | High | Confirm certification date in writing from product team | @product-manager |
| [QR-NNN] | [Category] | [Risk] | [L / M / H] | [L / M / H] | [Response] | [@owner] |

Carry accepted risks and assumptions into the RAID Log (`project/raid-log`)
and the response's assumptions list, so that the delivery team inherits
them at contract signature.

## 10. Bid cost and resource ask

<!-- Guidance: Make the cost of bidding visible so that the decision owner sees what the company is investing. Questions: who is needed, for how long, and what will not get done while they bid? Pitfall: counting only the bid manager's time. -->

| Role | Name | Effort (days) | Period | Released by |
|---|---|---|---|---|
| Bid or proposal manager *(Example)* | [@name] | 25 | YYYY-MM-DD to YYYY-MM-DD | Bid office |
| Solution architect *(Example)* | [@name] | 30 | Same | Architecture practice |
| Technical specialists (integration, data, security) *(Example)* | [@names] | 20 | Same | Delivery |
| Commercial and pricing *(Example)* | [@name] | 8 | Same | Finance |
| Legal and contracts *(Example)* | [@name] | 5 | Same | Legal |
| Executive sponsor *(Example)* | [@name] | 2 | Same | Business unit |
| Total *(Example)* | | 90 | | |

| Cost item | Value |
|---|---|
| Internal effort *(Example)* | 90 days at an internal cost of USD 1,000 per day = USD 90,000 |
| Proof of concept or demonstration environment | [Cost] |
| Travel and presentation costs | [Cost] |
| Partner contributions | [Cost or in kind] |
| Total bid cost | *Example:* USD 90,000 internal effort plus [other costs]; the expected value check in section 8.3 uses the internal effort only |

## 11. Weighted scorecard

<!-- Guidance: Combine the evidence above into one comparable number. Agree the weights for the business unit once and reuse them, so that bids can be compared. Questions: which knock-out criteria apply, and does the weighted score clear the threshold? Pitfall: changing weights to make a favoured opportunity pass. -->

### 11.1 Knock-out criteria

| ID | Knock-out criterion | Result | Evidence |
|---|---|---|---|
| KO-01 | We can meet every mandatory requirement, or the gap can be closed before submission | *Example:* Pass with action (GAP-001) | Section 5.2 |
| KO-02 | The contract terms are within company risk policy, or can be negotiated | *Example:* Pass with action (liability cap) | Section 8.2 |
| KO-03 | No legal, ethical, sanctions or conflict-of-interest barrier | *Example:* Pass | Conflict check |
| KO-04 | We have the people to write the bid and to deliver the work | *Example:* Pass with action (QR-004) | Section 10 |
| KO-05 | The submission date allows a quality response | *Example:* Pass | 6 weeks available |
| [KO-NN] | [Criterion] | [Pass / Pass with action / Fail] | [Evidence] |

### 11.2 Scoring scale

| Score | Meaning |
|---|---|
| 5 | Strong position, backed by documented evidence |
| 4 | Good position, evidence mostly in place |
| 3 | Neutral or mixed; evidence incomplete |
| 2 | Weak position; known disadvantage |
| 1 | Very weak position or no evidence |

### 11.3 Scorecard

Weighted score for each criterion is the weight multiplied by the score
divided by 5, so a perfect opportunity scores 100.

| ID | Criterion | Weight | Score (1 to 5) | Weighted | Evidence reference |
|---|---|---|---|---|---|
| QC-01 | Strategic alignment | 10 | *Example:* 4 | 8 | Section 4 |
| QC-02 | Customer relationship and access | 15 | *Example:* 2 | 6 | Section 3.3, WPF-01 |
| QC-03 | Requirement understanding and influence | 10 | *Example:* 3 | 6 | WPF-02, WPF-05 |
| QC-04 | Solution fit | 15 | *Example:* 4 | 12 | Section 5 |
| QC-05 | Competitive position and discriminators | 15 | *Example:* 3 | 9 | Section 6 |
| QC-06 | Commercial attractiveness | 15 | *Example:* 4 | 12 | Section 8 |
| QC-07 | Delivery risk (5 means low risk) | 10 | *Example:* 3 | 6 | Section 9 |
| QC-08 | Bid feasibility (time, team, cost) | 10 | *Example:* 4 | 8 | Section 10 |
| | **Total** | **100** | | **67** *(Example)* | |

### 11.4 Decision thresholds

| Weighted score | Default recommendation *(Example policy)* |
|---|---|
| 70 or more, every knock-out a clean Pass | Bid |
| 55 to 69, or any knock-out passed with action | Bid with conditions, or Defer until conditions are met |
| Below 55, or any knock-out failed | No-bid, unless the decision owner records a strategic exception |

*Example:* the score of 67 with three knock-outs passed with action gives a
default recommendation of Bid with conditions.

## 12. Decision and conditions

<!-- Guidance: Record the decision in words that cannot be misread later. Questions: what exactly was decided, under which conditions, and who checks them by when? Pitfall: a Bid with conditions whose conditions are never reviewed at Gate 2. -->

| Field | Value |
|---|---|
| Gate | [Gate 1 Bid] |
| Decision | [Bid / Bid with conditions / Defer / No-bid] |
| Decision date | YYYY-MM-DD |
| Decision owner | [@name] |
| Rationale | *Example:* Strong solution fit and an attractive margin outweigh weak access to the economic buyer; the conditions below must be met before Gate 2 |
| Strategic exception (if overriding the threshold) | [Reason, or "None"] |
| Dissenting views | [Name and view, or "None"] |

### 12.1 Conditions

| Condition ID | Condition | Owner | Due | Verified at |
|---|---|---|---|---|
| CON-001 *(Example)* | Secure a meeting with the Chief Operating Officer and the Chief Information Officer | @account-lead | YYYY-MM-DD | Gate 2 |
| CON-002 *(Example)* | Written confirmation of in-country hosting certification date (GAP-001) | @product-manager | YYYY-MM-DD | Gate 2 |
| CON-003 *(Example)* | Liability position approved by legal, with fallback | @legal-counsel | YYYY-MM-DD | Gate 2 |
| CON-004 *(Example)* | Named delivery lead and two product specialists confirmed for the start date | @resource-manager | YYYY-MM-DD | Gate 2 |
| [CON-NNN] | [Condition] | [@owner] | YYYY-MM-DD | [Gate] |

### 12.2 No-bid handling

When the decision is No-bid, tell the customer promptly and courteously,
give a short reason where appropriate, and say whether the company would
like to be considered for future work. A well-handled No-bid protects the
relationship and the company's reputation for bidding only when it can
deliver. Record the reason in section 14 so that the portfolio of No-bid
decisions can be reviewed.

## 13. Actions and capture handoff

<!-- Guidance: Turn the decision into work. Questions: who starts what tomorrow, and what does the response team inherit from qualification? Pitfall: the response team starting from a blank page and repeating the qualification research. -->

| Action ID | Action | Owner | Due | Status |
|---|---|---|---|---|
| ACT-001 *(Example)* | Open the response workspace and compliance matrix | @bid-manager | YYYY-MM-DD | Open |
| ACT-002 *(Example)* | Draft win themes from section 6.1 discriminators | @capture-lead | YYYY-MM-DD | Open |
| ACT-003 *(Example)* | Start the solution concept and options analysis | @solution-architect | YYYY-MM-DD | Open |
| ACT-004 *(Example)* | Prepare the rough order of magnitude estimate for Gate 2 | @estimator | YYYY-MM-DD | Open |
| [ACT-NNN] | [Action] | [@owner] | YYYY-MM-DD | [Open / Done] |

The response team inherits: the drivers (section 3.1), the stakeholder
map (3.3), the capability gaps and closure options (5.2), the
discriminators (6.1), the risks and assumptions (9), and the conditions
(12.1). Use them as the starting point for the RFP Technical Response
(`business/rfp-technical-response`) and its executive summary.

## 14. Post-decision review

<!-- Guidance: Close the loop after award or after a No-bid. Questions: was the qualification right, and what should change in the scorecard? Pitfall: reviewing only lost bids, so that the scorecard is never checked against wins. -->

| Field | Value |
|---|---|
| Outcome | [Won / Lost / Withdrawn / No-bid / Cancelled by customer] |
| Outcome date | YYYY-MM-DD |
| Customer feedback received | [Summary of debrief] |
| Winning supplier and price (if known) | [Name, price] |
| Was the qualification score predictive? | *Example:* Yes; access to the economic buyer was the deciding weakness, as scored |
| Scorecard or threshold change proposed | [Change, or "None"] |
| Lessons for the account plan | [Lesson] |

Feed lessons into Lessons Learned (`project/lessons-learned`) and review the
scorecard weights at least once a year against the business unit's win
rate by score band.

## 15. Glossary and references

<!-- Guidance: Define terms the reviewers may not share, and list the sources and internal policies used. -->

### 15.1 Glossary

| Term | Meaning |
|---|---|
| Bid/no-bid decision | The formal choice whether to invest in preparing a response |
| Capture | Work before the formal request that positions the company to win |
| Compelling event | The dated event that forces the customer to buy |
| Discriminator | A feature of our offer that matters to the customer and that competitors cannot easily match |
| Economic buyer | The person with authority to approve the spend |
| Knock-out criterion | A condition that, if failed, stops the bid regardless of score |
| Price to win | The price range judged likely to win given the competition and the customer's budget |
| TCV | Total contract value over the full term |
| Win theme | A short message linking a customer driver to our discriminator and proof |

### 15.2 References

| ID | Reference | Version or date | Use |
|---|---|---|---|
| REF-01 | APMP Body of Knowledge, Association of Proposal Management Professionals, bok.apmp.org (members) | Online edition, checked YYYY-MM-DD | Topic coverage for opportunity qualification and bid decisions |
| REF-02 | Company bid governance policy | [Version] | Gates, thresholds and approval authority |
| REF-03 | Company pricing and margin policy | [Version] | Section 8 |
| REF-04 | Customer RFI or RFP documents | [Reference] | Sections 3 and 5 |
| REF-05 | Solution Estimate (`project/solution-estimate`) | [Version] | Section 8.1 |
| REF-06 | [Other source] | [Version] | [Use] |

## Standard and licence note

Structure aligned with common capture and bid decision practice, including
the opportunity qualification and bid/no-bid topics of the APMP Body of
Knowledge (Association of Proposal Management Professionals), which is
available to members and is cited by topic only. No text, scoring model,
checklist or diagram from APMP or from any proposal management training
provider is reproduced; the criteria, weights, thresholds and examples in
this template are original and illustrative, and should be replaced by
your organisation's bid governance policy. Check the current APMP Body of
Knowledge and your internal policies before use. APMP is a trademark of
its owner; this template is not affiliated with or endorsed by it.
Template licence: MIT.