Choose a repeatable job

Look for a recurring process with understandable inputs and an observable output. A task performed once a month with unclear requirements may be less suitable than a frequent enquiry response with an approved service guide.

Check the foundations

Identify the process owner, reviewer, sample inputs, source information and baseline. Ask whether ordinary templates or automation can solve the issue first. Missing data access or review ownership is a dependency, not a reason to promise an autonomous solution.

Fictional comparison

A fictional agency compares proposal drafting and enquiry triage. Proposal pricing is inconsistent; the service guide for enquiries is current and has an owner. Enquiry drafting may be the clearer first candidate, subject to feasibility. This is an example of selection, not a recommendation for every company.

Write a bounded pilot decision

Define one input, one output, a human review point and a stop/go measure. Test representative cases, including missing facts. Track time after review, correction rate, user feedback and costs. Decide whether to expand only after comparing with the baseline.

Begin with a process inventory

List five recurring tasks and identify trigger, inputs, output, owner, reviewer, volume and common exceptions for each. Focus on actual work rather than a list of AI features. “Respond to a qualified service enquiry” is a workflow; “install an AI chatbot” is a proposed solution. Keeping those separate lets you consider templates, standardisation or ordinary automation before choosing a model.

Use a selection matrix

Score each candidate against frequency, clarity of inputs, quality of source information, reviewability and the consequence of a wrong output. Add dependencies such as access, integration and team adoption. Use the matrix to support a discussion, not to turn judgment into a misleading numerical guarantee. A high-volume process with poorly controlled prices may be a weaker first pilot than a smaller process with current approved information and a willing owner.

Choose a narrow boundary

A first pilot should have a recognisable start and finish. Drafting a response from approved information is narrower than managing all customer service. Summarising a recurring report is narrower than making management decisions. State what the workflow must never do: send automatically, infer prices, access unrelated records or approve an exception. The boundary makes testing and responsibility clearer.

Collect a representative evaluation set

Use examples from ordinary cases, missing information, contradictory inputs, unusual requests and out-of-scope situations. Remove personal or confidential details where required. Have the responsible team identify what a good answer should contain and what must be escalated. A test set of only easy cases can make a pilot look useful without showing whether it handles the cases that consume the most review effort.

Write the stop and go criteria

Agree how you will assess time after review, factual corrections, user adoption and total operating cost. Decide which failures require stopping, such as unsupported commercial commitments or access to the wrong client’s information. Do not set success only as “the system generates a response”. A response can be fluent and still fail the business task. Record the baseline and conditions before the trial rather than choosing favourable measures afterwards.

Turn the decision into a brief

The brief should name the workflow owner, input sources, expected output, reviewer, exceptions, systems, information boundaries and measures. List technical questions separately from commercial assumptions. If a company needs integrations or private knowledge, confirm the delivery capability before advertising those features. A paid assessment can help define this work; it should not imply that every idea in the report is immediately ready to deploy.

TAKEAWAY

Use evidence. Keep a reviewer. Measure the complete job.

A polished first output is a starting point. Confirm the facts, review the result and decide whether it actually makes the task more useful.

Before you use the result

  • Separate approved facts from assumptions.
  • Identify missing information and the person who owns it.
  • Check prices, promises and consequential fields.
  • Review the work in the format the audience will actually see.

Questions to ask next

What should I try first?

Choose one representative job and a useful output. Use fictional or approved inputs, define the review standard and compare the complete result with your current method.

Does this article mean JustDigital has connected the featured tools?

No. Vendor updates are editorial topics. The JustDigital preview uses local planning tools and fixed samples; live generation, permanent account storage and company integrations remain pending.

Where should I take the next step?

Use the related free tool to prepare a brief or estimate. If the task involves a business process, a scoped assessment can clarify the dependencies before a build.

Back to Learning Hub