Define the requirement before commissioning work
For a technical director or head of digital, the starting point is a requirement that can be evaluated and commissioned. Identify the process owner, the current systems and the specific change the business needs. That might be reducing the time spent checking incoming documents, improving retrieval across an internal knowledge base or adding assisted drafting to an existing customer service platform.
Write the requirement with a baseline and acceptance criteria. Record transaction volume, current handling time, failure modes and the quality standard the output must meet. For a policy-search feature, this means more than returning an answer: the answer must use current sources, respect the user's access and decline questions the available material cannot resolve. Those conditions belong in the brief.
Check whether AI is the right approach
Some problems need a simpler process, a better website or an integration between tools you already own. If a known event should copy an exact value into another system, conventional automation is usually easier to test and explain. If the task involves interpreting varied documents, finding relevant passages or drafting from unstructured information, AI may be worth evaluating.
Compare configuration of existing software, an off-the-shelf product and bespoke development against the same requirements. Include integration access, user permissions, data handling, support arrangements and the ability to change supplier. A feature bundled with an existing platform may be sufficient, but its availability does not establish that it fits the workflow or your operating requirements.
Define the first release boundary
Document preparation
Extract proposed fields from recurring documents, show the source beside them and ask a colleague to confirm them before updating a business record. The first release can cover one document type rather than every file the business receives.
Internal information search
Help a team find relevant information in an approved collection of policies or product guidance. Answers should point to their sources and respect the same access restrictions as the documents themselves.
Enquiry assistance
Suggest a category and prepare a draft response for a staff member. Begin with a narrow set of routine enquiries, keep unusual requests visible and leave sending decisions with the team.
Check data readiness and operational ownership
Review the source material before agreeing delivery scope. Check ownership, versioning, access controls, document quality and whether representative examples can be used for development and evaluation. Record the preparation required, including resolving conflicting policies or supplying missing fields. These dependencies affect the architecture and schedule, rather than being a general data-cleaning task to leave with the implementation team.
Name both a technical owner and a process owner. The technical owner needs to agree integration access, deployment and support; the process owner needs to define acceptable outputs, review exceptions and approve changes to the workflow. Involve the staff who will use the feature when assembling evaluation cases. Their exceptions are part of the requirement, even when they are absent from the documented process.
Compare value, effort and consequences together
Estimate the time and rework that could be removed, then subtract the review, correction and support the new workflow would require. Consider software subscriptions, model usage, maintenance and training as well as the initial build. Keep assumptions visible. An estimate based on a handful of examples is a starting hypothesis, not a promised saving.
Set the permitted actions according to the consequence of an error. Preparing a draft for review has different requirements from sending a customer message or changing a business record. Specify where approval is required, which actions must be reversible and how exceptions are escalated. Test those boundaries as part of acceptance rather than relying on a general promise of human oversight.
Evaluate the uncertainty before committing to rollout
For an illustrative enquiry evaluation, assemble previous messages with the expected category, acceptable response content and escalation decision. Include incomplete requests, unusual wording and cases outside scope. Keep part of the set separate from development examples so that a change can be checked against cases it was not specifically adjusted to handle. Evaluate suggestions without sending messages to customers.
Agree success criteria before reviewing the results. Measure total handling time including checking, factual errors, escalation quality and whether staff can understand the source of a suggestion. Keep a record of failed examples and retest them after changes. If the output is fast but takes longer to verify than writing it manually, the workflow needs a different design.
Choose the engagement that matches what is already known
A paid AI Opportunity Assessment is appropriate when the business has several candidate uses and needs evidence to prioritise them, or when feasibility is unresolved. It should identify dependencies and recommend a delivery scope, including alternatives using existing software. Commission a limited evaluation when output quality is the unresolved question. Neither is a compulsory stage for a feature with established requirements and evidence.
If the requirement is already scoped, an implementation brief can instead describe the integration points, acceptance criteria, release constraints and support responsibilities. Agree who maintains source information, approves configuration changes and investigates failures. The commissioning route should reflect the work still needed, rather than making every project repeat discovery the client has already completed.
Useful resources and next steps
Discuss the requirements for your project
We can review a proposed AI use case, assess its integration requirements or take on a defined development brief.
AI consultancy