How to E-Mail a Tech Person & Get a Reply (for Non-Tech)

I’ve been working as an application developer / team leader for quite some time now. During my career I’ve seen thousands of emails from non-tech people asking for support. In most cases replying to these messages is tedious and defies productivity.

Inspired by Tobias’s post about writing emails to busy people, I decided to do a followup. Below is a practical guide to contacting tech people for mere mortals. My goal is to show you how to cut communication overhead, receive a reply and get things done.

This post is about problem description. The presented method  will also help you write better emails in general. It doesn’t matter if your recipient is tech or just “busy”. More often than not describing the problem in detail will lead you to a solution before you click “send”.

Let’s go through seven guidelines while tackling a common “I can’t send emails” problem.

Email Writing Guidelines

1. What is your issue? (Summary)

Start with a 2-3 sentence description of the problem. It doesn’t have to be fancy just write down what you need help with. Be succinct and straightforward. There will be time for details later.

If you have a reoccurring issue it will often be possible to get a reply immediately. Just remember to polish your short summary. An instant answer form IT?

Yes, it is possible as long as you provide a good description and do not fall into an emotional frenzy. You’re not moving ahead by writing “This stupid app is broken!!! Fix it now!!!”. Stay cool … but also be warm.

You also do not have to show off any flashy tech-lingo as you probably aren’t kin to any such dialect anyway. Plain English is enough and above all don’t try to appear tech-savvy. Any IT person will spot this from a mile away and treat it as mockery.

Now on to the problem describing itself.

2. What happened? (Observed)

Simply write “que pasa?”. Be precise though. “Shit not working!!!” is definitely not a detailed description. Just put down what happened, when you did, whatever you did.

It is good to put yourself in the position of the reader. Ask yourself – Would I understand the problem if someone wrote this to me? Look, it works like this … if you’re not precise then even your best tech friend will be stuck with wild guesses. So instead of watching cats on Facebook you will have to dig up the problem, bother your mind again, etc.. Why not do it right the first time?

Next we contrast reality with expectations.

3. What you wanted? (Expected)

For some people it may be an ugly bug and for others a cuddly teddy. If you want to communicate an error you must state your expectations. This is also good life advice, so pause — and give yourself a minute to think it over. Thank me later.

Your prediction of the result may be the problem in the first place. This can happen for example with new UI elements or girls that don’t dig your new sports car. Other times you may be sure of the expected result, but it is still important to include a description. It will be easier for the person you are requesting help from to quickly catch on the problem.

In this case this is obvious, so it can be omitted. But we have to explain “how?”, so let’s move on.

4. How it happened?  (How to reproduce?)

What did you do to end up in this unfortunate position? Whatever happened might have been an uncommon edge case. Reproducing it might be harder than solving the issue itself. Don’t make it difficult for the person who wants to help. Get things done stupid! Adding a short report of the steps you took costs you next to nothing.

Yet do not resort to memory alone. Write down the steps you remember and verify them. This is important. Reproduce the error yourself to check if you are sure what you did to cause the problem. If you are able to remove unnecessary steps then give yourself a pad on the back. Your tech friends will love you for this.

Of course you tried to fix it yourself. Haven’t you?

5. What did you try? (Tried)

The first rule of fight club … I mean self-help is to look for the answer yourself. If it takes you 5 min. to google it up than why bother other people? In fact why bother yourself with writing an email? You will have to wait for it, reply … when you can get the problem off your TO-DO in five.

If you tried a decent search and nothing comes up then try to solve the problem yourself. Shocking right? Well this will probably not take you long, but can pump up your self reliance. Often you’ll also be spared the embarrassment of forgetting to turn on your WiFi.

We must not forget to pass on all the information involved in the case. More on that below.

6. Important information (Data)

If you have problems with software it is crucial that you provide details about the version. The software may be outdated. You can save the IT people yourself for that matter a lot of hassle if you make sure you’re up to date. The nerds might have fixed your problem already!

When it comes to submitting the software version you should provide the whole picture. For example for a webpage problem it should be: the URL, browser version and OS version. You can usually find the information in the “About” section of the main menu of your program. Providing the version numbers will allow the tech guys to quickly reproduce the error. Don’t make there life harder than it is.

If possible include a screenshot of the error. It is probable that you’ll miss important details in your description and a good image can help a lot. If you want to highlight some part of the image it is a good idea to also include a raw version without your doodles. You don’t want to end up covering an important part by accident.

One last awesome guideline and we’re wrapping up …

7. Write a good subject line

I left this for last, killing two birds with one stone. As it often happens it is easier to write a one sentence summary of everything you wanted to say at the end. Yes, that one liner will probably make a good subject line. If you’re working on a specific project then it is also good to include a project label. It can be [WRLD DMNTN], if that’s what you’re working on. DO NOT use labels like [ASAP], [PRIORITY] or [!!!!!!!!!!!!]. Not knowing how to set your wallpaper doesn’t threaten the existence of life on earth. It can wait, trust me. Focus more on productivity and make it easier for others to.

Ladies and Gents …

The Wrap Up

Remember that your goal is getting things done and not chatting with someone. If your intentions are different try proposing him/her coffee. If you want to know some extra tips on how to take them out for lunch, well … that’s beyond the scope of this post 😉

Writing in points (following Tobias’s suggestion) also helps. Let them know you mean business!