Last quarter I tracked every client-facing task that passed through my AI writing tool: eighty tasks in all, the ordinary output of an advisory practice - proposals, scope memos, executive briefs. I split the batch in half to see what would happen if I changed exactly one habit and nothing else. The half that kept prompting the way most professionals do took an average of fifty-one minutes per task to reach a draft a client could actually see. The other half took twenty-six. Same tool. Same people. Same client stakes. The only variable was five lines of writing, done before the first prompt ever went in.
I want to be precise about what this is and is not. What follows is a composite drawn from a full quarter of drafting work in my own practice, not a single client's file and not one writer's anecdote. I am reporting a pattern, not a case study with a name attached, because the pattern is the useful part.
Eighty tasks, one quarter, one tool throughout, split into two comparable batches of forty. Group A went from a short prompt - two or three lines, the way almost everyone uses these tools - straight to a draft. Group B did one extra thing first: five lines of specification, averaging six minutes to write, before the first prompt was typed.
Group A accepted nine of forty drafts on the first pass, 22.5 percent, and needed an average of 3.4 rounds of revision to reach something usable. Each round - a prompt, a human review, a re-prompt - ran about fifteen minutes. Multiply it out: 3.4 rounds times 15 minutes is 51 minutes of work per task, and that is before counting the time spent on the original prompt itself.
Group B accepted twenty-eight of forty on the first pass, 70 percent, more than three times the acceptance rate of Group A, using the identical tool. Average revision rounds fell to 1.3, or 19.5 minutes, and adding the six minutes spent writing the spec beforehand brings the total to 25.5 minutes, which I round to 26. Fifty-one minutes down to twenty-six - a 49 percent reduction in total task time - while first-draft acceptance more than tripled.
Why the Same Tool Produces Two Different Practitioners
When two people get very different results from identical software, the instinct is to look for a skill gap in using the tool: better prompt phrasing, a cleverer system message, a more expensive model. I do not think that is where the gap actually lives, at least not for client-facing drafting. The gap I keep finding is upstream of the tool entirely. It is whether the task was specified before it was prompted, or specified through the prompt itself, in real time, under time pressure, one revision at a time.
A prompt asks a tool to produce something. A specification tells the tool what "acceptable" means before it starts. Those sound similar and are not. A prompt can be excellent and still leave the tool guessing about the reader, the non-negotiables, and the finish line - and every one of those guesses becomes a revision round later. The professional and the amateur, in my data, were often using the exact same tool with the exact same access. The professional had simply moved the guessing to before the draft instead of after it.
The Five-Line Spec: What Goes on Paper Before the First Prompt
The five lines that separated Group B from Group A were not complicated, and none of them required special technical knowledge. They took an average of six minutes to write. Here is what they cover, in the order I write them.
- Audience - who actually reads or uses this output, and what they already know. A scope memo for a client's CFO reads nothing like one written for a first-time buyer of advisory services, and the tool cannot infer which one you mean.
- Boundary conditions - one thing that must appear in the draft, and one thing that must not. This is the single fastest way to eliminate the most common revision: content that is technically responsive but wrong for this particular client or this particular moment.
- One worked reference example - a real sample of what good, or bad, looks like. Not a description of tone. An actual example the tool can pattern-match against, because tools are far better at matching an example than interpreting an adjective like "professional."
- Definition of done - the specific, checkable condition that makes a draft acceptable. Not "make it good," but something you could hand to someone else and have them verify without asking you a follow-up question.
- Fallback instruction - what the tool should do when it is uncertain: ask, flag the gap, or stop, rather than guess and hand you a confident, wrong paragraph to catch on review.
Five lines. None of them ask the tool to do anything differently. All five simply remove decisions the tool would otherwise have to make silently, and those silent decisions are where most first-draft rejections come from.
What the Six Minutes Actually Buys You
Six minutes feels like friction in the moment a task lands on your desk and you want the draft now. That feeling is exactly why Group A behavior is so common - it is not a lack of discipline, it is a completely reasonable response to time pressure that turns out to be false economy. The six minutes did not disappear in Group B's numbers. It moved earlier in the process, where it is cheap, instead of staying scattered across 3.4 rounds of revision, where it is expensive and interrupts two people's attention instead of one.
The more durable return is not the twenty-five minutes saved per task, useful as that is. It is what a 70 percent first-pass acceptance rate does to a practitioner's relationship with the tool. At 22.5 percent acceptance, every draft is a small negotiation, and it is easy to conclude the tool is unreliable. At 70 percent, the tool starts to feel like a colleague who mostly gets it right on the first try, because the ambiguity that used to live in the prompt has already been resolved on paper before anyone typed anything.
I have written elsewhere about how professional judgment shows up in places people don't expect it - my other writing covers some of that ground. This particular habit is one of the smaller ones, and one of the easiest to test for yourself this week: take the next client-facing task, write five lines before you open the tool, and count your revision rounds. The arithmetic tends to make its own case.
For more on this and related work, see BrianServes, the platform for deploying autonomous AI e-mployees and Webspot, the AI strategy firm in Beirut.
