An issue queue shows the same address defect opened twelve times by different teams. What should structured DQ issue management emphasize?
Select an answer to reveal the explanation.
Short Explanation
Twelve tickets for one bad address is like twelve work orders for the same pothole—noise without progress. Good issue management collapses duplicates and tracks the real defect once. Coordination beats ticket spam.
Full Explanation
Structured DQ issue management emphasizes deduplicating related tickets for the same underlying defect and coordinating one remediation path across teams. When an issue queue shows the same address defect opened twelve times by different municipal teams, the program should consolidate those sightings under a master issue rather than treating each as an independent root cause. Opening a new ticket for every sighting without duplicate checks floods queues, fragments root-cause analysis, and burns steward time. Closing all tickets automatically after 24 hours regardless of fix status invents false throughput and leaves residents stuck with bad addresses in notices and routing. Assigning severity only by which team shouts loudest in chat replaces risk-based triage with politics and undermines consistent civic service levels. Exam caveat: duplicate sightings remain useful as impact evidence—retain links or occurrence counts under the master issue rather than deleting the history. Operational check: match new tickets on address key and defect type, merge into a master issue with a single owner and SLA, and notify originating teams when the system of record is fixed. Civic 311 and permitting stewards should share one address-defect queue taxonomy so cross-department duplicates collapse automatically and council reports show true unique defect volume.