Define the work before the technology
Begin by describing a real workflow from start to finish. Identify the request that starts it, the information required, the decisions made, the output produced and the person who owns the result. This exposes where an integration could remove repetition, improve retrieval or help someone draft an answer. It also exposes tasks where an error would have serious consequences.
Use ordinary language. “Respond to routine supplier questions” is more useful than “deploy a conversational agent”. The first describes work; the second describes a technical possibility.
Separate assistance from delegation
AI can assist with classification, summarisation, drafting, extraction and search. Assistance means a person reviews or uses an output before the business acts on it. Delegation means a system can trigger an action with limited human intervention. The distinction changes the design, testing and governance burden.
A drafting assistant may be appropriate where a colleague checks every response. Automatic changes to a customer record need stronger identity controls, clearer evidence and a way to reverse mistakes. Do not treat both as the same project because they use a similar model.
Compare the alternatives
For each proposed use, compare AI with a rule, a database query, a conventional integration or a change to the process itself. Rules are often preferable when the input and expected result are stable. Search can be preferable when the main problem is locating approved information. A human-led process may remain the better choice where context is scarce or the cost of a wrong answer is high.
Consider quality, explainability, data exposure, maintenance and the effect on staff. The most sophisticated option is not automatically the most suitable option.
Choose a narrow starting point
A useful first integration has a clear owner and a visible output. It should be possible to observe the work, collect feedback and stop the process without damaging the wider operation. Narrow scope does not mean trivial scope. It means that the boundary of responsibility is understandable.
Write down what success would look like in qualitative terms: fewer hand-offs, clearer retrieval, more consistent drafts or less duplicated entry. Avoid committing to an invented numeric target before you understand the baseline.
Make the decision reviewable
Record why the use case was selected, which data it touches, which people approve outputs and what would cause the integration to be paused. This record helps procurement, security, operations and leadership discuss the same proposal. It also prevents a pilot from becoming an unexplained permanent dependency.
Keep strategy connected to operations
Strategy is not a document that sits apart from delivery. Revisit the choice when the workflow changes, when the data source changes or when users find a new failure mode. An integration that is useful in one part of a UK business may be unsuitable in another because the records, responsibilities and customer expectations differ.
For the next step, map the workflow and then read the automation guide to distinguish predictable work from work that requires judgement.