The short answer

A useful implementation turns a business problem into a defined workflow, builds it, tests it with representative work and hands it over to the people who will use it. The model or prompt is only one part of that job.

First, understand the current work

We begin with the people doing the task. What starts it, where does information come from and what does a finished result look like? We want to understand the interruptions and exceptions, not just an idealised process diagram.

A first conversation can identify a plausible fit and the next step. A complicated requirement may need a more detailed investigation before the implementation can be defined. The introductory call is not a complete technical audit.

Agree what the implementation will and will not do

A useful scope explains the inputs, outputs, systems, permissions, responsibilities and acceptance criteria. It also says where a person reviews the result and what happens when the workflow cannot continue.

For example, “prepare a response for review” is different from “send responses without approval”. These boundaries need to be understood by everyone involved before building starts.

Build and test with representative examples

Testing should include the normal task, missing information and cases outside the intended scope. Where systems are connected, check the whole path rather than only the AI-generated text.

The intended users need to try the implementation too. Can they see what happened, correct a draft and understand an exception? Their feedback helps identify the difference between a technical demonstration and something useful in the working day.

Handover is part of the delivery

Before the workflow becomes part of normal work, agree the practical operating details.

  • Who owns the accounts and can grant or remove access.
  • Who maintains reference information and instructions.
  • How someone recognises and reports a problem.
  • Which changes the team can make themselves.
  • Where documentation is kept and who is responsible for it.
  • What support and future improvements have been agreed.

Review usefulness after it meets real work

A process can change after launch: a source document is updated, a system adds a field or the team finds a better way to handle an exception. Keep a clear route for that feedback.

At Get AI Working, Stu focuses on business discovery and commercial priorities, while Dan leads technical discovery and implementation. We work together to connect the business problem with a tool or workflow the team can actually use.

A working implementation includes the process, the checks, the people and the handover.

Explore the connected topic

Put the idea to work

Custom AI Tools

Sometimes a business has a clear way of working, but no tool that quite fits. We design and build a focused application around that requirement, using AI where it helps.

How we can help