If you're choosing an AI workshop for your business, bring a piece of work that is taking too long or needs too much checking. A proposal. A weekly update. The preparation for a management meeting.
I would start there. It gives you something concrete to discuss with a facilitator, and it gives your team a way to judge whether the learning is useful when they return to work.
A long list of AI tools tells you very little about that. You need to know what participants will practise, what information they can use and who will check the result.
Write down the current process
Suppose your team prepares a customer proposal. Someone finds the requirements, pulls together product information and asks a manager to approve the price. A colleague checks the wording before it goes to the customer.
That is an example for planning, not a claim about a particular customer. The work gives you several questions worth answering. Where is time being spent? Which source is authoritative? What decision still belongs to a person?
A useful workshop brief might say: “We want to prepare a first draft from approved requirements and product notes. The sales owner must still check the scope and price before anything is sent.”
That is specific enough to shape an exercise. It also puts a boundary around what the AI is allowed to do.
Choose a result you can inspect
For the proposal exercise, ask what a good draft should contain. Perhaps the requirements must be traceable, the scope must be complete and uncertain points must be clearly marked for review. A fluent paragraph that misses the customer's request should fail the exercise.
Have someone who knows the work review the result. If nobody can explain what makes it acceptable, you will struggle to tell whether a different prompt or tool has made it better.
Keep the first check modest. Compare the result with an approved example. Note what the person still had to correct. If you measure preparation time, record what was included so the comparison remains fair.
I would rather see one exercise survive that check than see a room full of attractive demonstrations with no owner afterwards.
Prepare safe material
Ask what data the exercise requires before putting it into an AI service. Use material your organisation has approved for that tool and account. A redacted or invented example may be enough for the first practice.
Do not bring a complete customer file merely because it is convenient. Decide who can access the material, what must be removed and where the output can be stored. Your organisation's policies and the service's current terms need to guide those choices.
Credentials and security codes have no place in a workshop brief. If an exercise needs a connection to a business system, agree the access and supervision separately. Training should not become an unplanned production change.
Match the workshop to the people doing the work
A founder trying to keep track of commitments has a different learning need from an operations team preparing recurring reports. A technical implementation team has another set of responsibilities.
For a founder session, I would want to understand the decisions you need to make and where the necessary information sits. For a team session, the brief should name the role, the repeated task and the person who can approve a change to the process.
Check the programme's prerequisites and practical requirements. Ask how much time is spent practising, what participants need to prepare and what can reasonably be completed in the session. Keep the agreed programme details in the quotation so the buyer and facilitator are working from the same brief.
Decide what happens after the session
Before booking, name the person who will try the exercise in the normal working week. Agree one small follow-up: use the method on an approved task, record the corrections and discuss whether it should continue.
The review may show that the source documents need work. It may show that checking takes longer than drafting. Both are useful findings. They tell you what needs attention before asking the whole team to use the method.
Keep an approved version of the instructions and the example result. If the process changes, update the source instead of leaving staff to guess which version is current.
A workshop is a sensible next step when there is a real task, someone able to judge the result and time to practise. A business that needs a supported integration or a change to a live system should discuss that scope explicitly.
Bring that brief to the first conversation
Write a few sentences about the task, who does it, what makes it difficult and the result you want to inspect. Leave confidential material out of the initial enquiry.
If you are considering my founder-focused Execution-OS workshop, read the programme and preparation requirements. The current programme describes three half-day sessions, 12 hours in total, and requires a MacBook. Confirm the software requirements, format and scope in your proposal before booking.
Then send me the problem you want to work through. A short description is enough for the first conversation.
For a wider business team, browse MatrixC's course catalogue. If you need help deciding between a workshop and implementation work, review MatrixC's AI services. Explain who will do the work and what support they need.
