A university’s risk portal crashes when duplicate reports are filed, so staff stop submitting altogether. What does this illustrate about reporting mechanisms?
Select an answer to reveal the explanation.
Short Explanation
If the portal eats duplicates and then dies, people learn one lesson: do not bother. Tools that punish reporting kill the culture faster than any memo. Fix usability—or offer a reliable backup—before you lecture about “speaking up.”
Full Explanation
Reporting mechanisms must remain usable; when a university risk portal crashes on duplicate reports and staff stop submitting altogether, broken tools erode reporting culture and hide risk even if leaders intended only to manage duplicates. System crashes do not prove staff are over-reporting and that volume should be capped artificially; they prove unreliable civic infrastructure supporting a core control. Treating duplicate submissions as desirable proof of culture while the tool fails confuses enthusiasm with a functioning control environment. Switching permanently to unsigned paper left on a shared printer tray recreates loss, privacy leakage, and intake failures without acknowledgment to the reporter. Technology that supports risk reporting is itself an operational dependency and should be monitored like other student- and staff-facing service tools. Temporary workarounds during outages must still reach a human owner who acknowledges receipt. Exam caveat: process design for deduplication belongs in workflow logic, not in fragility that punishes reporters. Operational check: restore portal reliability, allow related-ticket linking without hard failure on duplicates, communicate a backup phone or email path during outages, measure submission volumes before and after the crash window, and assign IT and risk co-owners for portal uptime tied to reporting-health metrics.