# Operations manual — fictional Faro Studio example

Original SOPFlow teaching example. All roles, references and outcomes are fictional. Administrative service work only. Adapt and test before approval; this file is not an approved policy for your business.

Faro Studio is a fictional five-person service business. Its first manual covers incoming administrative requests, their weekly follow-up and changes to the instructions. The roles, IDs and completed results are teaching examples, not customer records or an approved manual for your business.

- **Manual reference:** M-OPS-001 · example revision 1 · maintained by the Operations lead.
- **Scope:** From receipt of a routine service request to an acknowledged owner and next action. Quoting, payments and emergency response follow separate procedures.
- **Working roles:** Request coordinator records the request; Delivery lead accepts the next action; Operations lead maintains the instructions and resolves ownership gaps.
- **Current home and records:** A maintained manual index links to OPS-101, OPS-102 and DOC-101. Individual request records stay in the team’s approved work system.

## Procedure index

Reference | Procedure | Maintaining role
--- | --- | ---
OPS-101 revision 1 | Register and assign a service request | Operations lead
OPS-102 revision 1 | Review open service requests weekly | Delivery lead
DOC-101 revision 1 | Review a change to the instructions | Operations lead

## OPS-101: register and assign a service request

Example revision 1. Begin when a routine request arrives through the team’s approved channel. The coordinator needs the request reference, a permitted contact reference, the requested outcome and a Delivery lead who can receive it.

1. Coordinator: open the source request, confirm its reference and check the requested outcome. Link to the authorized source rather than copying private contact details into the manual.
2. Coordinator: create or update the work record with its reference, requested outcome and relevant constraint. If information is missing, use the exception path before routing it as ready.
3. Coordinator: propose the Delivery lead as receiver and record the next action and agreed due point. Link to OPS-101 revision 1 in this example record.
4. Delivery lead: open the source, check that the task is within scope and acknowledge ownership of the next action. Ask the coordinator to resolve unclear information.
5. Coordinator: confirm the acknowledgment is visible. Mark intake complete only when the receiver and next action are recorded; otherwise keep the request pending.

**Exception:** Leave the request pending, name who must supply the missing item and ask the Operations lead to resolve an unassigned request. Do not mark it accepted merely because a message was sent.

**Completed fictional record:** REQ-018 · requested outcome: schedule a routine service review · source: demo request reference · receiver: Delivery lead · next action: propose a review slot · due: next agreed business day · acknowledgment: recorded · status: intake complete under OPS-101 revision 1.

## OPS-102: review open service requests weekly

Example revision 1. Owner: Delivery lead. Trigger: the agreed weekly review point. This cadence belongs to the example; choose timing appropriate to your work. Prerequisites: the current open-request queue, source references and the Operations lead's escalation route.

Outcome: every open item has an acknowledged next action or an explicit unresolved item with an owner. Each review creates a new record.

1. Delivery lead: open the current queue and check requests still pending or in progress against their source records.
2. For each request, confirm its receiving owner, next action and agreed due point. Ask the coordinator to clarify incomplete information.
3. Refer unassigned or overdue items to the Operations lead. Record the decision and next check; keep unresolved items visible.
4. Save the review record with the queue references, actions, unresolved items and OPS-102 revision 1. Do not overwrite an earlier week's result.

Exception: if a source record is inaccessible, leave that item unresolved, name the access owner and arrange another check. An inaccessible item is not a completed request.

Completed fictional record: WR-006; REQ-018 has an accepted receiver and next action; REQ-019 lacks an outcome and stays pending with the coordinator; Operations lead notified; next check agreed. Review completed with one item still open.

## DOC-101: review a change to the instructions

Example revision 1. Owner: Operations lead. Trigger: a reported tool, role or rule change, repeated ambiguity or scheduled review. Prerequisites: the current procedure, change report, performing role and a reviewer/publisher with the required authorization.

Outcome: a review decision is recorded. An accepted revision becomes the current published reference; a failed test returns the draft for correction. A draft is never labeled approved merely because it exists.

1. Record the affected procedure, step, reason and any immediate question about work already in progress. Resolve urgent instruction conflicts through the designated owner.
2. Edit a draft and identify changed steps, relevant screenshots, exceptions and proposed revision. Preserve the current published reference.
3. Have the reviewer test an ordinary request and a relevant missing-information case with fictional data. Record both results.
4. If either test fails, return the draft for correction and record what remains unresolved. If accepted, have the authorized publisher release the revision and verify reader access.
5. Update the manual index after publication. Record the decision about training and the next review trigger. Keep earlier execution records associated with the content they used.

Exception: missing authorization or an unresolved test leaves the draft in review. The owner must decide how readers handle any inaccurate current instruction; do not silently substitute an unapproved draft.

Fictional review record: CR-003; affected procedure OPS-101 revision 1; draft revision 2 adds a required outcome field; ordinary case passed; missing-information case failed; decision returned for correction; revision 1 remains the published reference; no new version declared approved.

## Pilot and maintenance record

Before rollout, ask a teammate who did not write the procedure to find the current instructions, complete an ordinary request, recognize missing information and report a correction. Record the observer, task reference, observations, unresolved items and acceptance decision. Agree your success criteria before testing.

Blank pilot record: observer [role]; procedure/revision [reference]; findability [observation]; ordinary task [result]; exception [result]; unresolved items [owner and next check]; decision [ready / revise]. No pilot has been performed by downloading this file.

Review the index when ownership, links or current versions change. Review procedure accuracy on the chosen cadence and sooner when work changes. Define record retention and access under your organization's requirements.