A team can leave an AI workshop with pages of ideas and plenty of interest. Two weeks later, most people are working exactly as they did before.
The workshop created a shared starting point. Adoption depends on what happens when people return to full calendars, client deadlines and familiar ways of getting work done.
Training creates interest, then the working week takes over
Most people leave a good workshop intending to practise. Then Monday arrives. Email, meetings and delivery commitments take priority, and the new tool sits outside the habits that already get work finished.
People usually return to the method they know when the deadline is close. AI can feel slower during the first few attempts because the person is learning how to provide context, judge the response and correct weak output. That early effort needs room in the working week.
A general demonstration leaves too much work for the user
A demonstration can show what ChatGPT can do. The person still has to connect that example to their own documents, systems, responsibilities and standards.
Broad instructions to use AI more rarely survive contact with real work. Give each team a small set of named tasks: prepare a prospect brief, turn meeting notes into assigned actions, draft a project update or compare a document with an approved checklist.
Each task needs approved inputs, an expected output and someone who can judge the result. That gives people a place to begin and a reason to try again.
Managers set the real expectation
Staff notice what their manager asks for, reviews and uses. If AI appears once in a workshop and disappears from team meetings, people read the signal quickly.
Managers need to take part in the practice. They can ask how a recurring report was prepared, review an AI-assisted draft against the usual standard and discuss where the method saved effort or created more checking. Their role is to make the new behaviour part of normal work.
This also gives managers a clearer view of where AI is useful. A polished response can still contain a weak assumption, an old source or language that the business would never use.
Unclear rules make sensible people cautious
People hesitate when they do not know which information they may use, whether a client document is approved or who will answer a question about risk. Others make their own judgement and create avoidable exposure.
Give the team short, usable rules with examples from the business. Cover company information, client material, personal information, connected apps and the work that always needs qualified review. Name the person who can settle questions quickly.
Access matters too. Licences, workspace membership, source permissions and approved apps should be ready before the training task begins. A blocked login during the first week can be enough to end an experiment.
People need repetition to build judgement
One successful prompt can create confidence that disappears with the next, messier example. People learn through repeated attempts across normal work, incomplete information and awkward exceptions.
Short weekly practice works well because the gap between attempts stays small. Run an office hour, use-case clinic or team review where staff bring a live task and the output they received. Discuss what they gave the tool, what came back and what they changed.
The aim is sound judgement: knowing how much context to provide, which claims to check, when to ask another question and when to complete the work without AI.
Useful experiments need to become shared methods
Early adopters often find good ways to use AI, then keep the method inside their own chat history. The rest of the business receives a prompt without the source material, examples or checking that made it work.
Capture the whole method. Record its purpose, approved inputs, instructions, example output, review checklist, owner and review date. Store it where the team already keeps working procedures.
Ask another person to run it. A method becomes useful to the business when different people can produce an acceptable result and know how to handle exceptions.
Someone has to own the month after training
Follow-through usually fails when responsibility is spread across IT, a senior sponsor and several team leaders. Each assumes someone else is collecting questions, checking progress and deciding what happens next.
Give one person responsibility for the first 30 days. They coordinate access, schedule practice, collect examples, settle questions and report which methods deserve more work. Team leaders remain responsible for the quality of work in their area.
Ownership also keeps the rollout honest. Some use cases will create too much rework, depend on poor source information or solve a problem the team barely has. Stop them and put the effort somewhere better.
A practical 30-day follow-through plan
During the first week, confirm access and information rules, then give each team 2 to 4 recurring tasks to test. Set the expected output and review owner for each task.
In weeks 2 and 3, hold a short weekly clinic using live examples. Keep a record of questions, output problems, rework and any method that saved time or improved the finished work. Managers should request at least one agreed AI-assisted output through the normal team process.
In week 4, decide which methods to document, change or stop. Set owners and review dates for the methods you keep. Schedule the next check before attention moves elsewhere.
- Named rollout owner
- 2 to 4 recurring tasks per pilot team
- Approved inputs and review requirements
- Weekly practice using live work
- Manager participation
- A 30-day decision on every tested method
Product references
Official OpenAI sources
Product information was checked against these sources on 24 August 2026. Addaptive’s implementation advice reflects our work with Australian teams.