Purpose and fit

Use this after the problem is understood and before a team commits to a sourcing route. The question is which option can support the required outcome within the organisation’s operating constraints. Include an existing capability and a manual approach so that the comparison does not assume a new purchase or build.

Define “build” carefully: a configured workflow, a small integration and a custom system have different responsibilities. Compare complete operating arrangements rather than attractive feature lists.

Before you start

Use your existing task requirements, tool inventory and dated option notes, quotations or approved product descriptions. Supply only information you are authorised to share. You can compare the routes for which you have evidence; missing price or capability fields should remain unresolved, not require a new dataset.

Expect an evidence-linked comparison and conditional next-step recommendation, not a purchase decision, verified integration claim or complete supplier evaluation. The same essential conditions should be applied across routes.

Required inputs

  • A bounded job, required outputs, acceptance conditions and intended users.
  • An inventory of relevant existing tools and reusable internal components, with their owners.
  • Verified descriptions of candidate capabilities, pricing assumptions and access requirements; record the source and date.
  • Available implementation skills, support capacity, delivery constraints and requirements for leaving or replacing an option.

Practical workflow

  1. Write one common job description for every option. Separate essential conditions from conveniences, and ask the affected team to confirm which failures would make an option unusable.
  2. Describe four routes where plausible: reuse, buy, build and continue manually. For each, name the work still required for integration, information preparation, review, support and maintenance.
  3. Check essential conditions first. Mark each as evidenced, unresolved or failed. An attractive feature or lower headline price cannot compensate for an unresolved condition that the owner treats as mandatory.
  4. Use the same sanitised example to explore the remaining routes. Record what was actually observed and what still depends on a demonstration, supplier assertion or unfinished internal component.
  5. Compare ownership over an agreed planning period. Include staff capacity, changes to connected systems, supplier dependence, data export, replacement work and fallback arrangements alongside purchase or development cost.
  6. Write a conditional recommendation. Name the decision owner, the evidence still required and the point at which the team should reconsider. Keep research approval separate from spending or contractual approval.

Expected output

A sourcing decision note with one record per route:

Job and essential conditions: [shared definition] Option: [reuse/buy/build/manual] What is included: [capability and scope] What we must supply: [data, integration and people] Evidence: [source/date or observed example] Unresolved conditions: [question and owner] Initial effort/cost: [estimate and basis] Ongoing owner/capacity: [role and commitment] Exit/fallback: [practical route] Recommendation: [conditional choice] Next decision: [owner, evidence and review date]

Hypothetical example: a team needs searchable internal guidance. An existing knowledge tool may be sufficient if its source coverage can be improved; a new conversational interface remains an option only if it addresses a demonstrated gap.

Human checks

Technology owners verify integration and support assumptions. Users examine actual outputs, and the purchasing or budget owner checks commercial assumptions. Ask who would keep the service working if its initial champion left. Treat supplier claims as claims until the relevant requirement has been checked.

Limitations

This comparison supports a sourcing decision; it is not technical due diligence, a purchasing approval or a review of contractual terms. Product capabilities and prices can change. A successful demonstration does not establish performance across the organisation’s work.

Starter prompt

Compare sourcing routes for [bounded job] using these approved, sanitised requirements and option notes: [inputs]. Our essential conditions are [conditions], planning period is [period] and available ownership capacity is [capacity]. Use only supplied evidence; identify anything that needs current verification.

Create a record for each plausible route: reuse, buy, build and manual delivery. Use these fields: shared job and essential conditions; option; included capability and scope; what we must supply; evidence and source date; unresolved conditions and owner; initial effort and cost with estimation basis; ongoing owner and capacity; exit or fallback; conditional recommendation; next decision, evidence and review date. Separate setup from ongoing responsibilities. Recommend the next evidence-gathering step. Do not infer access permissions, approve purchases, accept terms, contact suppliers or make commitments.

Adapt the requested fields to the authorised inputs actually supplied. If an option lacks evidence, mark its conditions unresolved rather than treating them as passed or failed. Keep conflicting prices, feature descriptions and dates separate and request current owner verification; do not invent current vendor facts. State the expected output and acceptance criteria before drafting. Ask for essential missing information; where a useful partial draft is possible, label its limits and assumptions. Do not invent facts, evidence, results or approvals.

Data, model variability and your responsibility

Use relevant data that exists or that you provide, with accuracy and completeness sufficient for the task. Different AI models and versions may produce different results, and responses may vary between runs. You are responsible for checking and validating the output against your own requirements, source information and acceptance criteria before relying on it.