# Software project brief: service request queue

FICTIONAL COMPLETED EXAMPLE
This is a teaching example, not a client project or evidence of business results.
Companion: https://blutekmedia.com/insights/software-project-brief-worksheet

1. Who is doing the work?
Service coordinator: assign each incoming request to one named owner.

2. What happens today?
Assumption: email handoffs leave ownership unclear. Before estimating impact,
inspect a permitted sample of requests and ask coordinators where ownership
becomes uncertain. There is no measured baseline in this fictional example.

3. What must the first release do?
Create a request, assign one owner, update status, and find unresolved work.
Exclude demand forecasting, a public portal, and automatic AI assignment.

4. Which data and integrations are needed?
Request identifier, customer reference, status, owner, and change history.
Open question: which existing system is the authoritative source?
Use synthetic records until a data owner authorizes development access.

5. Who may see and change each record?
Proposed: coordinators manage requests within their assigned team.
Assigned staff update their own eligible work. Export permissions are separate.
Open question: do contractors need a narrower record scope?

6. What happens when something fails?
If two people assign the same request, detect the changed version and refresh.
If a source system is unavailable, preserve existing work and explain the failure.
Define a manual reassignment path when the owner is absent.

7. What will show that it works?
Test assignment, closure history, unauthorized access, and conflicting updates.
Collect a baseline for unassigned requests before claiming improvement.
Agree the observation period and acceptance criteria with the workflow owner.

8. Who owns the next decision?
Workflow owner: to be confirmed. Data owner: to be confirmed.
Next decision: establish the system of record and permitted development data.
Review date: set with those owners, not assumed by the development team.