Start with the work people repeat
“We need to use AI” leaves a lot of room for a project to drift. “We copy enquiry details into a tracker, decide who should respond and prepare an acknowledgement” gives you something you can examine.
Write down what arrives, what somebody does with it and what a useful result looks like. Include the awkward cases: missing information, duplicated requests and enquiries that do not fit the usual categories. They are part of the job, even when they do not appear in the neat version of the process.
Use a rule when you already know the rule
If a form includes a chosen service, routing it to the relevant team may only need a simple rule. If a required field is empty, the workflow can flag it for follow-up. An agreed reference format can be checked without asking a language model to interpret it.
These are illustrative examples, rather than claims about a particular client project. The point is to separate predictable steps from those that involve reading or judgement. That usually makes it easier to explain what the workflow should do and test whether it does it.
Clear rules still need exception handling. A missing destination or a failed connection should leave a visible task for somebody to deal with, rather than an enquiry disappearing between systems.
Give AI a defined part of the task
An enquiry written in free text is different from a fixed form choice. A language model could help summarise the request or prepare a draft response from approved information. That can be useful, provided the output is treated as something to check, not an automatic statement of fact.
For a first trial, keep sending separate from drafting. Someone should be able to see the original enquiry, check the proposed reply and decide what goes out. Give the system only the information and permissions needed for that task.
The NCSC’s secure-design guidance starts with a useful question: is AI appropriate for the task? It also recommends limiting what AI-connected systems can access and do. Those are design decisions to make before connecting a model to business information.
Compare a small trial with the current process
Use a manageable set of representative examples, with permission to use the information involved. Agree what a good result means before testing. For enquiry drafts, that might mean the right facts, an appropriate next step and no promises the business cannot fulfil.
Count the review and correction effort as well as the time spent generating the draft. If somebody has to rewrite most of it, the workflow has not necessarily become easier. Keep a route back to the existing process while the trial is being assessed.
You may end up with a combination: rules to move information, AI to help interpret it and a person to approve the result. Or a straightforward automation may be enough. Our workflow improvement review starts with the task so that the technology follows a clear purpose.