Define the job before comparing options
Describe the task: user, trigger, information, expected result, and cases for a person. Keep scope narrow. If the need is only 'we want an AI agent,' identify the delay, repeated research, or difficult handoff first.
A ready-made product may fit when its process and controls match. Custom work may help when existing products cannot support a required system or policy. A hybrid may add a small workflow around a purchased service. UK Government guidance recommends considering other approaches and assessing requirements, support, and supplier dependency.
Compare the lifecycle: selection, configuration, integration, testing, training, support, changes, and exit. The future owner is part of the decision.
Compare fit, access, and ownership
Check whether a product supports your cases, not just its demo. Ask what it can read and change, how approval and activity records work, and how staff correct a result. Read terms for the plan and region you would use. A small integration may close one important gap.
For a custom build, list systems and permissions, the code and account owners, and who handles monitoring, incidents, policy changes, and turnover. Include a practical way to export data or replace a provider. Custom control also creates maintenance work.
For a hybrid, define which component owns the source record, where a person approves, and how failures appear. Keep the boundary easy to explain.
- List the must-have workflow steps and policy rules before viewing demos.
- Check data access, action permissions, review controls, logs, and export options.
- Name the owner for setup, ongoing support, and the eventual exit or replacement.
- Compare a non-AI option if fixed rules or a clearer process would solve the problem.
Use a synthetic example
A fictional retailer wants help drafting answers about product compatibility. A purchased helpdesk may already connect to the inbox and knowledge base. If it uses approved product facts, keeps drafts for review, and routes uncertainty, buying may be sufficient; test the catalogue and policy coverage.
If the tool cannot reach a needed catalogue or support a required approval, a narrow integration could retrieve details and place a draft in the existing queue. A full custom agent may fit only if configuration and integration cannot meet distinct requirements and the retailer can own support. This is a planning example, not a deployed result.
Every version should flag incomplete facts and route uncertainty. It should not guess compatibility from a similar name or unverified catalogue entry.
Run a limited comparison
Prepare cases for ordinary requests, exceptions, missing records, and out-of-scope use. Have each option handle the same examples. Review accuracy, effort, handoffs, and how easily staff can correct a source. Involve policy and legal owners if outcomes may affect money, access, or important decisions.
Ask suppliers about data handling, integrations, retention, access, usage charges, and what happens if service ends. For custom work, identify owners for code, credentials, documentation, monitoring, and changes.
After a pilot, compare behavior and operating effort with today's process. Continue, change product, add a small integration, or stop. Record why and what evidence would change the decision.
A simple scorecard can keep the comparison grounded: mark whether each option meets a must-have requirement, what remains manual, who supports it, and what unresolved risk needs an owner. Avoid a single overall score that hides a failed requirement. If two options both fit, choose a short trial with clear stop conditions and a person responsible for the result.
Make the choice reversible where possible
Keep the first version inspectable and easy to pause. Document its policy and access limits. Use a few defined integrations and keep a manual route for outages or uncertainty.
Balance fit with the team's capacity to operate the choice. Compare real workflow needs in a pilot and name the owner who accepts the ongoing work.