Use it in one evaluation meeting
- Define the buying scope. Put the project, proposed use, markets and supplier product in your saved copy. Adapt the suggested requirements before sending them to candidates.
- Set the acceptance conditions. Mark each requirement Mandatory, Optional or To define. Name the owner and the observable result that would satisfy it.
- Record supplier evidence. Use the requirement ID to join each claim to a dated document, version and observed test result. Duplicate evidence rows for more suppliers or tests.
- Make the decision explicit. Keep missing evidence as missing. An Accepted row needs supporting evidence and a recorded owner; it does not approve the entire supplier.
- Review unresolved gaps. A mandatory gap keeps the proposal unapproved. Record next steps and review dates instead of hiding failures inside an average score.
What is in the workbook
Requirements contains 12 editable starting questions, expected evidence and suggested acceptance conditions. Supplier evidence provides linked rows for the exact product, claim, evidence reference and date, actual result, decision, next action and owner. All supplier results begin unevaluated.
The workbook has no macros, supplier ranking, automatic endorsement or prefilled customer information. Its status fields are manual records. Keep commercial documents and personal data in your approved systems; use controlled references in the worksheet.
The 12 starting requirements
| Requirement | Evidence to request | Suggested acceptance condition |
|---|---|---|
| R01 · Market and use scope | Written scope for the exact product, territory, customer and distribution use. | The responsible owner confirms the intended use and records exclusions. |
| R02 · Product and version | Quoted package, deployed components, configuration and version references. | The demonstrated scope matches what the contract and rollout propose. |
| R03 · Data and identity mapping | Field definitions, stable identifiers, transformations and missing-value rules. | Representative synthetic records map correctly; exceptions are visible. |
| R04 · Repeat and delayed events | Supported test sequence with repeated, late and corrected events. | Expected state and economic effects occur once under the agreed rules. |
| R05 · Permissions and restrictions | Current roles, preference scope and applicable restriction propagation. | Authorised actions work; revoked or disallowed actions are denied. |
| R06 · Outage and recovery | Dependency map, supported recovery procedure and controlled rehearsal. | Recovery meets the agreed scope; remaining dependencies are explicit. |
| R07 · Security and data handling | Relevant controls, assessment scope, access, retention and deletion terms. | Responsible owners review the actual configuration and unresolved risks. |
| R08 · Operating workload and cost | Comparable volume assumptions, exception workload and complete quote. | Recurring, setup, support, change and exit costs have a stated basis. |
| R09 · Support and escalation | Coverage, severity definitions, contact route and decision responsibilities. | A rehearsal identifies the available owner and permitted response. |
| R10 · Change and regression testing | Change notice, version history and tests affected by material changes. | Changes reopen relevant acceptance checks before expanded use. |
| R11 · Exit and unfinished obligations | Sample export, supported exit procedure and pending-work inventory. | Agreed records remain readable and unfinished obligations have an owner. |
| R12 · Final decision and exceptions | Test observations, open gaps, named decision owner and review date. | Mandatory gaps are resolved or the proposal remains unapproved. |
Keep the result honest
Evidence requested means a question is still open. Test pending means the observation has not happened. Accepted is the responsible reviewer’s recorded decision for that requirement and scope. Not applicable needs a reason. None of these states demonstrates that IGW³ tested or approved a supplier.
This is an original editorial resource, not a regulatory checklist or certification standard. The linked guides explain the primary-source context and limits of specific technical and regulatory examples. No independent expert review is claimed.
You may adapt this original worksheet for your own buying process and share the resource link. Preserve the distinction between proposed tests and actual results. Revisit acceptance when the product, configuration, use or supporting evidence changes.
Read our evidence methodologyKeep building your evidence pack
The free IGW³ Briefing brings together source-linked buyer research. Read online, follow RSS or choose email updates separately from this download.
Free to read, with sources and dates. Add the RSS feed to your news reader to follow new editions.