Write the job down the way you would brief a new hire, and most of your disappointing AI output goes away. That is the answer, and it has three parts: the steps in the order you actually perform them, two or three samples of output you would send to a customer plus two or three you would not, and the exceptions you currently handle by instinct without telling anyone. At Orion Intelligence Agency we build these workflows for small businesses, and the pattern we see is consistent: the model is rarely the broken part. The undocumented process is. This piece covers how to pick the one workflow worth writing down, what goes in each of the three sections, where the page should live, and how to edit it after every miss.
The model is filling in gaps you left blank
A model given an underspecified request will produce the average answer, and the average answer is exactly what disappoints you. Ask for "a follow-up email to this lead" and you will get a competent, generic follow-up email. It will not know that you never open with "I hope this finds you well," that you always reference the specific service the lead asked about, that you sign off with a scheduling link and not a question, or that leads from your referral partner get a different tone than leads from the contact form. None of that is in the request, so the model invents something plausible. That is the mechanism. It is not a defect you can prompt your way out of one message at a time, because every new session starts from the same blank.
Here is the test that makes this falsifiable. Take the last output you rejected. Write down, in plain sentences, exactly why you rejected it. If you can write that reason down, the model could have followed it. If you cannot write it down in under a minute, you have found the real problem, and it was never in the model.
Pick the workflow you have explained twice this month
Choose one workflow, and choose the one you have already explained out loud to another person recently. That is the signal. Explaining it twice means it is repeatable, it is not obvious, and it costs you time in a form you can feel. Good candidates for a small business: turning a site visit into a quote, writing the weekly customer update, triaging inbound service requests into urgent and scheduled, drafting the job posting, summarizing a call into a CRM note with next actions.
Do not start with the workflow that is most valuable. Start with the one that is most describable. A high-value process you cannot articulate will produce a vague document, and a vague document produces exactly the output you are already unhappy with. You want a first page that works, because the first page that works is what convinces everyone else to write theirs.
Section one: ordered steps, written as decisions
Write the steps in the order you do them, and write each one as a decision rather than a topic. "Check the customer's history" is a topic. "Open the customer record. If they have bought from us before, reference the last product by name in the first sentence. If they have not, reference how they found us" is a decision. The second version can be followed. The first cannot, by a new hire or by a model.
Number them. Keep each step to one or two sentences. If a step needs a paragraph, it is two steps. Where a step depends on information the model will not have, say where that information comes from: the invoice, the intake form, the calendar entry, the last three emails in the thread. This sounds tedious, and it is, for about twenty minutes. Then it is written for good.
One useful discipline: dictate it. Open a voice memo, walk through the workflow out loud as if training someone standing next to you, and transcribe it. Your spoken version will contain the conditionals your written version tends to skip, because when you speak you naturally say "unless" and "but if it's a rush job." Those are the most valuable sentences in the document.
Section two: two or three good samples, and the same number of bad ones
Samples do more work than instructions, and bad samples do more work than good ones. Paste in two or three real outputs you were happy with. Then paste in two or three you rejected, and under each one write a single line explaining the rejection: "too long," "used the word partner, we say client," "invented a delivery date," "asked a question instead of proposing a time." That line is the part that transfers. A good example alone shows a target. A bad example plus its reason shows a boundary, and boundaries are what stop the drift you keep correcting by hand.
Use real work, with customer names swapped out. Invented samples encode how you imagine you write, not how you actually write, and the gap between those two is precisely where the output starts to feel off-brand. Three real ones beat ten fabricated ones.
Keep the bad samples permanently. There is a temptation to delete them once the workflow starts performing, because the page looks cleaner without them. Resist that. The bad samples are the reason it performs.
Section three: the exceptions you handle by instinct
List the situations where you break your own rules, because those are the failure cases that make the output unusable. Every workflow has them and almost nobody writes them down, because by definition you handle them without thinking. Prompts for finding yours: What makes you rewrite a draft from scratch? Which customer gets special treatment and why? What time of year changes the answer? What do you never put in writing? When do you pick up the phone instead?
Write each exception as a trigger and a response. "If the request came in after 4pm Friday, do not promise a same-week slot; offer Monday and Tuesday." "If the customer mentions a competitor by name, do not respond in writing at all, flag it for me." That second kind matters more than it looks: an escape hatch is what makes it safe to let the workflow run without you reading every output. You are not trying to cover every case. You are trying to cover the cases where being wrong is expensive, and to route those back to a human.
Keep the page in a file you own and can edit
Put the document somewhere you control: a doc in your own drive, a markdown file in a folder, a page in the wiki you already pay for. Not buried in a chat history, not locked inside one vendor's prompt library that you cannot export, not in a tool that a single employee has the login for. The reason is practical rather than philosophical. This page is the asset. The model underneath it will be replaced, probably more than once in the next two years, and each time you switch you should be able to carry the same page across and get the same behavior on the first try. If you cannot copy it out, you did not write down your process, you rented it.
Ownership also means editing. One named person owns the page. Changes to how the work gets done go into the page first and into the model second, not the other way around. When the page and the actual practice disagree, the practice has quietly changed and nobody logged it, which is the same condition you started in.
Edit it after every miss, and treat that as the real work
The document earns its value in the corrections, not in the first draft. Every time the output comes back wrong, do not just fix the output. Spend the extra minute to add one line to the page: a new bad sample with its reason, a step made more specific, an exception you had not surfaced. This is a habit, not a project. Suppose you touch the page after each miss for the first two weeks; for illustration, that is a handful of edits, most of them a single sentence, and the miss rate you feel in week three is noticeably different from week one because the gaps are getting closed in the order you actually encounter them.
Measure it simply. Note how long the workflow takes you by hand today, and how many outputs you had to rewrite out of the last ten. Those two numbers, taken again at 30 days and 60 days, tell you whether the page is working. If you want the fuller method for timing a single workflow honestly, we wrote it up separately. A workable target for a first page: get the rewrite rate low enough that reviewing the output costs less than producing it did, and stop there. Perfection on a page nobody reads is not the goal.
A 30/60/90 that ends with a document
Thirty days: one workflow, one page, three sections. Dictate the steps, paste in the real samples, list the exceptions. Run it live, edit after every miss. Do not add a second workflow.
Sixty days: the page has stabilized and someone other than you can run the workflow using it. That is the actual test, and it is worth staging deliberately: hand the page to an employee, let them run the workflow with the model, and watch where they hesitate. Every hesitation is a missing sentence. Now write the second page, for the next workflow you have explained twice.
Ninety days: you have two or three of these pages in a folder you own, each with an owner and an edit history. This is what a governed workflow looks like at small-business scale. Not a policy binder. A short document per workflow that says how the work is done here, kept current by the person who does it, portable to whatever tool you use next.
The part that transfers
The reason this works is that you already have the process, you have just never externalized it. Everything hard about the exercise is retrieval, not invention: getting what is in your head onto a page in a form another party can follow. The model is the least interesting participant. It is a fast, literal new hire with no memory of Tuesday and no instinct for your customers, and it will do the job right the moment you tell it what right means, with examples, including the counterexamples.
Write the page. Keep it in a file you own. Edit it after every miss. That is the whole method, and the reason we lead with it is that the businesses getting real value out of AI are not the ones with better tools. They are the ones who wrote it down.