Use the account section once per client and the request section for each new job. Store the working copy in your own approved system. The worksheet asks for references to assets, not uploads to this site.
Complete it with the requester
Ask the requester to supply the intended outcome, approved content and deliverable specifications. Have the studio delivery owner check whether those answers are sufficient to start. A field marked "not applicable" needs a reason when its absence could affect production.
Keep a requested deadline separate from a studio estimate. Record why the date matters, then assess readiness and capacity before accepting a commitment. The onboarding walkthrough explains the order of these checks.
Use the readiness decision
Return missing inputs as one list with named owners. Keep the request in intake until the delivery owner records it as ready. Payment confirmation belongs with the responsible billing record; do not put payment-card details, passwords or unnecessary personal information in this document.
Use the onboarding guide to adapt permissions and approval authority to the client's organisation. This worksheet is an operational aid, not a contract or a substitute for checking asset rights.
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: ____ Ready does not mean active. Record a start commitment in the queue.