Start with the work. Then consider AI.

A useful AI conversation often starts with an ordinary question: what keeps taking up your team's time?

It might be searching through documents, sorting incoming requests, or preparing a recurring report. These tasks are less dramatic than a promise to transform an entire organisation. They are also easier to examine. You can identify who does the work, what a good result looks like, and what would happen if the result were wrong.

That is a practical starting point for an experiment. The purpose is to find out whether a particular approach helps with a particular task. A useful result may be a small improvement, a reason to change direction, or a decision that the existing process needs attention first.

Describe the work before choosing a tool.

Imagine a team that receives enquiries about a training programme. Messages arrive with questions about eligibility, dates, and documents. A staff member reads each one, checks the programme guidance, and drafts a reply. This is an illustrative workflow, but it gives us something concrete to examine.

Where does the time go? Some messages may be repetitive. Others may be difficult because the guidance is scattered or out of date. If staff disagree about the answer, an AI system will not resolve the underlying policy. The team first needs a reliable source and someone responsible for keeping it current.

Write down the input, the expected output, the person responsible, and the exceptions. “Help us answer routine programme enquiries” is a more useful brief than “give us an AI assistant.” It leaves space to compare solutions and recognise when a simpler change would help.

Consider the simpler option alongside AI.

A clearer application page might prevent common questions. A searchable guide might help staff find answers. A form can collect missing details, and a straightforward rule can route messages containing a programme reference. These options can be easier to maintain when the underlying task is predictable.

AI becomes a candidate when working with varied language or producing a draft has potential value, and when there is a practical way to check its output. Even then, one workflow can combine several approaches: a form collects essential information, rules route it, and a model suggests a reply for a person to review.

For our example, the first experiment could be limited to draft answers to routine questions using an approved guide. Eligibility decisions, complaints, and unclear requests would stay with a person. That boundary makes the experiment easier to assess.

Make the first test small enough to understand.

Choose a set of representative enquiries and agree what a good answer must contain. Use examples you have permission to use, with identifying details removed where possible. Include straightforward requests, incomplete messages, questions the guide does not answer, and cases that must be passed to a staff member.

Write the assessment criteria before reviewing the generated answers. Does a reply match the current guidance? Does it invent a date or promise? Does it acknowledge missing information? Is it understandable to the intended reader? A fluent answer can still fail the task.

Keep some examples out of the initial development work and use them to check the revised version. Otherwise, a system can appear to improve simply because it has been adjusted around familiar cases. Record the guide version and test conditions so that later comparisons mean something.

Design the review step as carefully as the draft.

A label saying “human review required” does not make review easy. The person checking a reply needs access to the original question, the proposed answer, and the relevant source material. They need enough time to notice a problem and a clear way to correct it.

Make the state of the work visible: suggested, reviewed, approved, or sent. The system should not turn an unreviewed suggestion into a commitment merely because somebody clicked the wrong control. For decisions with significant consequences, define the limits with the responsible subject specialist before testing automation.

Also decide what happens when the tool cannot help. A useful fallback might be a short explanation and a handover to a person. Leaving someone in a loop of increasingly confident but unsupported answers is a service failure, even when the interface looks polished.

Know what information the experiment uses.

Before connecting documents or inboxes, establish what the chosen service receives, who can access it, how long it is retained, and what controls are available. Check the provider's current terms and settings against your organisation's requirements. There is no single privacy answer that applies to every product or deployment.

Start with the minimum information the task needs. Keep credentials and unrelated personal records out of test material. Give the experiment an owner who can change access, correct outdated source information, and turn the system off if necessary. These are operational decisions as much as technical ones.

Measure the whole task.

A draft produced in seconds may still take longer to verify than an answer written from scratch. Compare total handling time, the amount of correction required, and the number of enquiries that need escalation. Include the cost of maintaining guidance and supporting staff.

Look at the mistakes, not just an average score. An occasional invented deadline can matter more than a large number of harmless wording differences. Agree in advance what would justify continuing, what would require a narrower scope, and what would stop the experiment.

Once the test is useful, expand gradually. A new audience, document collection, or task changes the conditions. Recheck quality when the model, instructions, or source material changes; a successful first demonstration is the beginning of that responsibility.

At MeDomot, the conversation we want to have is about the work you need to improve. Bring a recurring task, a bottleneck, or a process people keep working around. Together, we can explore a practical approach to automation and define what a useful result would look like.