Most business prompts fail for the same reason: they describe the topic but not the job. "Write something about our new service" gives the model no role, no audience, no constraints and no definition of done, so it returns something plausible and useless. A five-part structure fixes almost all of that, and it takes about ninety seconds longer to write.
The five parts
Role, context, task, constraints, output format. Every one of them answers a question the model would otherwise guess at, and guessing is where the generic output comes from.
Role: who the model should be. "You are a bookkeeper reviewing a supplier invoice" produces different judgement than "you are a copywriter"
Context: what it needs to know that is not obvious. The business, the audience, what happened before, what is at stake
Task: the single thing you want done, stated as a verb. Not a topic, an instruction
Constraints: what to avoid, how long, what tone, what it must not assume or invent
Output format: the shape you want back. A table, five bullet points, a draft email, a JSON object
What each part actually buys you
Role and context are the two most people skip, and they are the two that change the answer most. A model asked to review a contract as "a careful commercial lawyer flagging risk" surfaces different clauses than one asked to "summarise this contract", because the first framing tells it what to care about.
Constraints do the unglamorous work of preventing the failure modes you have already seen. If the last three drafts came back too long, say the word limit. If it keeps inventing statistics, tell it not to include figures it cannot source from the material you supplied. Constraints are where your accumulated annoyance becomes useful.
Output format matters more than it sounds, because it determines whether the response is usable without rework. Asking for a table when you are going to paste into a spreadsheet saves a reformatting step every single time you run the prompt. Over a task run weekly by three people, that reformatting is the difference between a tool that gets adopted and one that quietly gets abandoned.
A worked example
Weak version: "Summarise these customer emails." Strong version: "You are a customer operations lead at an Australian trades business. Below are twelve support emails from the past fortnight. Identify the three most common complaints, quote one real line of customer wording for each, and note which are fixable in our process versus outside our control. Do not invent issues not present in the emails. Return a three-row table with columns: theme, customer quote, fixable yes or no."
Same input, same model. The second version returns something a manager can act on in a meeting; the first returns a paragraph nobody reads. Notice that nothing in the strong version is clever. It is just the brief you would have given a person, written down instead of assumed.
Turning good prompts into shared assets
A prompt that works should not live in one person's chat history. The pattern that holds up in practice is a shared file of the prompts your team actually reuses, with a one-line note on what each is for. Ten good prompts beat a hundred filed and forgotten ones.
Keep the ones used weekly or more; delete the rest rather than curating a graveyard
Note who owns each prompt, so there is someone to update it when the process changes
Record the failure you were fixing, because the constraint will look arbitrary in six months without it
Review the set quarterly, since prompts written for an older model often carry workarounds that are no longer needed
When to stop refining
There is a point where prompt engineering stops paying. If a prompt has been rewritten five times and still misses, the problem is usually the input, not the wording, and no amount of role-setting fixes missing context. That is the moment to give the model the actual source material, connect the actual system, or accept that the task needs a person.
For prompts you will run repeatedly, the payoff is different. A prompt used weekly by four people is worth twenty minutes of careful drafting and worth saving somewhere shared. Put a number on it: if that task takes each person fifteen minutes a week and you employ them at a fully loaded $95,000 a year, the four of them are spending roughly $4,500 a year on it. Twenty minutes of prompt work against that is an easy trade.
What not to conclude
This is a structure, not a spell. It will not make a model accurate about facts it does not have, and it will not make a bad task a good one. It also is not a reason to write a five-paragraph prompt for a thirty-second question, plenty of quick asks are fine as a single line. The structure earns its keep on work that matters or repeats, which for most businesses is a smaller set of tasks than they expect.
If your team is getting inconsistent results from the same tasks, book a short call and we will look at which prompts are worth standardising.
