Ask how they understand the problem
A useful first discussion should cover the workflow, users, systems, current baseline and desired result. Notice whether the proposed approach follows that context or arrives before it. Ask how the supplier compares an existing product, a straightforward integration and a custom AI application. The answer should explain the trade-offs relevant to your work.
Make the deliverables concrete
What will you receive at each stage? A workshop may produce a prioritised opportunity map; a pilot may produce tested behaviour for one task; an implementation should include the application, integrations, evaluations and operating guidance in scope. Ask what decision each deliverable supports. Avoid treating a presentation, a demonstration and a released service as interchangeable.
Examine relevant evidence
A case study is more useful when it explains the input, connected systems, human decisions and measurement, rather than only displaying a percentage. Ask which contribution the supplier actually made and how the outcome was assessed. Where reference material is confidential, discuss what architecture, demonstration or evaluation evidence can reasonably be shared.
Understand evaluation and failure handling
Which examples will be used to test quality? Who defines acceptance? How are difficult inputs, missing sources, access restrictions and failed integrations covered? Ask to see how findings lead to changes and how those changes are checked. A supplier should be able to discuss limitations and exceptions as clearly as the successful path.
Compare the whole commercial scope
Separate the initial work from recurring platform, model, infrastructure and support costs. Check assumptions about data readiness and access. Agree ownership and licences for code, documentation and third-party components. Clarify what happens if the project changes direction, if a provider changes or if your team takes over operation.
Check how your people are involved
Identify the process owner, reviewers and technical contacts your team will need to provide. Ask how training and handover work, and how feedback from actual users changes the implementation. An embedded team and a supplier-owned workstream can both work, but responsibilities and decision rights should be understandable to everyone involved.
Finish with a decision-ready brief
Before selecting a partner, put the problem, first scope, deliverables, assumptions, acceptance criteria and operating boundary in one place. Compare suppliers against that same brief. You are choosing a working relationship and a path to a useful result. Clear reasoning, relevant evidence and explicit ownership make that decision easier to assess.
Compare proposals on the same basis
A discussion aid to adapt to your workflow.
| Ask for | What it helps you judge |
|---|---|
| A scoped workflow and named deliverables | Whether the supplier understands the actual work. |
| Relevant implementation evidence | How the team handles integration, review and exceptions. |
| An evaluation and release plan | What evidence will support the decision to launch. |
| Separate build and running costs | Whether proposals cover a comparable whole-life scope. |
| Explicit ownership and handover | How the relationship will work after initial delivery. |
Make it specific
How does this apply to your business?
Bring us the workflow, your current systems and the decision you need to make.
Discuss your project