From scattered requests to a reviewable operating system.
A fictional community program receives requests by email and informal messages. Its coordinator cannot reliably see what is waiting, who owns a decision, or what a successor needs to continue the work. This sample follows one problem from initial diagnosis through requirements, procedures, and handoff, so a reader can evaluate the reasoning without a guided walkthrough.
Scope and provenance. This is a portfolio demonstration created to explain an approach. The organization, request volumes, time estimates, and operational conditions below are invented for the exercise. They are not Angel’s client results, university records, research findings, or evidence of a completed implementation. Recommendations remain proposals; no improvement is claimed.
01 / Decision brief
Decision to support: Should the program first standardize its process in a shared tracker, or invest immediately in a dedicated portal? The recommended starting point is a small, controlled tracker pilot. It tests the information structure and ownership rules before the organization commits to software that could automate an unclear process.
Boundaries: This example covers intake, completeness review, ownership, decision tracking, and closure. It does not design payments, safeguarding, eligibility policy, sensitive case management, or integrations. Those areas would require separate discovery and specialist review. Success would mean a traceable request, an identifiable next owner, and a handoff another coordinator can use.
Discovery questions: What qualifies as a request? Who may approve one? Which fields are necessary for a decision? When does the response clock start or pause? Who may view attachments? These questions must be answered with the actual team before treating this structure as an approved procedure.
02 / Analysis dashboard and interpretation
The simulated four-week ledger starts with zero open requests. It contains 84 arrivals and 60 closures, leaving 24 open at the end of the period. These counts describe queue movement only: they do not establish service quality, individual productivity, or the reasons a request remains open.
Incoming work exceeds closures in every week
Simulated requests · same weekly scale · received / closed
Week 1
18 received12 closed
Week 2
24 received16 closed
Week 3
20 received18 closed
Week 4
22 received14 closed
84 received − 60 closed = 24 still open. The persistent imbalance suggests a need to inspect waiting states and capacity. It does not prove the team is understaffed.
The open queue accumulates over time
Closing balance = opening balance + received − closed. Week 3 adds only two requests, but the backlog still grows. A lower arrival rate alone does not clear existing work.
A hypothetical touch-time breakdown
Capture & clarification
12 min
Review preparation
8 min
Decision recording
6 min
Closure & handoff
4 min
Assumed active handling time totals 30 minutes per request. Capture and clarification account for 40%. These estimates identify what to measure during discovery; they are not observed time savings or a staffing forecast.
What to measure before recommending automation
Collect received, complete, assigned, decision, and closed dates for a limited pilot. Separate elapsed days from active handling minutes. A request can take five days to close while requiring only thirty minutes of work.
Review a small set of records with the coordinator to validate stage definitions. Check for missing dates and reopened requests before calculating medians. Report incomplete records alongside any metric so missing information does not create a misleading improvement.
Decision rule: Investigate the largest verified delay first. If clarification dominates, improve intake. If complete requests wait for approval, clarify decision ownership and review cadence before adding more form fields.
Each gap below connects an observable condition in the fictional brief to a proposed control, an owner, and a test. Priority reflects whether the issue prevents a request from progressing or merely reduces visibility. The ranking is qualitative; it is not a validated risk score or a claim about an actual organization.
Sample gap register · all conditions hypothetical
Gap
Why it matters
Proposed control
Priority rationale
Accountable role
Trace
G01 · Incomplete requests
Required information arrives through several channels, so reviewers must ask follow-up questions before work can start.
Standardize the intake fields and add a completeness check.
High · blocks review
Coordinator
FR01 / AC01
G02 · Unclear ownership
A request can sit between teams because no one is explicitly accountable for its next decision.
Assign one accountable owner and record the next action at triage.
High · creates unowned work
Process owner
FR02 / AC02
G03 · Hidden waiting time
A single open/closed label cannot distinguish active work from waiting for information or approval.
Record stage changes, dates, and a reason when a request is waiting.
Medium · limits diagnosis
Coordinator
FR03 / AC03
G04 · Inconsistent handoff
A closed request may lack a decision explanation or reusable record for the next coordinator.
Use a closure checklist and retain the decision and supporting links.
Medium · weakens continuity
Process owner
FR04 / AC04
Tradeoff: Requiring every optional detail at submission could reduce incomplete records but make the form harder to use. Start with fields needed for triage, explain why each is requested, and allow the coordinator to seek additional details after the initial review.
04 / Business requirements and acceptance checks
The business need explains why the organization cares. The functional requirement describes what the process or tool must do. The acceptance check makes that requirement reviewable. The same rules can be tested in a spreadsheet pilot or a portal; choosing software does not replace defining the expected behavior.
BR01 → FR01
A reviewer needs a complete request before deciding.
Required behavior: Capture purpose, requester contact, requested date, and a description. Mark missing information for follow-up.
Acceptance check: Submit a request with the description missing. It must be flagged incomplete and excluded from the ready-for-review queue.
Trace: AC01 · Proposed for review, not an executed test result.
BR02 → FR02
Every accepted request needs a decision owner.
Required behavior: Assign exactly one accountable owner before moving a request to review; retain the assignment history.
Acceptance check: Attempt to move an unassigned request into review. The transition must be prevented with an explanation of the missing owner.
Trace: AC02 · Proposed for review, not an executed test result.
BR03 → FR03
The team needs to distinguish work time from waiting.
Required behavior: Record the date of each stage transition and a reason for waiting. Preserve prior events rather than overwriting them.
Acceptance check: Move a test request from review to waiting and back. Both transitions, their dates, and the waiting reason must remain visible.
Trace: AC03 · Proposed for review, not an executed test result.
BR04 → FR04
The next coordinator must understand why a request closed.
Required behavior: Require a closure category, decision explanation, and evidence link or an explicit no-attachment reason.
Acceptance check: Attempt closure without a decision explanation. Closure must fail; a complete example must save successfully.
Trace: AC04 · Proposed for review, not an executed test result.
Additional operating constraints: Use stable request IDs, define access by role, retain an auditable change history, and agree a retention period before handling live information. Test keyboard access and clear validation messages. No retention period or access policy is assumed to be approved in this demonstration.
05 / Worked SOP: intake to closure
Document control: SOP-DEMO-01 · Version 0.1 · Draft demonstration · Process owner: proposed program lead · Review trigger: policy change, recurring exception, or pilot review. The coordinator performs the routine steps; the process owner resolves scope and approval questions. A requester supplies information but does not approve their own request.
Register and acknowledge
Create a stable request ID and record the received date, contact, purpose, and requested timing. Acknowledge receipt without promising approval. Search for an existing record before creating a duplicate. Output: a traceable intake record.
Check completeness and scope
Compare the record with the required-field checklist. If information is missing, identify the exact gap, ask for clarification, and mark the record Waiting for requester. If scope is unclear, route it to the process owner. Do not silently reject or advance an incomplete request.
Assign and prepare review
Record one accountable decision owner and the next action. The coordinator assembles the relevant information and flags unresolved questions. Move to Ready for review only when completeness and ownership checks pass. Output: a reviewable record with a named next owner.
Record the decision
The authorized owner records approve, decline, or request clarification, together with a short rationale. If a conflict of interest exists, refer the decision to the agreed alternate. The coordinator communicates the decision through the approved channel and records when it was communicated.
Close and hand over
Verify that the decision, communication, supporting reference, and closure category are present. Record the closed date. If follow-up work remains, assign it explicitly instead of hiding it in a closed record. A successor should be able to identify the decision and outstanding obligations from the record alone.
Exception handling and quality gate
Duplicate: link to the original and retain enough context to explain the merge. Urgent: use an agreed escalation route; urgency must not silently bypass approval. Owner unavailable: route to an authorized alternate. Reopened: retain the original closure event and add a new status event.
Before closure, check: unique ID; complete decision; authorized owner; communication recorded; evidence link or documented exception; no unassigned next action. A missing item returns the record to the appropriate stage. This checklist is a proposed control, not a certification of compliance.
06 / Pilot, implementation decisions, and handoff
1 · Validate
Walk through the proposed stages with the coordinator and decision owner. Resolve scope, access, and exception rules. Exit evidence: an agreed process map and definitions.
2 · Configure
Set up a restricted demonstration tracker with required fields and stage rules. Use dummy records for the acceptance checks. Exit evidence: test notes, unresolved issues, and an owner for each issue.
3 · Pilot
Run a limited, approved pilot and review missing fields, waiting reasons, and workload. Agree the pilot duration and response expectations with the team rather than inventing a service target.
4 · Review & hand over
Compare the pilot with its documented starting conditions. Decide whether to revise, continue, or investigate a portal. Provide the SOP, field dictionary, issue log, access owner, and change process.
Decision log example
D01 — Start with a shared tracker. Rationale: the process rules need validation before automation. Alternative: build a portal immediately. Tradeoff: the tracker may require manual checks and should not be treated as a permanent solution for complex or sensitive information. Revisit when the pilot demonstrates stable rules, adequate access controls, and a clear limitation the portal would solve.
What the recipient receives
The handoff package contains the brief, assumptions, gap register, requirements and acceptance checks, workflow map, responsibility matrix, SOP, field dictionary, pilot plan, and open decision log. A handoff walkthrough should ask the successor to process a dummy request, identify its next owner, and explain an exception without relying on the original author.
Limitations and next questions: No interviews, live observations, access review, or pilot were conducted for this fictional example. Actual request complexity, staffing availability, policy constraints, and accessibility needs could change the recommendation. The deliverable demonstrates a structured method and makes its assumptions available for challenge.
07 / Tracker field dictionary and open issues
This sample dictionary gives the tracker a shared vocabulary. Dates should use one agreed time zone and format. Keep optional narrative separate from controlled stage values so reporting does not depend on interpreting free text.
Proposed minimum tracker fields
Field
Definition and rule
Example using dummy data
Request ID
Unique, stable identifier; never reuse after closure.
DEMO-001
Received date
When the request first reaches the team; retain the original date after clarification.
Pilot day 1
Purpose and contact
Decision context and an approved way to contact the requester; use dummy information in testing.
Room setup request / dummy requester
Stage
Controlled values: Received, Waiting for requester, Ready for review, In review, Decision recorded, Closed.
Waiting for requester
Accountable owner
One role authorized to make the next decision; required before review.
Program lead
Next action and waiting reason
Concrete action, responsible role, and the information or decision being awaited.
Coordinator requests event date
Stage event date
Append an event for every transition; do not erase previous transitions.
Pilot day 2: Received → Waiting
Decision and closure
Decision category, rationale, communication date, closed date, and supporting reference or exception.
Pending; closure fields not yet complete
Open issue log
O01 — Approval authority: the program lead must confirm who can approve which requests before a pilot starts. O02 — Access and retention: the information owner must determine who may view records and when records are removed. O03 — Response expectations: the coordinator and lead must agree when the clock starts, pauses, and resumes. These remain unresolved decisions, not implemented policies.
Sample handoff acceptance exercise
Give the successor dummy record DEMO-001 with a missing event date. Ask them to identify the correct stage, draft the clarification request, find the accountable owner, and explain why it cannot advance to review. Then supply the missing information and ask them to record the stage change. Record any ambiguity in the issue log and revise the SOP before considering the handoff accepted.
Illustrative demonstrations. Created for this portfolio to show document structures and operational thinking. These are not completed client deliverables or internal university materials.
Request intake workflow
See who owns each step and where the handoffs happen.
