I write operating documents that name the trigger, the person responsible and the evidence needed to move forward. This studio draft takes a business enquiry through intake, approval, review and handoff.
Purpose: keep one current brief, one named client approver and a clear record of each decision. Use this procedure when an enquiry may lead to a scoped document, spreadsheet, design or business-support project.
Version
0.1 / portfolio specimen
Process owner
Dhairya Patel / studio owner
Release state
Draft. Owner review required before use.
Review trigger
Change to service scope, tools or approved terms.
This is a working procedure draft, not a legal policy or a completed client record. Project prices, payment, privacy, retention and cancellation terms come from the approved project documents. No response or delivery commitment is added by this sample.
01 / EnquiryRecord the requestOutput, purpose and timing.
02 / IntakeComplete the briefInputs and one approver.
03 / ApprovalConfirm the scopeWritten acceptance.
04 / ReviewControl the versionFeedback and exceptions.
05 / HandoffRelease the filesChecks and next steps.
Roles and decision rights
I / studio owner
I qualify the request, write the scope, check capacity, make the work and record the decision. I control the current version and release the approved files.
Client approver
One named person confirms the brief, supplies permissioned source material, consolidates feedback and approves the final deliverable. Other contributors send feedback through this person.
Qualified reviewer, if needed
An agreed specialist reviews an accounting, legal, funding or other professional decision within their remit. Their involvement and sign-off must be scoped. The specimen does not imply a standing team or completed review.
Steps 01–02 / Entry gate
Record enough to decide whether the work fits.
Open one enquiry record.
Record the received date, channel, contact, business, requested output, intended use and requested date. Assign a reference. Link later correspondence to the same record.
Check fit and capacity.
I compare the request with the service scope, available hours and required competence. I record accept for scoping, ask for missing information, refer or decline. An enquiry does not reserve a start date.
Name the client approver.
Confirm who can approve the scope and final work. Ask how they will collect feedback from contributors. If authority is unclear, pause the proposal.
Gather the brief and source material.
Record the reader, decision, output format, must-have content, supplied assets and permission to use them. Ask for the source behind factual claims. Mark missing records and assumptions.
Define acceptance and dependencies.
Write what a complete deliverable must contain, what is excluded and which inputs or approvals allow each stage to begin. Record the agreed feedback date and a pause date for missing inputs.
Gate A / Complete enough to quote
I can name the output, intended use, client approver, source inputs, exclusions and acceptance check. Open questions are recorded. If a missing fact changes the scope, I resolve it before quoting.
Minimum intake checklist
One enquiry reference and named approver.
Intended reader, purpose and file format.
Source list with permission and missing items.
Inclusions, exclusions and acceptance criteria.
Requested timing, dependencies and review dates.
What I avoid
I do not request passwords in a public enquiry, promise an unconfirmed date or write unsupported business claims into a draft. I do not start with a large questionnaire when five missing facts will resolve fit.
Steps 03–04 / Approval and controlled review
Keep one approved scope and one current version.
Issue the scoped proposal.
I write the deliverables, inclusions, exclusions, review process, inputs, responsibilities and acceptance criteria. Commercial terms reference the approved project agreement. I include the proposed schedule and its dependencies.
Record written acceptance.
Save the approver’s acceptance, the final scope version and any conditions. Check the required payment and complete-brief gate under the approved terms. Confirm the actual start only when those conditions and capacity are satisfied.
Build from a controlled source list.
Keep the original inputs linked to the working file. Label assumptions. I check factual statements, calculations, accessibility and file behaviour that apply to the deliverable. Record an unresolved issue instead of hiding it in polished copy.
Send one review version.
Use a reference and version number. State what I need the client to check and the agreed feedback date. Ask for one consolidated list with location, requested change and reason. Archive the previous version.
Classify each change.
A correction fixes a mismatch with the accepted brief. A revision changes an included item through the agreed review process. An added deliverable, new requirement or new direction enters the scope-change branch below.
Record final approval.
Link approval to the exact file version and acceptance criteria. Resolve open factual or specialist-review items before release. Silence is never recorded as approval in this procedure.
Gate B / Ready for release
The named approver has accepted the current version. Applicable checks pass. Open limitations are written. Required payment and access conditions match the approved project documents.
The decision log
Record
Required fields
Why it exists
Scope acceptance
Reference, scope version, approver, date, acceptance and conditions.
The work starts from the same agreed brief.
Review decision
File version, feedback location, classification, action and owner.
A change can be traced to its reason.
Final approval
File version, approver, date, acceptance check and unresolved limits.
The released file matches the accepted file.
Pause or change
Trigger, blocked task, dependency, next action and revised schedule status.
The next step remains clear when the path changes.
Exception branches / Document the stop points
The procedure still works when the project changes.
Scope changes
Record the request. Link it to the job and current scope. Name what is added or changed.
Pause the added work. Continue only work that remains valid under the accepted scope.
Assess the effect. Record added hours, dependencies, price and schedule effect in a written change proposal. These are project-specific.
Get written approval. The client approver accepts the revised scope and any required payment condition before I start the addition.
Update the baseline. Save the accepted change, new scope version and schedule. If declined, retain the accepted scope.
A silent client
Use the agreed feedback date. Check that the review file reached the approver and that no question from me remains unanswered.
Send the agreed reminder. State the missing decision, current version and work affected. Record the contact attempt.
Mark the dependency blocked. At the agreed pause date, stop the affected task and record what must arrive to resume.
Recheck the calendar. When the client replies, I confirm inputs and available capacity. Record any revised start or delivery date.
Follow the approved agreement. Closure, cancellation or payment decisions use its terms. If those terms do not answer the situation, I seek a documented decision before acting.
Missing evidence or conflicting instructions
I flag the exact claim or decision, its source gap and the person who can resolve it. I ask the client approver for one direction. I keep the affected item on hold until the answer is recorded.
An issue after handoff
I record the file version, the issue and how to reproduce it. I compare it with the approved acceptance criteria and support scope. I classify correction, new work or specialist review before committing the next action.
Step 05 / Release checklist
Make the handoff usable without me.
Work through this draft checklist. The ticks are local and reset on reload. They are a review aid, not approval evidence. The real decision log belongs with the project record.
0 of 10 draft checks marked. Owner review and recorded client approval are still required.
The Markdown download contains the full procedure, roles, gates, exception branches and release checklist. It can be adapted after owner review.
