How do I find everyday AI uses for staff outside IT?
· 5 min read
Start with the work your teams already do, not a list of AI tricks: observe, set data rules, run small timed trials with an owner, and publish what works as knowledge.
In brief
Many IT leads are being asked to find practical, everyday uses of AI for colleagues who do not write code. This article argues that the best place to start is not a list of clever examples from other organisations, but the work your own teams already do each week. It sets out six practical steps: choose three willing teams rather than the whole organisation, spend time watching the real work, ask people which parts of their job they would most like to stop carrying, agree clear data rules before anyone uses a tool, run short timed trials with a named owner and a before and after measure, and write up each successful use case so other teams can reuse it. A worked example from a civil engineering practice shows how two small trials, one on summarising tender documents and one on drafting client updates, can produce a clear keep or drop decision within a few weeks. The article also lists common mistakes, such as starting with the licence instead of the work, measuring logins instead of outcomes, and letting a good pilot fade without an owner. It draws on the guiding principles Focus on Value and Start Where You Are from John Sansbury's The Journey to Service Excellence, a question for leaders from Ian Hughes's What Stays the Same, and UK guidance from the National Cyber Security Centre and the Information Commissioner's Office.
The short answer: do not start with a list of clever AI tricks. Start with the work your colleagues already do every week, find the parts that are slow, repetitive or dreaded, and test AI on two or three of those with clear rules about what data can go in and who checks what comes out.
This question comes up a lot at the moment. An IT lead has been asked to "bring back some real use cases" for staff who do not write code, and the usual result is a slide of generic ideas that nobody adopts. The fix is to treat it as a service management problem, not a technology hunt.
Why the use case list rarely works
A list of other people's examples tells you what is possible. It does not tell you what is valuable here. John Sansbury's first guiding principle in The Journey to Service Excellence is Focus on Value, which he says means two things: "Understand who your stakeholder is for each service" and "Understand what constitutes value for each of these parties in respect of each of your services." Swap "service" for "team" and you have the brief. A useful AI use case for the finance team looks nothing like one for the design team, and neither of them will thank IT for guessing.
Practical steps
- Pick three teams, not the whole organisation. Choose ones with a willing manager and a visible pain point. Breadth comes later.
- Watch the work before you suggest anything. Spend an hour with each team. Ask what they do every week, what takes longest, what gets sent back, and what they put off. You are looking for tasks that involve reading, summarising, drafting, reformatting, translating or comparing text and tables. Those are where today's general AI assistants tend to help most.
- Ask the better question. In What Stays the Same, Ian Hughes suggests asking people: "What becomes possible for you if the grinding part of your job is no longer yours to carry?" That question surfaces real candidates and also lowers the fear that often sits underneath slow adoption.
- Set the data rules first. Before anyone pastes anything, agree which tool is approved and what may go into it. The UK National Cyber Security Centre recommends "not to include sensitive information in queries to public LLMs". If you have an enterprise tool with proper data protections, say so plainly. If you do not, keep the first experiments to non sensitive material. The ICO's guidance on AI and data protection is the place to check obligations, rather than relying on memory.
- Run small, timed trials. Two to four weeks per use case, with a named owner in the business team, a before and after measure (time taken, rework, turnaround) and a simple rule that a person checks every output before it leaves the team.
- Publish what worked as knowledge. Write each successful use case up as a short how to: the task, the approved tool, a sample prompt, what to check, and who to ask. That turns one person's discovery into something the next team can reuse.
A short worked example
Take a civil engineering practice. In the observation hour, the bid team mentions that every tender response starts by rereading long client documents to pull out requirements and deadlines. The project managers say their weekly client update is mostly retyping notes from site meetings.
So the trial covers two tasks. First, summarising tender documents into a requirements checklist, using the approved enterprise tool only, with the bid manager checking every item against the source. Second, turning rough meeting notes into a first draft client update, which the project manager edits and sends. After three weeks you compare time taken and the number of corrections. One may clearly save time; the other may produce drafts that need so much rework they are not worth it. Both results are useful. You keep one, drop the other, and write up the keeper for the rest of the firm.
Common mistakes
- Starting with the tool licence instead of the work.
- Collecting impressive examples from other industries that do not match your people's day.
- Skipping the data rules and then having to unwind bad habits.
- Measuring logins or prompt counts instead of whether the work got better.
- Treating a good pilot as finished. Without an owner and a written how to, it quietly fades.
- Throwing out what already works. John's principle Start Where You Are asks you to "recognise those elements of the current situation that you can usefully keep and build on because they are working well". Sometimes the best answer for a task is a template or a checklist, not AI.
Next step
If you want a structured route through this, the AI Enablement topic on ESM's Exchange (exchange.esm.institute/knowledge/topic/ai-enablement) follows a simple loop: agree the value, see the real work, map it, redesign it, run a bounded trial, prove the result, and learn before you scale. It is built for exactly this kind of first step with teams outside IT.
The quotations above are from The Journey to Service Excellence by John Sansbury and What Stays the Same by Ian Hughes. John's book is available to members of ESM's Exchange, so joining is the simplest way to read it.
Tags: esm-questions, ai-enablement, ai-adoption, knowledge-management, guiding-principles
Sources
Join the Exchange free
Join free to unlock the complete knowledge library.
Founder membership is free for life
More from Esm
Experience debt: what happens to judgement when AI takes the tasks people learned from
5 min read
How should IT teams handle emergency patches for critical vulnerabilities?
5 min read
When the human in the loop becomes a rubber stamp: what UK regulators found about AI checks
5 min read
10 scheduled AI tasks for service management teams
8 min read
Boards expect AI savings: why almost no organisation is finding them
5 min read
AI rebounding: why some employers are asking back the people AI replaced
5 min read
Related articles
Experience debt: what happens to judgement when AI takes the tasks people learned from
New research finds most people say skills are slipping as AI takes on routine tasks, while time to learn is scarce. What that means for leaders, and which toolkit tools help rebuild the learning route.
How should IT teams handle emergency patches for critical vulnerabilities?
Treat an emergency patch as an emergency change: triage the risk fast, agree the fast path in advance, test as far as the clock allows and keep a remediation plan.
When the human in the loop becomes a rubber stamp: what UK regulators found about AI checks
The Bank of England and FCA find most firms approve AI before launch but far fewer keep watching it, and the FCA warns human review can become a tick-box exercise. What leaders should check, and which toolkit tools help.
Boards expect AI savings: why almost no organisation is finding them
Gartner finds 77% of board members expect AI to deliver savings, but only 3% of organisations beat their savings goals through productivity. What leaders should agree instead, and which toolkit tools help.
AI rebounding: why some employers are asking back the people AI replaced
New SHL research finds some UK and US workers replaced by AI were later asked back. Why it happens, and how leaders can understand the work before automating it.
AI Job Cuts and the Unfilled Role: Where Should Freed Capacity Go?
Barclays' AI-assisted job cuts and a quieter freeze on junior hiring raise one leadership question: when AI frees capacity, who decides where it goes before the spreadsheet decides for you?