Getting output you can actually use

Most people's experience of AI writing is a draft that's fluent, generic and needs more editing than writing it would have. That's a method problem, and it's fixable in an hour.

What almost everybody types first

Write an email to a client about their overdue invoice.

What comes back is a competent, generic chase letter that could have been sent by any business to any client. It is polite, it is slightly too formal, it invents a payment term you never agreed, and rewriting it takes longer than writing the email would have.

The same job with four sentences of context

You are writing on behalf of a small bookkeeping practice in Australia. The job: a second reminder about an invoice that is three weeks overdue. The reader is a long-standing client who is usually prompt, so the tone is a check-in rather than a chase — assume something has gone astray rather than that they are avoiding it. Keep it under 120 words, no attachments referenced, and do not state a payment term or a consequence, because I have not decided on one yet. End by asking whether they would like it reissued.

What comes back is close enough to send after one read. The difference between the two is not a trick or a magic word. It is four sentences that a first-morning assistant would have needed anyway.

The whole skill, in one comparison. Who the reader is, what the constraint is, and what must not appear.

The problem with the first draft

Ask for a client email and you get a client email: grammatical, structured, and written for nobody in particular. It reads like a template because functionally it is one — the tool had nothing specific to work with, so it produced the average of everything it has seen. Customer replies are the clearest case — answering customer emails with AI shows the fix.

The fix isn't a clever prompt. It's giving the tool the same four things you'd give a capable new employee before asking them to draft something.

The four things

Context. Who is reading this, what do they already know, what happened before, and what should happen after they read it.
Examples. Two or three of your own past documents of the same type. This single step does more for voice than any instruction about tone.
Constraints. Length, structure, what must be included, what must not be mentioned, reading level, and any phrase your industry can't use.
A rejection. The first output is a starting position. Saying what's wrong with it specifically is faster than rewriting it, and it's the habit most people never form.

The test we use in the room

Take a document you've written forty times. Get a draft you would send without editing. If you can't, the gap tells you which of the four things is missing — and it's almost always examples.

What this looks like by the end

A first draft you correct rather than rewrite, on the documents you produce most often.
A written brief for your three most common documents, saved where the team can use it.
A clear sense of which jobs are worth the setup time and which are faster by hand.

Where it goes next

Once the output is usable, the next question is how to stop rebuilding the setup every time — that's building reusable setups. If the documents you care about are long, working with long documents comes first.

What this module covers

The gap between text that looks finished and text you would actually send. Most self-taught use gets stuck here: the output reads plausibly, so people either send it and regret it, or rewrite it from scratch and conclude the whole thing is a waste of time.

Giving the tool the three or four facts it can't infer, rather than a long instruction.
Showing it a good past example instead of describing the style you want.
Saying what the document is for and who reads it — the single change that most improves output.
Fixing a draft by naming what's wrong with it, rather than starting again.
Recognising a confident wrong answer, which is the skill that makes the rest of this safe.

What someone can do afterwards

Takes a job they do regularly and gets a usable first draft in one or two exchanges instead of five, and can tell you why the bad version was bad. The second part matters more than the first: it's what transfers to the next job and the next tool.

Where it sits in the order

First, always. Every other module assumes it. A team that can't get usable output has nothing to apply reusable setups to, and no basis for judging which tool suits which job.

Where this module stops

This is not a prompt library. We hand out a short one because people ask, and the starting library is deliberately brief — fifty prompts teach copying, a handful that match your real jobs teach judgement. The module teaches the judgement and leaves the copying alone.

If you know which job you'd want the room practising on, that's the session half planned.

Start an enquiry

The questions we get asked about this

Isn't prompting the whole skill?

It's the smallest part. Knowing what to supply, what to show as an example, and how to tell a confident wrong answer from a right one is what separates someone getting value from someone getting plausible text.

Does this change when the models improve?

The specifics get easier. The judgement doesn't: a better model still can't know the three facts only you hold, and still produces confident wrong answers occasionally.

Get a training plan built for your business. Nine questions about how your business actually runs. You get a plan ordered for your work, a reading on where you're exposed, and one clear place to start. No account needed. Build your plan.