What problem are we trying to solve?
Write the problem in ordinary business language. ‘We copy the same enquiry into three systems’ is more useful than ‘we need to use more AI’. Be specific about who experiences the problem and how it affects their work.
What do we already have?
Check the existing software stack and speak to the people who use it. You may already have a suitable feature, or a process change may remove the need for another subscription. Equally, an existing feature should still be assessed before it is used.
What information would go into it?
Map the information the task depends on. Consider whether it includes client details, confidential work or personal information, and who should review the proposed use. Check the relevant product arrangements and settings rather than assuming all tools handle information in the same way.
Who will own it?
Someone needs to make decisions about access, guidance, support and review. Ownership should include the business workflow, not only the purchase. If the person who introduced the tool leaves, the organisation should still understand how and why it is used.
How will we judge whether it helps?
Choose a measure connected to the original problem. That could be the number of repeated steps, the time taken to complete a task or the amount of checking needed. Compare like-for-like work and include the effort needed to review and correct the output.
What is the smallest sensible test?
Try the approach on a bounded task with appropriate information and oversight. Agree what would make you stop, adjust or continue. A considered trial gives the business better evidence than a promising demonstration.
