The first request is a useful rehearsal of the service you have sold. It reveals whether the client knows how to brief work, whether the studio can assess it and whether both parties understand when delivery begins. This is a suggested workflow, not evidence from a product test or a client case study.
Agree the start condition
Before inviting the client into production, confirm the accepted scope and the commercial condition for starting. The billing owner should verify the account in the responsible system. Avoid treating a forwarded payment email as the authoritative record or assuming that paid means brief-ready.
Use the policy in billing and retention to handle exceptions. If a studio permits work before settlement, record who authorised it and what boundary applies instead of allowing the exception to become an unwritten default.
Run the first-request handoff
- Confirm account readiness: service, start condition, billing owner and any unresolved restriction. Pass a clear status to the person onboarding the client.
- Name the requester and final approver. Ask who resolves internal disagreement and who acts if the approver is away.
- Invite only the people who need access. Check what the client can see and explain where requests, feedback and final files belong.
- Collect reusable brand resources and permissions. Ask for approved asset locations instead of duplicating sensitive files across messages.
- Complete the first request using the brief and onboarding worksheet. Keep purpose, deliverables, content and deadline context together.
- Have the delivery owner inspect scope and readiness. Return missing decisions in one consolidated reply, or accept the request into the ready queue.
- Assess available capacity and record the start decision separately. Communicate the next update and a conditional first-review estimate only after this check.
Make the readiness check specific
For a hypothetical presentation request, "brand assets supplied" is not enough if the studio cannot access the font licence or the linked imagery. "Copy supplied" is not enough if different stakeholders are still rewriting the argument. Ask whether the materials are usable and authorised for this job, not merely present.
A useful missing-input message names the request, lists the unresolved items, assigns each to the client or studio and explains the effect on scheduling. For example, ask the approver to confirm the final copy version before layout begins. Do not imply that the original requested date remains committed while a dependency is unresolved.
Teach the operating rules through the job
Show the client where this request sits and how another request would enter the queue. Explain whether waiting for feedback retains an active slot. Ask the approver to practise finding the current version and making a clear decision rather than watching a long tour of unrelated features.
The broader onboarding guide covers account design, while the delivery guide defines the state transitions. Keep the wording consistent across both the written policy and the client interface.
Review the first cycle before adding tools
After the first handoff, record which information needed chasing and whether the client used the intended channel. Fix the intake instructions if a required decision was easy to miss. Fix permissions if the right person could not act. Neither problem automatically requires a new platform.
Investigate a client portal only when repeated access or visibility needs remain unresolved. For regulated or confidential work, agree storage, access and retention requirements before collecting assets. This operational workflow does not establish legal or security compliance.