AI Workshops for Consultants: Put AI on the Writing Around the Work, Not the Judgement Clients Pay For

Point AI at the writing that surrounds an engagement, meaning the proposals, scoping documents, project reports, client updates and meeting notes, and keep it away from the diagnosis and the recommendation themselves. That line is the decision this page is about. A workshop earns a full day of your time if it helps you draw that line for your own practice and leaves you with a drafting workflow built on your own material, tested on a real engagement.

TL;DR

• The risk in a consultancy isn't a clumsy AI draft. It's a persuasive wrong one. In a randomised experiment run inside BCG with 758 strategy consultants, the people using AI on a problem the model got wrong still scored higher on recommendation quality than the people working without it. 1
• Decide by asking what a document has to be right about. Documents that restate a decision you have already made are safe to draft with AI. Documents that make the decision are not.
• On the safe side, the gains are large rather than marginal. Across eighteen realistic consulting tasks inside the model's range, the same study measured faster completion and substantially higher graded quality. 2
• Most of the distance between a generic draft and one you would actually send comes from the written context you assemble, not the assistant you pick.
• Client confidentiality settles your tooling before capability does. Sort the data question first, then build the workflow.
• The public workshop is a full day in person at Avani Mooloolaba Beach Hotel, The Cove room, Mooloolaba, at A$495 excluding GST per person for a maximum of 15 paid attendees, on Wednesday 7 October 2026. Private onsite training and implementation are separate engagements, each scoped and quoted.

Which parts of consulting work does AI actually help with?

The paperwork that describes the work, rather than the work itself.

Proposals and scoping documents. Project and status reports. The fortnightly client update. Turning a set of meeting notes into an actions list that names who owns what. The methodology section you have now written forty times with four words changed. The handover pack. The invoice narrative that has to explain what the last month bought.

What those documents share is that the thinking behind them is already finished. You know the scope, because you decided it. You know the price. You know what you saw in the client's operations room on Tuesday. Writing it up is assembly with structure, and it happens after six.

That is a real and large amount of time, and it's the part of the job clients are least willing to pay for directly, which is the honest reason it gets done badly and late. AI workflows for custom sales proposals sit exactly in that gap: high volume, repeated structure, decisions already made elsewhere.

The training market has noticed the same thing. Consultant-specific courses now build their curriculum around drafting proposals, RFPs and engagement plans with large language models. 3 One European provider frames the entire pitch as moving from a scoping note to a client report faster while keeping editorial control. 4 They are pointing at the right target. What most of them skip is the other half of the sentence.

Where AI hollows out the work clients are paying for

Give it the decision instead of the write-up and it will quietly degrade the one thing your fee is attached to.

This is not a hunch. In 2023, researchers from Harvard Business School, Wharton, MIT Sloan and Warwick ran a pre-registered randomised experiment inside Boston Consulting Group with 758 strategy consultants, about seven per cent of the firm's individual contributors. They built two tasks. The first sat inside what they called the jagged technological frontier, the uneven boundary of what the model can genuinely do. On that one, across eighteen realistic consulting tasks, the consultants with AI completed 12.2 per cent more tasks, worked 25.1 per cent faster, and produced work graded more than 40 per cent higher in quality than the control group. 2

Then they built a second task designed to fall just outside that boundary. It was based on a real business case: a spreadsheet that looked complete, plus interview notes containing the detail that changed the correct answer. Consultants without AI got it right about 84.5 per cent of the time. Consultants with AI were 19 percentage points less likely to reach the right recommendation. 5

Here is the finding that should stop a consultant in their tracks. The graders scored the quality of the recommendations separately from their correctness, and the AI groups scored higher on quality whether or not the underlying answer was right. 1 Better structured. Better argued. More confident. Wrong.

Think about what that does inside a client relationship. The failure mode is not a partner spotting an awkward sentence and sending it back. It's a board reading a clean, well organised recommendation that nobody interrogated, acting on it, and discovering the problem two quarters later. Your reputation is the asset. It is the thing priced into your day rate, and it is the only reason a client picks you over a cheaper firm with a similar deck.

Two smaller findings from the same study sharpen the point. The researchers also measured how similar participants' ideas were to each other, and found a marked reduction in variability among the AI users, which suggests more homogenised output. 6 If differentiated thinking is what you sell, converging on the same answer as everyone else with the same assistant is a commercial problem, not just an intellectual one. And the participants who performed worst were the ones who blindly adopted the model's output and interrogated it less. 7 The tool didn't cause the damage on its own. The absence of a review step did.

How do you decide which documents AI can touch?

Ask what the document has to be right about. That single question sorts almost everything on your desk.

The middle row is where consultants get hurt, because it feels like the first row. Gathering and structuring is genuinely quick with an assistant, and the output looks finished. But the failure the BCG experiment produced was precisely a clean synthesis that missed the line in the interview notes that changed the conclusion. If you cannot point at the source behind each claim in a synthesis, you are not reviewing it. You are proofreading it.

The bottom row has a use most people miss. Once you have written the recommendation yourself, hand the model your reasoning and ask it to attack it: what evidence would have to be true for this to be wrong, what has been assumed rather than shown, what a sceptical CFO would ask first. That is AI on the judgement layer without AI making the judgement, and it is the one place in an engagement where a homogenised, conventional-minded assistant is an advantage, because conventional objections are the ones you will actually get in the room.

Whatever you decide, the review step needs to be written down rather than remembered. A defined way to check AI output that names what gets verified against what source is the difference between a workflow and a habit that decays the week you get busy.

The proposal workflow we built inside my own business

I sell services for a living, so I write proposals. In my own business, Searchmaxxed, we built an AI workflow to prepare custom ones, alongside the workflows we run for blog creation and SEO.

I'm not going to tell you how to scope an engagement. You have run more of them than I have, and the value in your proposals is the diagnosis and the judgement behind the numbers. What I can show you is the layer underneath that, because I had the same problem you have: the thinking was done and the document still took a night.

The important thing about that workflow is what it does not decide. It doesn't set scope. It doesn't set price. Those exist as written decisions before it runs. What it does is assemble: the client's situation in the words they used, the problem I diagnosed, the work I'm proposing, what sits outside the boundary, the commercial terms. The draft that comes back is a document I edit, not a document I discover.

Two things made the difference, and neither of them was the model.

The first is context. Giving an assistant the actual material a business runs on, the scope language, the exclusions, the standard terms, the notes from the real conversation, produces something entirely different from asking a disconnected chat window to guess your facts. The generic proposal everyone complains about is generic because the input was generic. When I feed it my own written material it drafts in my language, because that language is in front of it.

The second is rules, specifically the rules about what it must never invent. Numbers are the obvious one. If a figure isn't in the notes, the instruction is to leave a marked question for me rather than produce a plausible amount. Same with dates, same with anything about the client's business I haven't recorded. That single rule turns a draft from something I have to audit line by line into something I can read as a draft.

Both of those are inputs you write, and they are the bulk of the five-input prompt we teach: Context describes the business and the situation, Task names the job, Source supplies the approved material, Rules set the limits and flag what's missing, Output describes the shape of the finished document. Write those five well for a proposal and the same workflow runs on the next engagement's notes. Write them badly and you get the draft everyone else is complaining about.

What does a full-day AI workshop cover for a consulting practice?

One repeated task from your practice, built and tested in the room on your own material.

For a consultant, the choice of task matters more than it does for most trades, because your repeated documents vary in how much judgement they carry. Pick one from the first row of the classification earlier on this page. A proposal from an agreed scope. A monthly client report. The standing project update. Bring the source material that job actually needs: the notes, the template you use now, a previous version you were happy to send, and your rules about what you never claim in writing.

You write the five inputs, run them on that example, read what comes back against your own source material, then fix the inputs where the draft went wrong. That last step is the session. A first attempt usually comes back partly right, and the interesting part of the full day is working out which part is wrong, why, and what to write differently. You leave with the instructions, not with principles to apply later.

You can see the public workshop details and register now if the timing suits. People travel to the Sunshine Coast for it from Brisbane and further south.

What do you do about client confidentiality?

Settle it before you choose a tool, because for a consultancy it constrains everything downstream.

You sit on other people's commercially sensitive material. Strategy that hasn't been announced. Financials. Things people said about their colleagues in an interview believing it would stay in the room. Start by reading your own client agreements and finding what you already signed about disclosure to third parties and subcontracted processing. That's a specific document with your signature on it, and it will answer the question faster than any general discussion of AI policy. Where the answer is unclear or the client is sensitive, ask them. In my experience clients respond far better to being asked than to finding out.

Then make three decisions deliberately rather than by default. Which account and tier you use, and what its terms say about how your content is retained and whether it's used to improve models, since these differ between consumer and business offerings and change over time. What gets redacted before anything is pasted, which is a property of your Source input and therefore something you control. And who in the practice is allowed to do this at all while you're still learning.

For the workshop itself, bring an example you're comfortable working on in a room with other businesses: a de-identified engagement, a past project where you have permission, or your own practice's internal documents. Preparing safe material for AI training is a step in its own right, and doing it once teaches you the redaction pattern you'll reuse on every real engagement afterwards.

None of that is legal advice, and I'm not qualified to give you any. It's the order of operations that keeps the question from being answered accidentally by whoever on your team discovered a chatbot first.

Should your practice learn to build this, or have it built?

Both are available here, and they answer different situations.

Training is the entry rung. The public workshop, or private onsite training at your office, teaches your team to build a workflow and run it themselves. Implementation is the managed rung, where the system gets built and connected for you. They are separate engagements with separate scope and price, and which one fits depends less on budget than on how much the work will keep changing.

Learn to build it when the workflow is intimately yours and moves with every engagement. A proposal workflow is a good example: the language, the exclusions and the rules are your commercial position, they change as your positioning changes, and handing that to an outside party to maintain means re-explaining your business every time you adjust it. You want the person who writes proposals to own the instructions.

Have it built when the thing needs connecting rather than composing, when it has to run reliably without anyone remembering to trigger it, or when it touches systems that should not be experimented on during a full-day session. If that's the shape of your problem, enquire and we'll scope it. There's no rate card to quote you here, because the price follows the scope and the scope follows a conversation.

Providers in this space tend to draw a hard line between training and consulting, treating them as alternatives you pick between. One Australian company puts the choice plainly: training if you need to build skills across a team, consulting if you have a defined challenge needing a bespoke solution. 8 That distinction is a real one, and the difference between AI training and consulting engagements is one to understand before you commit. Our view is that they're two rungs of the same ladder rather than a fork in the road, and most practices sensibly start on the lower one.

For a team, private onsite AI training runs at your workplace and is scoped around your people's actual tasks, their experience level and your location. Sessions suit roughly 4 to 20 people, larger teams get split across sessions, and a fixed quote follows a conversation about what you want to work on. Team size, session length and travel determine the price. Private onsite training is available across the Sunshine Coast and in Brisbane, Gold Coast, Ipswich, Noosa, Moreton Bay, Logan, Redlands, Toowoomba and Gympie.

The implementation experience behind all of it is specific, so let me state it plainly rather than dress it up. We helped automate internal processes at Radiant Roof Repairs with AI, before I left to run Searchmaxxed and Sunshine Coast AI Workshops. We used AI to automate SEO, enquiries and admin for Glen House Homoeopathy. And in Searchmaxxed we built the blog, SEO and custom proposal workflows I described above. Three businesses, three different sets of constraints, and the same pattern each time: the model was never the hard part.

Frequently asked questions