AI Training & Literacy
AI Training for Employees in Nepal: A Sample One-Day Workshop Syllabus
Key takeaways
- A one-day AI workshop for employees should spend at most ninety minutes on how the technology works and the rest on participants' own tasks. Sessions built on invented examples produce noticeably worse retention than sessions where people bring real work.
- Group size decides quality more than duration: beyond roughly 30 participants the practical exercises stop working and the day becomes a lecture. Split a larger team into two sessions.
- The measurable outcome of AI training is not a test score. It is the number of participants who, four weeks later, still use one workflow they built on the day. Ask for that number and plan the day around it.
- Three things belong in every syllabus regardless of industry: how to verify an answer before acting on it, what must never be pasted into a public model, and one written example of a good prompt from the team's own work.
When an HR manager or a principal asks about AI training, the first thing they want to see is the programme. Not the philosophy, not the pitch: what happens between nine and five, and what people can do afterwards that they could not do before.
This is the one-day syllabus I run for corporate teams in Nepal, with the reasoning behind each block. It changes by audience, and I will say where. If you want the broader picture of how I approach AI training, that page covers formats and who it is for.
Who this day is for
A team of eight to thirty people who do knowledge work of some kind: writing, research, correspondence, reporting, analysis, customer communication. Marketing, admin, accounts, HR, sales, operations. They have heard of ChatGPT and may have tried it. Few use it well, and nobody has agreed what it should and should not be used for.
It is not for developers, who need a different session, and it is not for a hall of two hundred, which is a seminar rather than a workshop. Group size matters more than anything else on this page: beyond roughly 30 people the practical exercises stop working and the day quietly becomes a lecture.
What happens before the day
Two things, and both matter more than they look.
A thirty-minute call with whoever owns the team. I need to know the three or four tasks the team spends the most time on, which tool the organisation can pay for and is allowed to use, and what data must never leave the building. Those answers shape the afternoon.
A one-line brief to participants. "Bring your laptop, an account on [the tool], and one real task you did this week by hand that you would rather not do by hand again." That last item is the whole day. Sessions where people bring their own work produce noticeably better retention than sessions run on invented examples.
The one-day syllabus
| Time | Block | What happens | Outcome |
|---|---|---|---|
| 09:00 – 09:30 | Where we are | Each participant names the task they brought. I group them on the board. | A shared list of the team's real work, which becomes the afternoon |
| 09:30 – 10:45 | How the technology actually works | What a language model does and does not do, why it is confident when wrong, what "training data" means, where Nepali language support stands. No maths. | Participants can predict when an answer is likely to be unreliable |
| 10:45 – 11:00 | Break | ||
| 11:00 – 12:30 | The three assistants, honestly | Same task run in ChatGPT, Claude and Gemini side by side. Where each is stronger, where the differences are overstated. | The team stops asking "which is best" and starts asking "which for this" |
| 12:30 – 13:15 | Lunch | ||
| 13:15 – 14:30 | Prompting as a skill | Structure, context, examples, constraints. Participants rewrite one of their morning tasks as a prompt and compare outputs in pairs. | Each person has one working prompt for a real task |
| 14:30 – 15:30 | Verification and the red lines | How to check an answer before acting on it. What must never be pasted into a public model, with examples from the organisation's own data. | A one-page rule that the team wrote, not that I gave them |
| 15:30 – 15:45 | Break | ||
| 15:45 – 16:45 | Build your workflow | Each participant turns their prompt into a repeatable routine: a saved template, a checklist, a sequence. I walk between pairs. | One documented workflow per person |
| 16:45 – 17:00 | What happens in four weeks | The team agrees what they will measure and who will ask. | A date and a number |
Why the morning is only ninety minutes of theory
Because theory is not what changes behaviour. People need enough of it to predict when the tool will fail them, and no more. The block on how the technology works exists so that the afternoon's verification session makes sense; it is not there to make anyone an expert.
Why the comparison is honest
Teams have usually been told that one tool is the answer. In practice the three assistants differ in ways that matter for specific jobs and are near-identical for others, and a team that has seen that for itself makes better decisions than one that has been sold a subscription.
Why the team writes the red lines
A policy handed down from outside is ignored by lunchtime. A one-page rule the team wrote in the room, with their own examples of what must never go into a public model, tends to survive. Client names, salary data, unpublished financials, student records, patient details: the list is short and specific, and it is different for every organisation.
The three-day variant
For teams that want more than one working prompt each, the day expands rather than changes.
| Day | Focus | Adds |
|---|---|---|
| 1 | The one-day syllabus above | Foundations, one workflow per person |
| 2 | Depth on the team's top three tasks | Each task worked end to end with the model; templates the whole team shares; edge cases and failure modes |
| 3 | From workflow to process | Which of the workflows are worth automating; a walkthrough of one automation in n8n; a plan for the first month |
Day three is where training meets automation. Not every team needs it. A team whose work is mostly judgement gets more from a second day of practice than from a day on automation.
What to skip
Things I leave out of a corporate day, deliberately:
- Prompt "hacks" and jailbreaks. Entertaining, not useful, and they date within months.
- Image and video generation. Unless the team is a design or marketing team, this is a demo, not a skill.
- Tool tours. Twenty tools in an hour teaches nobody anything. One tool, used well, transfers.
- Certificates. I will provide attendance letters if HR needs them, but a certificate does not mean the person can do anything. The four-week number does.
How to know if it worked
Ask one question four weeks later: how many participants are still using the workflow they built on the day?
A good session lands above half. A session where nobody brought real work lands near zero, regardless of how well the day was received. That number is more useful than a feedback form, and it is the one I ask organisations to send me.
The follow-up that makes the number go up is not another workshop. It is what happens inside the team in the weeks after: one person owning it, the workflows written down where people can find them, and a short check-in at week two.
Booking one
Sessions run in person in Kathmandu and across Nepal, or online for teams elsewhere. I take a limited number of dates because I am a practitioner who teaches rather than a full-time trainer, which is also why the worked examples come from systems that actually run rather than from a slide deck.
If you need a certified curriculum with formal assessment, a dedicated training institute is the better fit and I will say so on the pre-call. If you need a team that uses the tools well by the end of the month, start here.
Questions
Our team is not technical. Is this too advanced?
No. The syllabus assumes nobody has used an AI assistant seriously before, and almost none of it involves code. The people who get the most out of the day are usually the ones who do repetitive writing, research or data work by hand: accounts, admin, sales, HR. Technical staff often need a different session.
Which AI tool should we standardise on before the workshop?
Pick one that your organisation can actually pay for and that fits your data rules, then use it consistently on the day. ChatGPT, Claude and Gemini are all suitable. The comparison between them is covered honestly in the session, but switching tools mid-workshop wastes an hour. If you have no preference, I will recommend one during the pre-call.
Can this be delivered online?
Everything except the hands-on afternoon works well online, and for teams outside Kathmandu that is often the practical option. The afternoon exercises depend on walking between pairs and looking at screens, which is genuinely worse over video. For an online delivery I split the day into two half-days and keep groups under fifteen.
