Practical software guides
A community reporting page should explain what happens after submission. Keep the public status useful while restricting personal details, staff notes and photos that may identify residents.
| Stage | Resident experience | Staff boundary |
|---|---|---|
| Intake | Location, issue and optional approved contact | Collect only information needed to follow up |
| Triage | Reference and next step | Check duplicate/location and responsible service |
| Verification | Status reviewed; correction route | Authorised field observation |
| Action | Assigned or awaiting dependency | Restricted work details |
| Closure | Outcome and how to report an error | Retain evidence under approved policy |
Counter and walk-in variation
A resident can give the report to an authorised desk worker who reads back the details and supplies the same reference. A request missing location information stays in a correction state; it is not silently rejected. Appointment capacity and staff availability remain operational constraints, not problems a portal alone can remove.
Test a duplicate report, abusive upload, wrong location and forwarded status link. Show an accessible alternative when digital intake fails. W3C form guidance supports labels and feedback. This is a software specimen, not a deployed public-authority service or proof of shorter queues.