The Role-Context-Task-Format Framework: How to Brief AI Like a Contractor

You've had this afternoon. You ask ChatGPT for a customer email, get back four paragraphs of beige, spend ten minutes rewriting it into something you'd actually send, and quietly decide the tool isn't worth the subscription.

The model wasn't the problem. The brief was. That gap has a fix with an ugly name — role-context-task-format — and it's the same set of things you'd tell a contractor before they picked up a tool, in roughly the same order.

We teach this first in every client engagement, before anything else. Below is the framework applied to four jobs you probably have on your desk this week, and a way to diagnose output that lands wrong.

The role-context-task-format brief, in plain English

Four parts. Each one closes a specific gap between what you meant and what came back.

• Role — who the AI should be while it works. "An experienced bookkeeper who explains things to non-accountants" produces different vocabulary and different judgment calls than no instruction at all.
• Context — everything about your situation the AI cannot possibly know. Your business, the customer, the history, the constraint you're working around. Paste in the real material here.
• Task — the specific thing you want done, with a number attached where one makes sense. "Draft three replies" is a task. "Help me with this email" is a mood.
• Format — what the finished thing should look like. Length, structure, tone, headings or no headings. This is the part people skip, and it's the part that saves the most editing.

You don't need to write the labels out. Once you've done it a dozen times, a well-ordered paragraph carries the same information. The labels are training wheels, and they're useful precisely because they slow you down long enough to notice you don't actually know what you want yet.

If you want to see the difference this makes side by side, we broke it down in master prompt vs. regular prompt.

Four briefs for jobs you already have

Answering a complaint without sounding like a form letter

A customer is annoyed, you're writing back at 9pm, and the AI keeps producing something that reads like an airline apology.

Role: You are a customer service lead at a small business who
writes warm, plain replies and never sounds corporate.

Context: We're a 6-person residential cleaning company. A repeat
customer of two years emailed to say our team missed the upstairs
bathrooms on Tuesday and left the front door unlocked. She is
justifiably upset. The door thing is serious and we've already
retrained the crew.

Task: Draft one reply that acknowledges both problems, takes clear
responsibility for the door, and offers a free re-clean.

Format: Under 150 words. No bullet points. Sound like a person,
not a policy. Do not use the words "we apologize for any
inconvenience."

That last line matters more than it looks. Telling the AI what not to write is part of format, and it kills the stock phrases faster than anything else. The ready-made version of this lives in our scripts for de-escalating angry customers.

Writing a cold email that doesn't get deleted

Cold outreach fails on context. Most people give the AI their own pitch and nothing about the person receiving it.

Role: You are a founder who writes short, specific cold emails
that get replies. You never use flattery openers.

Context: I run a small IT support firm in Hamilton serving dental
and medical clinics. I'm writing to the office manager at a
4-dentist practice. Their website shows they just opened a second
location. Our angle: multi-site clinics usually discover their
backup situation is a mess only after the second office goes live.

Task: Write one cold email of 90 words or less asking for a
15-minute call.

Format: Subject line plus body. No greeting fluff. One specific
observation about their situation in the first sentence. One
question at the end.

Notice how much of that block is context. That's normal — for outreach, context should be most of the brief, and it's why personalizing cold emails at scale works better as a repeatable prompt than as a template you retype.

Turning "how I do it" into an SOP

This one's the biggest time saver, because the thing being documented only exists in your head.

Role: You are an operations manager who writes procedures that a
brand-new hire can follow without asking questions.

Context: Below is me rambling into my phone about how I close out
the till and lock up the shop. It's out of order and I skip steps
I do automatically. [PASTE YOUR TRANSCRIPT]

Task: Turn this into a written closing procedure. Flag anything
that seems to be missing or ambiguous as an open question at the
end.

Format: Numbered steps, one action per step. Plain verbs. Under
400 words. Add a short "if something goes wrong" section.

The "flag what's missing" instruction is doing real work there. You're asking the AI to audit your own explanation, which catches the steps you forgot you knew. Same principle behind our SOP writer.

Replying to a public review

Public replies are read by strangers, not the reviewer, which changes the format entirely.

Role: You are a small business owner replying publicly to a Google
review. Future customers will read this.

Context: We're a family-run auto shop. Three-star review says the
work was good but the car took two days longer than quoted. That's
accurate — we were waiting on a part.

Task: Write a public reply.

Format: Under 60 words. Thank them, name the delay honestly,
explain the part in one clause without excuses, invite them back.
No marketing language.

Short format constraints are the whole game on review replies. Left unconstrained, every model writes three paragraphs, and three paragraphs on a Google review reads as defensive. Our review response writer bakes the word limits in.

Diagnosing output that missed

When something comes back wrong, one of the four parts is usually thin. Match the symptom to the fix.

• Right facts, wrong voice — the role is missing or too generic.
• Generic, could be about any business — you didn't give enough context.
• It did a different job, or three jobs at once — the task isn't specific, or you stacked several into one prompt.
• Content's fine, shape is annoying — say the format out loud: length, structure, what to leave out.

That diagnostic is more useful than any prompt library, because it means you stop starting over. You adjust one part and re-run.

The voice problem is the one exception, and it has a better fix than more words. If the tone keeps landing wrong no matter how carefully you write the role, stop describing and start showing — paste in two things you've already written and let the model copy them. That's few-shot prompting, and it does the format job better than any instruction can.

Where this breaks

Role-context-task-format makes a good brief. It does not make the AI correct.

A confident, beautifully formatted answer built on a wrong assumption in your context is worse than a vague one, because you're less likely to check it. Anything touching money, employment, contracts, or safety still needs your eyes on it — and in the case of numbers or legal wording, someone qualified.

The framework also runs out of road on genuinely complex work. If you find yourself writing a 600-word brief every single time for the same recurring job, you've outgrown prompting that task by hand. That's the point where it becomes a saved skill or a real system.

Making it stick

Pick one job you do weekly and write the four-part brief once, properly. Save it in a note. Next week you're editing four lines of context instead of starting from nothing, and that's where the time actually comes back.

If you'd rather have the framework taught to you step by step, the free prompt engineering courses cover it with exercises, and the prompt improver will rewrite a rough prompt into this structure so you can see the difference on your own work. For the wider picture, start with our guide to prompt engineering for small business.