TWO ORIGINAL FICTIONAL SAAS SOP EXAMPLES
Checked 2026-10-27. Teaching material for fictional InviteDesk.
These examples grant no authority and describe no real service configuration.
Replace tool references, authority, and stop conditions before using operationally.

SOP INV-01 — INVESTIGATE A FAILED INVITATION
Purpose: locate the failure stage and route the permitted next action.
Trigger: a verified requester reports that an expected invitation is unavailable.
Scope: one permitted workspace and invitation. Not a bulk resend workflow.
Owner: Support in the fictional responsibility matrix.

Prerequisites:
- Confirm the requester/workspace relationship through the existing approved support process.
- Obtain only the relevant permitted account, invitation, and provider message references.
- Use read access to the approved eligibility and event views.
- Identify the authorized administrator for any replacement or membership change.
Stop if the relationship, access, or relevant evidence cannot be established.

Steps:
1. Inspect current eligibility and invitation status. If membership already exists, do not create a second membership; route the access question through the authorized process.
2. Inspect the intended-send record. If absent, record the missing stage and escalate to the application owner. Do not assume DNS is the cause.
3. If a provider message exists, inspect its event timeline:
   a. Recipient-server acceptance: inbox placement remains unknown; investigate the legitimate destination and permitted recipient context.
   b. Temporary delivery issue: follow the provider's documented retry behavior; do not create overlapping blind retries.
   c. Permanent bounce or complaint/suppression: preserve the status and follow the applicable suppression policy.
   d. Expired invitation: assess replacement eligibility through the approved administrator workflow.
4. A replacement is a separate authorized action. Before it, check current eligibility, active membership, valid invitation state, and duplicate requests.
5. Do not bypass suppression, change permissions, or invent a new send path to close the ticket.

Verification:
Record what stage was established, what action was authorized and performed, and what result was observed.
An API acceptance is not proof of inbox delivery; a replacement request is not proof that access is complete.
Execution record: support reference / permitted IDs / observations / action owner / outcome / next check.
Escalate missing evidence, conflicting state, or an action outside authority with a concise handoff.

SOP REL-01 — OPEN A BOUNDED INVITATION-EXPIRY PILOT
Purpose: expose a reviewed candidate to an approved small audience with a workable stop path.
Trigger: candidate is reviewed and the accountable owner is considering pilot start.
Scope: the approved candidate, audience, and time interval only.

Prerequisites:
- Candidate version and acceptance evidence are recorded.
- Permission and expiry checks include the defined boundary.
- The disabled path has been exercised.
- Audience and start decision are approved by the accountable owner.
- The operational owner is available and can use the approved configuration mechanism.
Stop if any required evidence or authorization is missing.

Steps:
1. Record candidate, configuration before change, intended audience, decision owner, and support contact.
2. Apply only the approved configuration action.
3. Verify actual assignment for synthetic eligible and excluded accounts; a saved configuration alone does not prove exposure.
4. Inspect the agreed behavior and monitoring evidence during the bounded pilot.
5. Stop exposure on a permission regression or incorrect result. Use the tested disabled path and notify the decision owner through the approved incident route.
6. Inspect accepted jobs, previously issued invitations, and actions already performed. Disabling future exposure does not undo them.
7. Resolve or hand off existing side effects through their authorized recovery process.
8. Record closure: actual exposure, observed failures, recovery, unknowns, and the next owner.

Dry run:
A second operator explains each branch using synthetic evidence before live use.
Record unclear instructions and revise the procedure. These examples have not been executed against a real application.