What should you bring to an AI workshop?

What to Bring to an AI Workshop

Bring a laptop, its charger, the jobs your business repeats, the source material that task needs, and a version of a real example you're comfortable opening in a room full of other business owners. That last one is where people come unstuck, so most of this page is about it. The rest fits in a backpack.

TL;DR

• The task you choose decides everything else you pack. Pick one that comes back at least weekly, ends in a document or a message you already write by hand, and that you're allowed to sign off yourself.
• A good example is an ordinary job, complete, with the version you actually sent attached to it. The two ways people get this wrong are bringing their hardest job ever, or stripping a real one back so far that nobody can tell whether the draft is right.
• If the real job carries customer or client information, prepare a redacted copy the night before. Keep the list of what you took out, because that list becomes rules in your prompt.
• Removing the name is the first step of redaction, not the whole of it. In a small local market, the combination of details left behind can still identify the customer.
• Bring the material the task needs to be correct: the price list, the template, the approved wording, the numbers. Not your whole operations manual.
• Do not pre-build the workflow. Building and testing it is what the full day is for.

What do you actually pack?

Seven things, and none of them are exotic.

If your business has a position on which AI tools staff may use, settle it before the day rather than in the room. A team AI use policy decides that question once instead of every time somebody opens a new tab.

One thing to check if you've booked with someone other than us: sessions differ, so read your own provider's list. AI workshops are organised in various ways depending on the provider and what you've asked for. 1 A university short course might ask for a fully charged computer with wifi, earphones and a working free Google account, because part of the day is independent video watching. 2 A 60-minute session built around a short conversation with a chatbot 3 needs nothing like the preparation a full day on your own work does.

The public session we run is a full day, in person at Avani Mooloolaba Beach Hotel, in The Cove room at Mooloolaba. A seat is A$495 excluding GST per person, and we cap the room at 15 paid attendees so nobody spends the afternoon waiting for a hand. The next date is Wednesday 7 October 2026, and you can register now on the full-day public workshop page.

Which task should you bring?

One that passes three tests: it repeats, it produces something, and you can sign it off.

It repeats. At least weekly, ideally more. A task you do twice a year won't pay back the instructions you write for it, and you won't remember the workflow by the time it comes round again.

It produces something. A quote, a reply, a report, a listing description, a file note, a proposal section. Drafting work is where you can see the result and judge it on the spot. "Clean up our customer database" and "make our admin more efficient" are goals, not tasks, and a goal can't be tested in an afternoon.

You can sign it off. If the output has to go past two other people before anyone knows whether it's right, you'll leave without knowing whether it worked. Bring the work that stops at your desk.

Most businesses have five or six candidates once they look. The quote written up after a site visit. The reply to the "do you service my area" enquiry that arrives eleven times a week. The Monday morning status update to a client. The follow-up email after a discovery call. The monthly report that takes an hour and says almost the same thing it said last month. If you're torn between two, there's a longer method for choosing which task to automate first, but the short version is: pick the one you resent most.

And if your task has five stages, bring the drafting stage. You can write and test instructions for one stage without connecting a single system to anything.

What makes a good example, and what makes a poor one?

A good example is the most ordinary job you did last week, complete, including what you actually sent back.

There are two ways this goes wrong, and they pull in opposite directions, which is why both need naming.

The first is bringing your hardest job. It's tempting, because if AI can handle that, it can handle anything. But the instructions you end up with are shaped by the exception, and they'll over-explain the ordinary jobs that were never complicated in the first place. Build for the middle of your week.

The second is over-redaction, and I think it's the more common one. Someone takes a real enquiry, removes the name, the address, the property details, the budget and the timeline, and arrives with: "Customer asked about a service. Please reply." A workflow built on that produces a draft that could go to anybody, which means you can't tell whether it's right, which means the test told you nothing. A safe example still has to be complete enough to be graded.

How do you build a safe example when the real job has customer details in it?

Copy one real job into a blank document, take out what identifies the person, keep everything that makes the job hard, and write down what you removed. It takes about ten minutes.

Copy, don't carry. Paste the job into a new plain text or Word file with a boring name. That way you never open your CRM, your client folder or your accounting file in a room full of people you met that morning, and the file you upload is the file you chose rather than whatever else was on that screen.

Take out the direct identifiers. Full name, address, phone, email, account and invoice numbers, dates of birth, patient or matter references. Replace the name with a stand-in and keep it consistent all the way through, because if one line says "Sarah" and the next says "the customer" and a third says "S.W.", the draft comes back inconsistent and you'll blame the model for it.

Delete contact details rather than inventing fake ones. A made-up mobile number that survives into a sent message is worse than a blank, and blanks are what your rules are for.

Keep what makes the job the job. The quantities, the measurements, the real prices, the customer's actual wording including the typo, the question they asked that you couldn't answer, the measurement they didn't give you. Those are the parts the instructions have to handle. Round every price to a neat thousand and you've deleted the arithmetic you came to check.

Widen instead of blanking. "A two-storey house in a coastal suburb" keeps the constraints that matter, which are salt exposure, height and access, without keeping the street number. Location is usually a constraint on the work, not an identifier, until you write it to the letterbox.

Check where details hide. The file name. The document footer and the letterhead template. The email signature, and the quoted chain sitting underneath it. Tracked changes and comments. The second tab of the spreadsheet. The attached photo.

Then read it back cold, as if you'd found it on a table in the venue. Removing the name is where de-identification starts rather than where it finishes: Australia's privacy regulator describes the process as two steps, the removal of direct identifiers and then the removal or alteration of other information that could be used to re-identify someone, and notes that removing name and address alone may not be enough. 4 That matters more here than it would in a capital city. On the Sunshine Coast, "the two-storey place on the corner, tile roof, insurance job, works at the surf club" is a name. Whether the Privacy Act binds your particular business is a separate question for your own advice, but the test in the room is simple enough: could anyone here work out who this is?

Finally, keep the removal list. Two lines at the bottom of the same file: removed: customer name, street address, mobile, invoice number. That list earns its keep twice. It tells you exactly what to put back when you run the workflow on a live job, and it converts straight into rules, one of the five inputs every prompt needs: the customer's name and address are supplied with each job, never invent them, and flag them if they're missing.

For health, legal, financial or children's information, take the more cautious road. The same regulator recommends as a matter of best practice that organisations do not enter personal information, and particularly sensitive information, into publicly available generative AI tools. 5 Build a composite instead: the same shape of job, the same awkward details, an invented person. You'll write the same instructions and they'll run on the real file afterwards, on your own systems, under your own rules. There's more on preparing safe AI training data if your whole business runs on information like that.

What source material should come with the task?

Whatever the task needs to be correct. Not everything about your business.

For a quote, that's the current price list or rate card, the template you send, the inclusions and exclusions you're not free to reword, and your lead times. For a customer reply, it's your service area, what you don't do, and the two or three answers you give constantly. For a report, it's last month's version and the numbers this month's version has to carry.

Two pages of your own approved wording beats a sixty-page policy document, because you'll be checking the draft against it line by line. Pull out the part that governs the task.

Prepare those files before the day rather than typing context in the room, which is the same advice workshop facilitators give each other: it's often much more effective to prepare context-providing documents before the workshop, so participants can upload them rather than compose them live. 6 Keep the formats plain and test them yourself first, by uploading the file and asking the model to prove it can read it. 6 A PDF that turns into soup when it's uploaded is a twenty-minute detour, and you can find that out at home instead of in the room.

One more thing to bring, and people forget it: a finished output you'd be happy to send again. That's the target. Everything else is the route to it.

The one thing not to prepare

Don't build the workflow before you arrive.

If you turn up with a finished prompt you wrote alone on Sunday night, you'll spend the session defending it instead of testing it, and the testing is the part that's hard to do by yourself. The full day goes on naming the task, writing the instructions, running them on your example, finding the three things the draft gets wrong, and adding a rule for each one. That loop is the skill. There's a written version of it in how to build your first AI workflow if you want to see the shape of it in advance.

What you leave with is the written instructions and the example you tested them on, which means you can run the same thing on Tuesday's job. Run it, then check the output against your source material before it goes anywhere. When a draft misses the same thing twice, that's a missing rule, not bad luck.

I've built AI workflows on real business material a few times over now. We helped automate internal processes at Radiant Roof Repairs with AI, where I worked before I left to run Searchmaxxed and Sunshine Coast AI Workshops. In Searchmaxxed, my own business, we built AI workflows for blog creation, SEO and custom proposals. We used AI to automate SEO, enquiries and admin for Glen House Homoeopathy. My read across all of that: the instructions are the straightforward half. What the model gets to see, and in what shape, is the decision that determines whether the output is any good, and your example is that decision.

Bringing a team changes the preparation

If you're sending several people, agree on the tasks before anybody packs.

Two people working on the same task get further than two people working on two tasks, and the pair that works best is the person who does the job and the person who signs it off. That second person is the one who knows the rules nobody has written down. For the public workshop, each person needs their own seat, so a team of five is five seats in a room capped at 15.

Private onsite training runs at your workplace instead, scoped around your team's tasks, experience and location, with a fixed quote after we've talked it through. Sessions are scoped for roughly 4 to 20 people, and larger teams can be split across more than one. Everyone brings the laptop they'll use afterwards, and we confirm tool and account requirements during scoping rather than leaving you to guess. Private onsite AI training is the route for that.

The preparation shifts a little for a group, and preparing a team for AI training covers the part that has to happen before the day: one task per pair, one redacted example each, and a decision about who owns the finished workflow.

And if what you actually want is the system built and connected for you rather than your team learning to build it, say so in the enquiry. That's a separate engagement with its own scope and price, and we'd rather scope it properly than sell you a training day that was never the answer.

Frequently asked questions