Roll out ChatGPT or Claude around one useful task, with a named owner, permitted sources and a reviewer who can judge the result. Test ordinary and awkward cases, practise the complete job with the team, then decide whether to expand. Seats and a training session are inputs; useful, accepted work is what you are trying to establish.
The sequence below is a practical implementation method for small teams. Its stages are decisions rather than a fixed number of weeks. Existing users may already have a strong starting point; involve them in finding what works.
Start with the ambition and the people doing the work
Ask what the business wants to make possible and invite the people involved to show a recent case. They may want more time for client conversations, a more consistent handover or an easier way to find a current answer. Avoid presenting AI use itself as the goal.
Describe one complete task: what starts it, which inputs it uses, what it produces, who checks it and what happens next. Capture how it works now, including review and correction. That baseline gives the team a fair comparison later.
Our first-workflow guide includes a candidate worksheet if there are several places to start. Choose a task small enough to inspect, with a result that would matter.
Agree a rollout brief before inviting more people
If columns don't fit, scroll sideways. Keyboard: focus the table and use the arrow keys.
| Decision | Record in the brief |
|---|---|
| Purpose | The useful result and who benefits |
| Task boundary | Trigger, output and what remains outside the test |
| Ownership | Sponsor, day-to-day operator, reviewer and administrator |
| Sources | Permitted material, current versions and who maintains it |
| Actions | What the tool may prepare and what requires approval |
| Success | Written acceptance criteria and evidence to collect |
| Exceptions | What to do when information or access is missing |
| Operation | Who maintains instructions, handles questions and can stop use |
Do not fill unknowns with reassuring assumptions. Give each material unknown an owner and a check. You may discover the task needs better instructions or a current template before it needs AI.
Choose the account and access arrangement
Work out which account or workspace owns company work, who administers membership and what happens when a person leaves. Check the provider's current plan, contractual and data-processing terms against the actual task. Where staff already use individual accounts, first inventory the existing use.
OpenAI's business-data page describes its default treatment of business data. That is one input to the decision; your permission to process a customer's material and your obligations for storage, retention and access still need checking.
Agree access before connecting a large document collection. Prefer the smallest useful source set and permissions needed for the task. Confirm access with the actual roles that will operate and review it, rather than relying solely on an administrator's successful test.
Build the test pack before teaching a shortcut
Select permitted examples that represent the work, including cases that should stop. Write the acceptable behaviour for each before looking at the generated answer.
For an internal policy-summary task, a compact pack might contain:
- A current, complete policy and an ordinary question.
- A question whose answer is absent from the permitted material.
- Two conflicting versions, only one of which is approved.
- A request to make a customer commitment outside the task's authority.
- A case where the operator cannot access the relevant source.
These are suggested case types, not a claim that five tests prove safety or suitability. Add cases that reflect the task's consequences. Record failures, revise the design and rerun affected cases. A successful ordinary example does not cancel a failed permission check.
Anthropic's Building effective agents supports starting with the simplest adequate approach. Its tooling examples date from 2024; the useful principle here is to justify added complexity with evidence. Many first tasks need clear instructions and good review rather than an autonomous agent.
Ready for a person to decide. The draft has its source beside it. The customer lead checks the wording, edits it and decides what to send.
Read both paths
Complete information: customer request and approved policy → prepared draft with source → customer lead reviews → ready to send if approved.
Conflicting policy: customer request and conflicting sources → draft withheld → policy owner resolves the source → draft is prepared again for human review.
A fictional teaching example, not a client result or a live ChatGPT or Claude session. The handover does not send a message automatically.
Train the whole job, including correction
Let people practise a case using the proposed arrangement. Training should cover finding the right source, making the request, checking the output, correcting it and completing the handover. Show what a held case looks like and where to ask for help.
Use a short practice record:
Task and source version: [ ]
What the tool prepared: [ ]
What I checked and changed: [ ]
What I could not establish: [ ]
Reviewer decision and next step: [ ]
This gives the operator something more useful than a list of clever prompts. Ask where the method feels awkward and change it with the team. If people need to copy the same material through several applications, investigate the process rather than assuming they need more encouragement.
A fictional rollout decision
The following is illustrative, not a client case or an implementation timetable.
A team tests preparation of internal meeting follow-up. The tool may organise permitted notes into a draft action list. A person must confirm names, commitments and dates before sharing it.
In practice, the draft is easy to read, but an ambiguous note becomes a confident deadline. The team changes the instruction and review checklist: uncertain dates are left visibly unresolved. It adds that case to the test pack and checks the next revision.
The useful decision is whether this complete arrangement now supports acceptable work. It is not whether everyone has logged in or whether the draft looks professional. The review step is part of the design, not an inconvenience to remove from the measurement.
Expand when the evidence supports it
Compare the whole task with the baseline: accepted output, operator effort, review, corrections, exceptions and running cost. Ask whether people can operate the arrangement without the original designer beside them. The measurement guide shows how to keep these categories separate.
Decide to continue, revise, simplify or stop. If you expand, identify what changes: sources, users, volume, actions or consequences. Recheck the affected boundaries. A tested internal drafting task does not automatically authorise customer sending or record updates.
Hand over something the team can maintain
Keep the task instructions, source register, access owners, test cases, review method and recovery steps together. Record who can change them and how a change will be checked. Agree any ongoing support separately.
Our ChatGPT + Claude Implementation service works through these decisions with your people. A free 25-minute Fit Call establishes fit and a useful next step; implementation, dependencies and acceptance are scoped in writing before you commit.