Start with a task whose mistakes you can catch
Your team reads incoming enquiries, copies details into a spreadsheet and asks customers for missing information. The work repeats, but each message looks slightly different. AI automation may help prepare that information for review. Whether it deserves investment depends on the effort it removes, the checking it adds and the consequences of getting something wrong.
A useful first AI automation project for a business has a clear beginning, a limited output and someone who can judge whether that output is correct. “Prepare an enquiry summary for a salesperson” is a more workable brief than “automate sales”.
Start by identifying where work accumulates. Then ask whether the task needs interpretation. Moving a completed form into a database may only need an ordinary integration. Reading varied messages and identifying what a customer wants could justify testing AI. A process review should leave room for either answer.
Compare candidates by effort, exceptions and consequences
List a few repetitive tasks, such as document intake, enquiry sorting or preparing internal report drafts. For each, consider:
- Frequency: Does it happen often enough to justify setup and ongoing attention?
- Inputs: Are the documents or messages accessible through tools the business controls?
- Expected output: Can an experienced employee describe a correct result?
- Exceptions: What happens when information is missing, contradictory or unreadable?
- Consequences: Could a mistake create a customer commitment, disclose information or change a financial record?
- Review effort: Can someone check the result without repeating the entire task?
Prefer a candidate with bounded consequences and a useful intermediate output. Drafting a response for approval gives you a chance to inspect the work before it reaches a customer. Allowing a system to negotiate terms would require a much broader scope and different controls.
NIST’s AI Risk Management Framework treats trustworthiness as something to consider throughout design, development, use and evaluation. It is voluntary guidance, not a certification or a substitute for applicable obligations. For a buyer, the practical implication is to discuss risks when choosing the workflow, before implementation decisions become expensive to change. NIST AI Risk Management Framework
Worked example: preparing sales enquiries for review
Consider an illustrative supplier receiving requests through a shared mailbox. This example is a planning scenario, not a report of company or customer results.
A buyer writes: “Please quote for 40 replacement filters like our previous order. We need them next month.” The message lacks a confirmed product code and a precise required date.
A focused pilot could produce an internal enquiry record containing the requested quantity, the customer’s wording about the product, the missing details and a draft clarification message. A salesperson would review the record and approve the response.
The brief should make several boundaries explicit:
- The pilot covers one agreed mailbox and a defined category of enquiries.
- Product identity remains unresolved when the available information does not establish it.
- Prices, availability and delivery commitments require an approved source and human judgement.
- Unreadable attachments or conflicting details go to a person for review.
- Sending a reply requires approval during the pilot.
Access to previous orders is a separate decision. It could help resolve references, but it also adds an integration and questions about matching the correct customer and order. You might first test whether extracting details and preparing clarification drafts provides enough value without that connection.
Regional details belong in the brief when they affect interpretation. For a business serving India and overseas customers, an enquiry might contain an ambiguous numeric date, an unstated currency or a delivery location in another time zone. Agree how uncertainty will be displayed. Include the languages and document formats your customers actually use; do not assume an English interface means every input will be English.
Define acceptance before watching a demonstration
A polished demonstration shows what a workflow can do on selected inputs. Acceptance testing should establish how it handles the work you intend to give it.
OpenAI’s evaluation guidance explains that generative AI can produce different outputs from the same input. It recommends task-specific tests, representative examples and human judgement alongside numerical measures. Those principles are useful even when your provider uses a different model supplier. OpenAI evaluation best practices
For the enquiry example, assemble an agreed test set containing routine messages and difficult cases: missing quantities, conflicting attachments, repeated enquiries and requests outside the pilot’s scope. Someone who understands the business should identify the expected result for each case.
Measure separate things rather than accepting one headline “accuracy” figure:
- Whether the extracted product, quantity and customer details are correct.
- Whether missing information is clearly identified.
- Whether drafts introduce unsupported prices or commitments.
- Whether exceptions reach the right reviewer.
- How much checking and correction the reviewer needs to do.
Agree which failures block launch. An incorrect internal category and an invented delivery promise should not carry the same weight. Keep some examples aside for acceptance testing so the final review includes work beyond the examples used during development.
Measure the existing process too. Compare the time spent preparing, checking and correcting work, including exceptions. If reviewing AI output takes as much effort as doing the task manually, the pilot may need a narrower scope—or may not justify further investment. That is a valid result.
Put responsibilities and running costs in the brief
A useful brief describes the process in enough detail that providers can make comparable proposals. Include the current steps, approximate workload, example inputs, desired outputs, connected tools and the person responsible for decisions.
Ask each provider to explain:
- Scope: Which steps use AI, which use fixed rules and which remain manual?
- Access: What information leaves your existing tools, where is it processed and what access is required?
- Approvals: Who checks consequential actions, and what happens when that person is unavailable?
- Failures: How are failed integrations, repeated inputs and incomplete work made visible?
- Ownership: Who controls the accounts, workflow configuration and documentation after handover?
- Costs: What is included in setup, what drives usage charges and what maintenance is separate?
For India-based and international buyers, specify any customer or contractual requirements affecting data handling and access. Ask the provider to explain how the proposed configuration meets them; an office location alone does not answer those questions.
Request a scoped quotation based on the workflow and integrations. A meaningful comparison includes recurring model and third-party usage, maintenance and the staff time needed for review. Avoid treating an unmeasured savings estimate as a business case.
Buy an operating process as well as a pilot
Before launch, name the person who monitors exceptions and the person authorised to pause the workflow. Agree what happens to incoming work while it is paused and how staff continue manually.
The handover should explain the approval process, logs, failure handling and account ownership. Ask for a demonstration of an unsuccessful run as well as a successful one. A reviewer needs to recognise when work is incomplete and understand who will resolve it.
Testing should also continue when the workflow changes. OpenAI’s guidance recommends ongoing evaluation and expanding test examples as new cases appear. Ask how changes to models, business rules or connected tools will be checked before they affect live work. OpenAI evaluation best practices
Our AI automation service covers process review, agreed integrations, AI-assisted document reading or drafting, human approval steps, logs, failure handling and practical pause controls. Documentation and handover are into accounts you control. Model and third-party usage stays on your accounts, and ongoing maintenance is scoped separately.
For a scoped enquiry, bring one candidate workflow, representative examples you are permitted to share and a description of what a mistake would cost the business. That gives the discussion a concrete starting point: what to test, what to measure and what evidence would justify proceeding.
Sources
Prepared with AI-assisted research and drafting, then checked by our automated editorial and publishing pipeline.