Explaining AI use to a sceptical manager
3 June 2026
Scepticism is often a request for limits. A useful briefing states the task you tried, the minutes it took with and without the assistant, the errors you caught, and the data that never left the building. One page is enough. A slide deck with a vision statement will not answer the questions a careful manager actually has.
Those questions are usually about confidentiality, about staff sending half-checked text to clients, and about licences multiplying without a policy. Answer those three even if they are not asked aloud. If you cannot answer them yet, say so, and ask for time to run a small, observed trial with a named reviewer.
We will help you prepare that page in an advisory call. Book twenty minutes on Contact if you would rather talk it through than draft it alone. Teams that need the same conversation across a department can start on For teams.
Reading an AI vendor's claim page
19 May 2026
Claim pages are written to be scanned. Before you comment on a tool at work, look for four things: the task the product actually performs, the data it needs from you, the human steps that remain after you switch it on, and the conditions of any case study (size of organisation, language, and whether the vendor ran the work themselves). If those four are missing, you do not yet know what you would be buying.
Time-saved figures with no baseline tell you very little. Job titles that appear only in the headline tell you even less. Ask for a trial on your own documents, with your own reviewers, for a period long enough that novelty wears off. Two hours in a showroom will not tell you how the tool behaves in week four.
We practise this reading in AI Foundations for Working Adults because staff are already being asked to comment on tools. You do not need to become a procurement specialist. You do need a short list of questions you will not skip.
Choosing between a tool and a process fix
22 April 2026
Teams often buy a licence because a demonstration looked quick. A week later the underlying process is still unclear: who supplies the input, who accepts the output, and what happens when the output is wrong. A cheaper first step is to write that path on one page. If the path is a mess, software will copy the mess at higher speed.
Ask whether the pain is typing, searching, waiting for someone else, or checking. Typing and first drafts are where current assistants help most. Waiting for someone else is usually a handoff problem. Checking is a standard problem. Match the fix to the pain before you shortlist vendors.
If you are scoping this for a department, For teams sets out how we run that conversation with a group. Individuals can bring the same one-page path to an advisory call; we will tell you honestly whether a programme is the next step.
What not to paste into a public assistant
18 March 2026
Public assistants are convenient and leaky. Anything you paste may be stored, reviewed, or used to improve the service, according to that vendor's terms. For work in Singapore that includes personal data, the safe default is to keep names, identity numbers, account numbers, health notes, and unreleased commercial figures out of the box.
You can still practise on the shape of the task. Replace names with roles. Replace amounts with ranges. Replace the real clause with a dummy clause of the same length. If the task cannot survive that stripping, it does not belong in a public tool. Speak with your organisation's own policy owners before you decide otherwise. We are an academy. We do not give legal advice.
In class we use examples the participant has already cleared, or we invent them together. That boundary is part of how we teach. Bring questions about the line; leave the raw files at work unless your organisation has an approved environment.
Writing a prompt you can reuse next month
11 February 2026
A prompt that worked once is a lucky sentence. A prompt you can reuse is a small procedure: role, task, inputs, constraints, output shape, and a worked example of the standard you will accept. Write it in a document you own. Paste from there. When the reply is wrong, change the procedure, then save the change.
People often bury the actual request under courtesy and background. The model does not need the courtesy. It does need the fields, the units, and the rule for what to do when a field is missing. State that rule. Otherwise it will guess, and the guess will look tidy.
We keep a two-Saturday practicum on this because reuse is a craft, and it is easy to slide back into one-off chatting. Sitting dates and class size are on Programmes. If the format is unclear, ask on the FAQ or book a call.
A checklist for verifying anything a model tells you
14 January 2026
When a model answers a factual question, treat the first reply as a draft. Ask where the claim would have to be true: a statute, a vendor manual, a spreadsheet you already hold, or a person who owns the process. If you cannot name that source in one sentence, you do not yet have an answer you can send on.
Keep a short list beside the keyboard: source named, numbers copied rather than paraphrased, names and dates checked against the original, and a note of what the model invented to sound complete. The last item matters. Models fill gaps with plausible language. Mark the gaps first. Polishing the prose can wait until the facts stand.
If the task is high-stakes (pay, personal data, a public statement), a second pair of eyes is part of the method. Our programmes practise this checklist on work you bring in, so the habit has somewhere to live on Monday. Details are on Programmes.
