The Problem with Problem Reporting

The process of reporting abnormal problems is often a problem in and of itself.

For example, my daughter once picked up strep throat, with the disease striking hard just 24 hours after she had surgery. She’d felt better the night after the surgery than she did 24 hours later when the fever hit. I reported the issue to the hospital, which said this wasn’t related to the surgery, so they couldn’t record it as related. Her pediatrician said that the timing was suspicious, prescribed antibiotics for the strep throat, and documented the case in her records. I spoke with the surgeon, who said that she might have picked it up from another child. The hospital said something similar, though we knew of no one with strep at school, church or daycare.

Our pediatrician saw her and agreed with my assessment. After filling the antibiotic prescription and getting my child’s fever down, I called the hospital and surgeon back to notify them of the issue.

Only on the fourth day of calls did I get an admission that it might have been caused by an improperly sterilized breathing tube or something else in surgery; at least two other children who had had surgery that day had developed strep throat after using that ward. While she fully recovered from both the strep throat and eye surgery, the fact that the infection wasn’t a standard post-op surgical infection meant that there was no clear process for reporting or documenting such an unusual problem. Only because I had reported it to everyone I could identify did it get reported, and the correlation get made that the surgery might have been the source of the spread.
Working in IT, I have run into similar problems. When there is a problem traced to several potential causes, where does the ticket go? It may be bounced from queue to queue or the user told to call someone else to get help since it might not be their job to resolve it.
What can your organization do to minimize the problems associated with problem reporting?
• Have multiple methods of reporting problems. The only thing worse than having problems with a software application is finding out that the problem reporting website is down, and the automated phone line only directs people to the website.
• Track your re-routes and misroutes. If more than a few percent of all tickets are not getting properly assigned at the clearing house, the front line staff needs better training, clearer scripts or additional knowledge base articles to cover the previously undocumented issues they misrouted.
• Respond to all misrouted tickets. Never tell a user, “This isn’t our job, call these people instead.” Your staff should either route the ticket to the correct group, or input a ticket into the correct system before closing the ticket they received.
• Follow up on misrouted tickets, to ensure that they weren’t routed to a third group or closed as “not our job, either”.
• Change your process so that suggestions are automatically recorded as enhancement requests instead of deleting suggestions because they are not truly problems.