# Enquiry to handoff

VertexLineup Studio / SOP VL-OPS-01 / Internal studio draft

| Control | Value |
| --- | --- |
| 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. |

## Purpose and scope

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.

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.

Procedure path: enquiry → intake → scope approval → controlled review → handoff. A scope change or missing client response follows its exception branch before the affected work continues.

## 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.

## 01–02 / Enquiry and intake

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.

## 03–04 / Approval and controlled review

1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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.

### Decision log

| Record | Required fields | Purpose |
| --- | --- | --- |
| 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 branch / Scope changes

1. **Record the request.** Link it to the job and current scope. Name what is added or changed.
2. **Pause the added work.** Continue only work that remains valid under the accepted scope.
3. **Assess the effect.** Record added hours, dependencies, price and schedule effect in a written change proposal. These are project-specific.
4. **Get written approval.** The client approver accepts the revised scope and any required payment condition before I start the addition.
5. **Update the baseline.** Save the accepted change, new scope version and schedule. If declined, retain the accepted scope.

## Exception branch / A silent client

1. **Use the agreed feedback date.** Check that the review file reached the approver and that no question from me remains unanswered.
2. **Send the agreed reminder.** State the missing decision, current version and work affected. Record the contact attempt.
3. **Mark the dependency blocked.** At the agreed pause date, stop the affected task and record what must arrive to resume.
4. **Recheck the calendar.** When the client replies, I confirm inputs and available capacity. Record any revised start or delivery date.
5. **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.

## Other exception routes

**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.

## 05 / Release checklist

The browser ticks are a local review aid. They reset on reload. They are not approval evidence. The real decision log belongs with the project record.

- [ ] **Approval matches the release.** The named approver accepted this exact file version.
- [ ] **The agreed scope is present.** Included files, pages, tabs or sections match the accepted brief.
- [ ] **Applicable checks pass.** Facts, formulas, links, formatting and access work as intended.
- [ ] **Sources and limits are attached.** Provide the source list, assumptions and unresolved limitations.
- [ ] **Files are named and packaged.** Include agreed editable and final formats with a clear version.
- [ ] **Access is tested.** The client can open the files using the agreed permission method.
- [ ] **Use instructions are included.** Explain routine edits, the next step and when the client needs a reviewer.
- [ ] **Release conditions are checked.** Payment, licences and support match the approved project documents.
- [ ] **The handoff record is complete.** Record recipient, date, version, location and outstanding action.
- [ ] **The next owner is clear.** Name who maintains the output and when further work needs a new scope.

Owner review and recorded client approval remain required even when every draft check is marked.