AI for Business

Working out where AI is worth applying

Most AI projects do not fail on the technology. They fail because the wrong problem was chosen at the start. So we begin with the work as the organisation does it today, looking for where time goes on repetition, where everything waits on one person, and where a decision is slow because the data is scattered. Those become use cases with a scope you can write down, then get scored and ranked against one set of criteria by the whole room. The method here builds on the Discovery & Strategy workshops we already run.

• Separate work AI genuinely helps with from work that sounds promising but has no usable data behind it
• Turn day-to-day pain points into use cases with a clearly stated scope
• Score them on a prioritisation matrix, for value and for how hard they really are
• Work through an ROI canvas: where the return comes from, and when it arrives
• Check early whether the data exists, what shape it is in, and who owns it
• Finish with a short list the organisation is prepared to fund, not a wish list

Reading a proposal, a demo and a vendor's claims

A demo is the best case somebody prepared for you, and a proposal is usually written as broadly as it can be. This part of the programme is practice at asking the right questions. We open up what these systems are actually made of, whether it is a chatbot answering from internal documents or an agent that collects data, structures it and analyses it: where the hard work sits, and which phrases in a proposal mean the work has not been done yet. Because we build these systems ourselves, we can say what each part really takes.

• A set of questions that separates what is finished from what is still a plan
• Where a quoted accuracy figure comes from: which data, measured under what conditions
• What the system does with a question outside its scope, and whether it can cite the source of an answer
• Why most of the work is data preparation and integration with existing systems, not the model
• What to pin down in a TOR or contract: scope, deliverables, and support after handover
• Build in-house or buy: what actually differs across the life of the system

Cost, risk and data governance, at the depth a decision needs

The cost of an AI system is never a single number. There is the build, the model usage that moves with how much people actually use it, the integration with what you already run, and the cost of keeping it working afterwards. The risk arrives from two directions: data that leaves the organisation, and answers that are wrong while still sounding convincing. This part builds on our Data & Governance for AI material, pitched at the depth a decision needs rather than at configuring anything yourself.

• Separate the one-off build cost from what recurs every month once the system is live
• What data leaves the organisation, where it is stored, and for how long
• PDPA for customer and employee data, including lawful basis and consent
• Model risk: wrong answers will happen, so decide where a person has to check before it counts
• A governance framework: who approves, who owns the outcome, and when it gets reviewed
• The signs that say start with a small pilot before rolling anything out organisation-wide

A different class from the hands-on courses, and a good fit alongside them

We already run courses for the people who build: Generative AI, n8n, Make.com and Claude Cowork, where participants make something of their own in class. This programme does not replace them, it does a different job, training judgement rather than tool use. There is no code and nothing to install. The sequence that works is for executives and business teams to settle the brief first, then send the people who will build it on to the hands-on courses.

• No coding and no tools to install
• Your own briefs and your own data as the material throughout
• Run as a closed in-house session, or as a talk for a larger audience
• Leads straight into the practical courses for the team who will build