The fictional Q01 walkthrough advances through E01, A01, F01, V01, and R01 without treating an earlier record as a later one. Q02 routes a broken application toward incident review; Q03 keeps an unlisted-tool request with the responsible owner.
Use the worked example
Select Installed, then inspect the verification gap: F01 alone cannot close Q01. Select Verification and review only for the conditional completed example. Switch to Q02 and Q03 to compare routing questions without sending a ticket or executing any device action.
Keep the decision attached to its evidence
UCSF describes service requests as access to standard services, distinguishes them from restoring broken services, and describes eligibility checks, predefined request models, and fulfillment review. These concepts support the example's routing and evidence stages. UCSF IT: Request Management
Q01 does not assert an outage. Q02 does not become a standard fulfillment request merely because the same application name appears in a catalog. For Q03, absence of a model is not an automatic approval or denial; retain the question for the responsible owner.
Record the catalog item and model revision chosen for Q01, with evidence of applicability. “Standard approved software” describes the fixture's catalog category. It does not establish that this particular requester/device is eligible or that request-specific approval has been obtained.
Q01 initially lacks eligibility evidence E01. Record what the applicable model requires, what evidence is missing, the follow-up question, and the actual assigned owner when known. Its state is awaiting eligibility evidence.
For the next illustrative state, suppose E01 confirms eligibility under the selected model. The model's required approval A01 is still absent, so the request now awaits approval. Do not collapse those two checks into one green status.
WashU's published request process places required approvals before fulfillment. Its specific systems, approvers, and notifications are institution-specific; this example does not adopt them as universal support rules. WashU IT: Service Request Approval Process
For an operational SOP, retain the actual approval requirements and authority from your team's model. Do not invent a supervisor, cost-center approver, license entitlement, or response deadline. An eligibility record can support eligibility without supplying any missing approval.
When fictional A01 is supplied and matches Q01's model and scope, fulfillment tasks can be planned under that authorization. This state does not mean the software was installed.
Keep task records separate from the approval record. They need the request ID, device reference, catalog/model revision, assigned owner when supplied, planned versus performed state, and actual result evidence. Do not substitute “approved” for a completion receipt.
If the request changes device, software scope, or model revision, recheck the applicability of eligibility and approval. The old evidence is history, not an unlimited permission to fulfill a different request. This packet supplies no administrative procedure or permission to bypass controls.
Copy a prompt for this example
Create a complete HTML walkthrough for three fictional IT support requests. Q01 requests standard software on device D01. Its evidence stages are separate: no E01 means eligibility evidence is missing; E01 without A01 means required approval is missing; A01 permits planned work but does not prove installation; F01 without V01 leaves verification pending; illustrative V01 plus R01 supports conditional closure under this supplied model.
Provide buttons for those five Q01 stages. Each button updates the current status and evidence table together. Keep actual requester, verifier and catalog-model revision fields unresolved. The interface explains a fictional workflow; it does not install software or send a ticket.
Q02 is an existing application that fails to launch. Its button should show incident-routing review and a Q02-specific evidence table, with no diagnosis or repair recorded. Q03 is an unlisted-tool request without a supplied model. Its button should show responsible-owner review and the missing catalog model, without retaining Q01 closure evidence. Switching requests must replace the previous request's status and evidence together.
Reset returns to Q01's initial missing-eligibility stage. Put the selected request beside its evidence table so readers can distinguish planned work, reported fulfillment and verification. Use clear stage labels, readable type and keyboard-accessible buttons, then stack the status and table on a phone. Return one complete, self-contained HTML file.
Put your team’s authorized catalog model and evidence references into the maintained SOP before using it operationally. The sanitized HTML walkthrough can be reviewed in NOS through HTML preview. Ask the reviewer which actual record establishes the requested result, then leave closure pending if that record is absent.