Include configuration as a real option
Software already in the business may cover part of the need. A new product may require configuration and integrations. A custom system may still use external models and services. Compare at least three concrete options instead of contrasting a finished product with a prototype that excludes operational work.
Define one task from input to outcome: a received enquiry, verified data, prepared draft and updated status. Ask each option to cover that path using the same examples. An impressive AI feature disconnected from the business system can leave the copying work you wanted to remove untouched. Make remaining manual steps visible in the comparison.
A practical comparison matrix
Scroll the table to compare all columns.
| Criterion | Question to verify | Evidence |
|---|---|---|
| Fit | Does it handle our ordinary cases and exceptions? | Test on agreed cases |
| Integration | Can it read and write the required systems with appropriate permissions? | Demonstrated operations and documented limits |
| Operations | Who responds when a source changes or a workflow stops? | Owner, support coverage and procedure |
| Complete cost | What work remains and which costs vary with volume? | Assumptions, recurring items and growth scenario |
| Exit | Can we export useful data, configuration and history? | Trial export and clarified rights |
Illustrative example: classifying CRM enquiries
A team wants to classify commercial enquiries and assign them. If the CRM already offers suitable fields, rules and an AI feature, configuration can be a serious candidate. The work is to check categories, access, ambiguity and assignment consequences rather than automatically build another application.
If the decision requires a document archive and an operational system the product does not cover, consider a dedicated integration. This does not imply rebuilding everything: a custom component may connect existing systems. The test should include what happens when one system is unavailable and who resolves cases left incomplete.
Separate requirements from preferences
For each requirement, distinguish “demonstrated”, “claimed” and “unverified”. A feature catalogue is a starting point; testing your operational path provides more useful decision evidence. Record exclusions openly so they can be priced or resolved before work begins.
- Identify requirements that exclude an option, such as access controls, essential data, export or critical operations.
- Do not offset a missing essential requirement with numerous small benefits in an average score.
- Establish who owns accounts, configuration, code and evaluation examples.
- Check residual manual work and platform administration time.
- Ask which dependencies can change and how versions and retirements are handled.
Write down the choice and when to revisit it
Document why the selected option fits now, which compromises you accept and what would change the decision: new volume, another integration or a data constraint. This prevents an initial choice becoming permanent through inertia.
A reasonable outcome can be configuring a product for the pilot and developing only the component that testing shows is necessary. Plan exit alongside entry: company-controlled accounts, exports and documentation make the project manageable even if the supplier relationship changes. Keep the evaluation cases so replacement options can later be compared on the same task.
A template to work from.
AI vendor scorecard
An evidence-based comparison with explicit conditions and gaps to clarify before a decision.
Download the Markdown templateSystem integration map
One connection record containing field mappings, permissions, duplicate handling and a reconciliation check.
Download the Markdown templateAutomation handover worksheet
A handover record with accessible materials, accepted responsibilities, an operating exercise and assigned outstanding work.
Download the Markdown templatePractical questions
Is custom development always more expensive?
There is no universal answer. Compare implementation, licences, usage, integrations, maintenance and internal work over the same period and volume.
Can we start with a product and migrate later?
It can be an option, but design for it. Check export, configuration ownership, data availability and the effort to recreate non-transferable components.
Is a supplier demonstration enough to decide?
It is useful for initial screening. Before choosing, test your cases, exceptions and at least one relevant failure against shared acceptance criteria.
References and method
UK public-sector AI procurement guidance, used as a methodological reference for defining needs and assessing suppliers; not presented as a requirement for private European businesses.