A client brief tells you what your client wants to happen. A project plan tells you what has to be done, by whom, and in what order. Those are different documents, and the gap between them is where most freelance projects lose their first week. Converting one into the other takes about twenty minutes and three passes: pull out the deliverables, mark everything you need from someone else, then write down what the brief did not say.
The last pass is the one that matters. The most expensive part of a brief is never what is in it.
Why can’t you just work from the brief?
Because a brief is written by someone describing an outcome, and you need a sequence. “We’re relaunching in November and need the site to match the new brand” is a perfectly good sentence that contains no tasks, no dependencies and no dates you can hold anyone to.
Work straight from it and two things happen. You start with the part you find most interesting rather than the part that blocks everything else, and you discover the missing pieces one at a time, each as a small emergency.
Pass 1: Pull out the deliverables
Read the brief once and write down every noun the client will actually receive. Not activities. Things.
A typical four-paragraph brief email contains between three and six of these, and usually only two are stated plainly. The rest are implied by a phrase like “and make sure it works on mobile” or “we’ll need something for the socials too”.
Each deliverable gets a line with a verb in front of it and a rough size. “Build five page templates.” “Write three social posts.” “Export a print-ready PDF.” If you cannot put a size on it, that is not a deliverable yet, it is a question — keep it for pass three.
The test for a good deliverable line
Could someone else tell whether it is finished without asking you? “Improve the homepage” fails. “Replace the homepage hero with the new brand image and headline” passes. This sounds pedantic until the invoice, at which point it is the only thing that matters.
Pass 2: Mark what you need from other people
Go through your deliverable list and put an owner on every prerequisite. Most of them will not be you: copy, logins, brand files, product photos, approvals, a decision about which of two directions to take.
These are the tasks that actually control your dates. Your own work is predictable because you have done it before. Waiting on a client who is also running a business is not.
Two rules make this survivable:
- Every client-owned item gets a date, and the client is told the date. Not “send me the logos when you can”. “I need the logo files by Thursday the 9th to hold the 20th.”
- Every client-owned item gets a consequence, stated once, neutrally. “If they arrive later I will confirm a new delivery date based on what is free that week.”
Do this in the plan, not in your head. A prerequisite you are carrying mentally is a prerequisite that gets chased three days too late. Keeping client-owned tasks in the same list as your own is the point of having one list at all, which we go through in how to manage multiple clients as a freelancer.
Pass 3: Write down what the brief did not say
This is the pass people skip, and it is the one that prevents the project going sideways in week three. Five questions surface almost everything that is missing:
- Who approves this, and who sees it before they do? A project with one reviewer and a project with a committee are different jobs at different prices.
- What already exists that I have to work with or around? An old site, a locked template, a brand guide, a developer who owns part of the stack.
- What is driving the date? A campaign, a trade show, a board meeting, or nothing in particular. Dates with nothing behind them move easily. Dates attached to an event do not move at all.
- What does done look like? A file, a live site, a handover session, a signed-off PDF. “Done” is the single most commonly assumed and least commonly stated item in any brief.
- What happens after? If they expect you to be available for changes in December, that is a separate piece of work and it should be priced now, not negotiated in December.
Send those as a short list, not a paragraph. Five numbered questions get answered. A friendly wall of text gets “yep all good”.
The reply that halves your risk
Before any work starts, send one email that plays the plan back. It is the cheapest insurance available to a freelancer and it takes five minutes.
“Confirming what I have: five page templates, three social posts, one round of revisions each, delivered by the 20th. That assumes I have the logo files and final copy by the 9th. Copywriting and photography are not included. Anything outside this I will quote separately before starting. Let me know if I have read anything wrong.”
Five sentences: deliverables, date, what you need from them, what is excluded, what happens to extras. A “yes” to that email is a written scope, whether or not either of you ever signs a contract. If you want the longer version of the exclusions list, it is in how to stop scope creep before it starts.
For website work the dates that matter most are the client’s review dates, because a late review moves everything after it. The guide on planning reviews before a website launch shows what a single late input does to the rest of the schedule.
Turning the plan into something you can work from
A plan that lives in an email is a record, not a working document. To be useful on a Tuesday it needs three properties:
- Every line has a date. Including the ones the client owns.
- It sits next to your other clients’ work. A project plan that only shows one client cannot tell you whether the 20th is realistic, because the 20th is shared.
- Blocked items look different from unstarted ones. Otherwise you carry the weight of work you literally cannot do.
The slow part of all this is the typing. A brief arrives as prose and a plan is a structured list, and converting one to the other by hand at eleven at night is exactly when items get dropped. That conversion is the thing TASKUL was built to do: you paste the client’s email in, and it comes back as a project with the deliverables as tasks, the prerequisites separated out, and a draft quote you can edit and send. You still make the judgement calls in pass three. The retyping is the part worth removing — and it is worth being clear about which parts of freelance admin that applies to, which is the subject of AI for freelance admin.
The same three passes work on feedback as well as on a brief. Turning client feedback into tasks applies them to a reply that mixes an agreed edit with a question and a new request.
A worked example
Take a brief of the kind that turns up on a Monday:
“Hi — we’re relaunching the brand in November and the website needs to match. Home, about, services, two case studies. We’ve got the new logo and colours from the designer. Also we’ll need something for socials to announce it. Budget’s not huge. Can you let us know cost and timing?”
Pass one gives five deliverables: home page, about page, services page, two case study pages, and an unspecified number of social assets. Pass two finds four client-owned prerequisites: the logo and colour files, copy for five pages, the two case studies themselves, and a decision on how many social assets. Pass three finds the real questions: who signs off, what the November date is attached to, whether “the website” is a rebuild or a reskin of the existing one, whether case study content exists or needs writing, and what happens after launch.
The brief as written could be a two-week job or a two-month one. Twenty minutes of conversion is the difference between quoting a number and guessing one.
Frequently asked questions
What if the client refuses to answer the questions?
Answer them yourself in writing and send them your assumptions. “I have assumed the existing site structure stays and you are supplying copy.” An assumption a client did not correct is nearly as good as an answer, and it is far better than an open question you both forgot about.
How long should this take?
Twenty to thirty minutes for a normal project brief, and it happens before you quote, not after. If you are spending two hours, you are designing the solution rather than scoping it. Scoping asks what has to exist. Designing asks how it should work, and it is paid time.
Should I share the project plan with the client?
Share the parts that involve them: deliverables, dates, and what you need from them by when. Your internal sequence is not useful to them and invites opinions about how you work rather than what you deliver.
What if the brief is a phone call, not an email?
Then you write the brief. Send the summary within a few hours, while the detail is still accurate, and ask them to correct anything wrong. Briefs that were never written down are the most expensive kind, because both people leave the call certain they agreed on something.
Does a plan help if the project is small?
The three passes take five minutes on a small job, and small jobs are where undefined deliverables do the most damage, because there is no margin to absorb them. A half-day job that grows by three hours has lost its entire profit.
