Before you start a request, your client fills in a short plain-text brief. This page gives you that brief blank, and filled in for a real landing-page request. See what a good one looks like before your first client sends you one. It has two parts: an account section, filled in once, and a request section, filled in for every job.
What goes in once, and what goes in every request
The template has two parts. The account section is filled in once per client, at onboarding. It covers who can submit requests, who can approve, who covers when the approver is away, and where the brand files live. You review it when people or terms change, not every week.
The request section is copied for every new job. It asks for the outcome the design must support, the audience, and the exact deliverables and sizes. It also asks for the approved copy version, what must not change, and how you will both know it worked. If you only enforce one field, make it the copy version. Most rework starts with a designer laying out copy nobody has signed off.
Keep a requested deadline separate from a studio estimate. The client writes the date they want and why it matters. You write your estimate only after you have checked readiness and the queue. Mixing the two is how "Friday" turns into a promise you never made. The onboarding walkthrough shows where this sits in the first week with a new client.
One rule for both sections: do not put payment-card details, passwords or unnecessary personal information in this document. Point to where things live instead. The brief is an operational aid, not a contract, and it does not replace checking who owns the rights to an asset.
The filled-in example: a webinar landing page
Filled-in example (illustrative). The client is invented: a 12-person B2B invoicing software company on a solo designer's subscription. Priya, the marketing manager, sends requests. Tom, the founder, approves. The same request, REQ-014, runs through review and approval in the workflow and approval checklist, so you can follow one job from brief to handoff.
ACCOUNT SETUP (filled once, 1 March 2027) Client/account reference: Client 03, B2B invoicing software company, 12 staff Studio account owner: Alex (studio owner and sole designer) Requester and permitted submission channel: Priya Shah, marketing manager; new requests on the Trello "Requests" list only, not Slack or email Authorised approver and scope of authority: Tom Reid, founder; signs off design and final copy Substitute approver or absence procedure: Priya Shah approves when Tom is away for more than two working days Billing contact / responsible billing-record reference: Tom Reid; Stripe customer record for Client 03 Agreed service / scope-policy reference: Standard plan, one active request, scope page v2 Service start conditions confirmed by: Alex, first payment received 26 February 2027 Brand guidance and reusable asset location: Shared Google Drive folder "Client 03 / Brand" (logo files, brand guide PDF, fonts) Access restrictions / approved storage: Drive folder shared with Priya and Tom only; no passwords recorded here Asset permissions and licence checks owned by: Priya Shah [x] Client access checked without exposing unrelated accounts [x] Requester understands active limits and queue priority rules [x] Feedback and approval method explained REQUEST BRIEF Request identifier and working title: REQ-014, Landing page for the spring webinar Requester: Priya Shah Studio delivery owner: Alex Purpose / outcome the design must support: get finance leads to register for the 22 April webinar on month-end close Audience and context of use: finance managers at 20 to 200 person firms, arriving from the invite email and LinkedIn, about half on mobile Deliverables, formats and dimensions: one desktop layout (1440 wide) and one mobile layout (390 wide) in Figma; hero image exported at 1600x900 and 800x800 Required export or source-file handoff: Figma file shared with Priya; hero exports as JPG and WebP Approved copy location and version: Google Doc "Webinar landing page copy", v3 Assets, references and access locations: speaker photo and last year's webinar page, both in "Client 03 / Webinar 2027" Brand constraints / mandatory elements: logo lock-up from the brand guide; sign-up form above the fold on desktop What must not change: logo lock-up, brand green, the form fields (the developer has already built them) Acceptance criteria tied to the purpose: headline, date and sign-up button visible without scrolling on a 390-wide screen; one call to action only Requested deadline and reason: approved files by Friday 19 March, because the invite email goes out Tuesday 23 March Dependencies or coordinated launch events: invite email on 23 March; webinar Thursday 22 April Final approver for this request: Tom Reid READINESS CHECK [x] Within agreed service scope [x] Deliverables and acceptance criteria are understood [ ] Copy approved and assets accessible with appropriate permissions [x] Approver identified and available under the review arrangement [x] Dependencies and deadline context assessed Missing input | responsible person | agreed next action/date: Final headline not approved (v3 has two options) | Tom Reid | choose one by Wed 3 March Speaker photo licence unclear | Priya Shah | confirm with the photographer by Thu 4 March Decision: [x] Return to intake [ ] Ready for queue [ ] Scope review Decision owner and recorded date: Alex, Tue 2 March 2027 Update Thu 4 March 2027: headline chosen (copy v4), photo licence confirmed in writing. Decision: [ ] Return to intake [x] Ready for queue [ ] Scope review Decision owner and recorded date: Alex, Thu 4 March 2027 Queue priority agreed with: Priya Shah (first in the queue) Estimate to communicate after scheduling assessment: first review Tue 9 March, subject to the queue Next client update and its owner: Alex, Mon 8 March
Look at the readiness check. On Tuesday the brief looked complete, but the copy had two headlines and nobody knew whether the speaker photo could be used. Alex sent it back with two named owners and two dates. Two days later it moved to Ready. Ready does not mean active: it joined the queue, and the first review date was given only after that.
Put it in Trello, Notion or a form
Trello. Paste the request section into the description of a card and mark that card as a template. Ask clients to create new requests from it on a "Requests" list. Put the account section on a pinned card at the top of the client's board. Trello's free plan covers up to 10 collaborators per Workspace (Trello pricing), which is enough for a solo studio and a few client contacts.
Notion. Make the request section a database template, so each new page opens with the fields already there. Clients can be invited as guests to the pages they need rather than as paying members.
A form. Google Forms or an Airtable form turns each field into a question and drops every answer in one place. Airtable only charges for people with edit permissions, so clients who just fill in the form do not cost you a seat (Airtable pricing). Keep the readiness check out of the form. That part is yours, not the client's.
When the brief comes back half empty
It will. Do not start designing around the gaps and do not chase each gap in a separate Slack message. Go through the readiness check once, write every missing input as one list, and give each line a named owner and a date. Then send the list back and mark the request "Return to intake".
A field marked "not applicable" is fine if it has a reason. "Brand constraints: not applicable" is not fine for a client with a brand guide. Keep the request in intake until you, as delivery owner, record it as ready. If you are a team, that decision belongs to one person per request. The requests and delivery guide explains how that owner hands work into the queue.
If the same fields come back blank from the same client every time, fix it upstream. Walk them through the brief once on a call during onboarding, using the client onboarding guide to set who can submit and who can approve. Ten minutes there saves a return to intake on most of their requests.
Use this template
Download the plain-text version, or select the text below and copy it into your own document. Replace the prompts with your studio’s decisions.
Download .txtSTUDIOSIFT | BRIEF AND ONBOARDING WORKSHEET Make a private working copy. Replace blanks with agreed answers. Use "not applicable" only with a reason. Do not record passwords or card data. ACCOUNT SETUP (reuse; review when people or terms change) Client/account reference: ____ Studio account owner: ____ Requester and permitted submission channel: ____ Authorised approver and scope of authority: ____ Substitute approver or absence procedure: ____ Billing contact / responsible billing-record reference: ____ Agreed service / scope-policy reference: ____ Service start conditions confirmed by: ____ Brand guidance and reusable asset location: ____ Access restrictions / approved storage: ____ Asset permissions and licence checks owned by: ____ [ ] Client access checked without exposing unrelated accounts [ ] Requester understands active limits and queue priority rules [ ] Feedback and approval method explained REQUEST BRIEF (copy for each request) Request identifier and working title: ____ Requester: ____ Studio delivery owner: ____ Purpose / outcome the design must support: ____ Audience and context of use: ____ Deliverables, formats and dimensions: ____ Required export or source-file handoff: ____ Approved copy location and version: ____ Assets, references and access locations: ____ Brand constraints / mandatory elements: ____ What must not change: ____ Acceptance criteria tied to the purpose: ____ Requested deadline and reason: ____ Dependencies or coordinated launch events: ____ Final approver for this request: ____ READINESS CHECK (studio owner completes) [ ] Within agreed service scope [ ] Deliverables and acceptance criteria are understood [ ] Copy approved and assets accessible with appropriate permissions [ ] Approver identified and available under the review arrangement [ ] Dependencies and deadline context assessed Missing input | responsible person | agreed next action/date: ____ | ____ | ____ ____ | ____ | ____ Decision: [ ] Return to intake [ ] Ready for queue [ ] Scope review Decision owner and recorded date: ____ Queue priority agreed with: ____ Estimate to communicate after scheduling assessment: ____ Next client update and its owner: ____ Moving to Ready for queue is not a start date. Record the start commitment in the queue.