One of the geeky intersections I have in personal and professional geekery is that of reporting issues. Sometimes this is with an online shop or app or web service. Sometimes it’s with a network provider, or a cell phone service provider. Sometimes I have to report to a professional IT Networking team. Other times I’m on the phone with Comcast about my Internet service. It happens a lot because I’m very observant, very geeky, very thorough, that I both notice an issue and want to fix it. When I report an issue, I’m very aware that there’s a right way and a wrong way to do it.

Now I’m not an absolutist by any stretch of the imagination. I’m very aware of variations in talent, available focus, available time, training, and other factors that can affect the thoroughness and usefulness of a bug or problem report. But I’m here to talk about baselines.

Most folks in technical trouble, who are not geeks or who have never worked in any Quality Assurance (QA or Testing) role and who don’t think about the job of fixing stuff are pretty comfortable just reaching out to their local or topical geek and yelling “It’s broken! Fix it!” Marginally better than this is to specify what’s actually broken (e.g. “My cell phone’s broken!” or even “My cell phone won’t make calls!”). This is the Wrong Way. Because it makes us geeks to a lot of work to pull all the workable information out of you (except that it’s broken, which is pretty obvious since you’re calling a help line – Duh).

But what a professional geek is looking for, baseline, is a lot more thorough. If you pay attention to any technical support call you make, you’ll notice that the tech on the other side guides you through a series of questions before starting with the real troubleshooting. That’s because we professional geeks are looking to frame and characterize the root issue. There are plenty of possible reasons for any conceivable technology failure. For instance, my phone not making calls could be caused by:

• Not having a signal
• Not having paid my bill
• Cell phone was hacked or compromised somehow
• Something inside the cell phone is physically broken
• Cell phone is just off/ran out of battery power
• A problem with the whole cell network
• A problem with a local cell tower
• Some local radio interference
• … and a list of things I can’t myself come up with because I’m not a cell network tech

For each of these possible reasons, there’s a question the tech needs to ask to either focus in on it or discard it as a possibility in this case.

For a baseline, I’m not expecting you to report on all the possible problems and all the possible solutions, because that would be asking you to be a cell network tech. And we can’t all be all the kinds of geek. It’s unreasonable. But I am asking you to provide more information than “It’s broken! Fix it!”

And that information is how it’s broken.

What I mean by that is when you’re reporting an issue, you should be able to articulate who you are, what your relationship is to the system (customer, vendor, tech, etc.), what you expect to happen, and what is happening instead. Often I find that simply doing this indicates the solution and I don’t have to call a tech. Certainly not always, but it does help my own private troubleshooting skills.

In our cell phone example, instead of my reporting “It’s broken! Fix it!” what I would call Verizon with is, “Hi, my name is Malcolm Gin. My phone number is XXX-XXX-XXXX. I’m on the Verizon Network and my signal is showing 3 bars and says I’m connected to the LTE network. I’m trying to make a call to a colleague in Maryland and I’m getting a busy signal but the beeps are coming faster than normal. Here’s her phone number. Can you help me figure out what’s happening?”

The elements I’m including in my issue report are:

• My name and number (so they can look up my account status and verify I’ve paid my bill, possibly look up my address and figure out if there are any known outages for my area).
• My connection status (so they know I’m connected to the Verizon cell network).
• My attempted action (make a call).
• Other relevant data (my colleague is in Maryland, so they can see if there are any known outages in her area).
• My expected results (to get connected).
• My actual experience (fast busy signal).

This is sort of basic information the tech on the other end of the line would wankel out of me with her script, but reporting it all at once means I’m thinking critically about what’s going on. She might ask me to repeat myself, but that’s fair. Techs are so beaten down by the “It’s broken! Fix it!” calls that that’s all they expect these days.

Anyhow, be a good geek citizen and don’t propagate the shitty “It’s broken! Fix it!” calls that we’re all used to. If you’re a geek or a friend-of-geeks, do us all a favor and save us from pulling out our hair.