Sense with Cents

Imagine two emails arriving the same morning.

The first, paraphrased, says: “Medlin isn’t working. Please help.”

The second says something like: “I moved Medlin Payroll to a new Windows 11 computer yesterday. My old computer still runs it fine. When I try to print a check on the new machine, I get an error that reads [exact text]. I’m attaching a screenshot. Nothing in the program or the payroll data has changed — the problem started the moment I moved to the new computer. I’m signed in as a local administrator.”

The second email gets a solution in the first reply, within seconds of being read. The first email turns into a week of back-and-forth — not because anyone is punishing the sender, but because every round-trip email costs time. The helper has to ask what “not working” means. The sender has to answer. The helper asks what changed. The sender answers. Each exchange is another day lost before the actual problem can even be looked at.

I am writing this because I get a lot of first emails. Not to chastise anyone — I do not want anyone to feel embarrassed about how they asked for help. I just want to get to the answer faster, and so do you. A few minutes spent on the front end of your next support email will save both of us days on the back end.

For context: I have been answering support email for a very long time — probably as long as anyone you can reach directly at any software company still in business. Let me be candid. The odd ones get my attention, because they are fun in a nerdy way — a genuinely new problem is its own small reward. The repeated standard questions do not bother me either. They are how you learn what the software needs to do better. Neither category is a burden. Write in.

This is not about being clever, or technical, or writing well. It is about respecting your own time. A good help email gets you a better answer, faster. A vague one delays the fix — because the person on the other end has no choice but to start with the basics.

Why email, not phone

Every question so far assumes you are writing an email. That is on purpose. Medlin support is email only — and that is for your benefit, not ours.

What the support person writes goes on paper, so to speak. You can save it, re-read it, and refer back to it a week later when you need to do the same thing again. On a phone call, you hear it once. It is tough to miss a step when every step is written down. It is much easier to miss one when someone is reciting it in real time. Both sides also see exactly what was said, which cuts down dramatically on misunderstandings. What you read is what I wrote.

Email keeps the queue fair. Whoever sent their question first gets answered first. Nobody can jump the line by calling — which is how it should work, because the customer whose question came in at 2 AM deserves the same shot at a fast answer as the one who is up at 9. Phone support rewards the loudest and the most available, not the ones who took the time to ask a good question.

There is one exception to the queue. If someone sends a string of one-line messages without waiting for a reply, those often get bumped to the bottom so we can read them all together and answer once. This ties back to taking a few moments to think before sending — a single thoughtful message beats a burst of fragments, and it gets you a faster answer in the end. A well-written, relatively complete message may even get a reply outside normal hours.

Email also carries things a phone call cannot. Screenshots. Error text you can copy and paste. A short screen recording. Attached reports. These are exactly the artifacts that make a problem solvable — and none of them travel over a phone line. Email can also carry clear references: a link to the documentation page, a pointer to the specific rule in IRS Publication 15-T, a line from the law text. You can read those on your own and verify what I told you. That is how trust works. I say the thing. You can check the thing. On the phone, you have to take my word for it.

There is also a more specific reason. In good software, the simple issues have already been prevented or answered with an on-screen message. The issues that actually need human help are, by definition, the ones that are left after the easy ones are solved. Those are not the kind of problems anyone should try to walk through by voice. They usually involve exact wording, specific steps, attachments, or details you will want to have written down. A phone call is the wrong tool for that conversation.

Try the search first

Before you write, consider our website search. Type your question in plain language — the same way you would say it out loud — and see what comes back. A fair number of the emails we get are answered directly in our documentation, and our first reply is often a link to the page that covers it.

That link-reply is not a brush-off. The documentation has an answer we have written with thought, usually refined over several years of customer questions and clarifications. It is likely a better-tested answer than what I would type to you in a fresh email this morning. Nobody at Medlin thinks less of you for asking a question the docs already cover. Most of our customers have a business to run, and reading documentation is rarely at the top of that list. The link is the answer, plus a pointer to where to look the next time something similar comes up.

If the search does not turn up what you need, or the docs cover a close cousin of your question but not the exact thing, then write the email. That is exactly what support is for.

What the first email was missing

Every question I would have asked in reply to the first email, that customer already had the answer to. They just did not put it in the message. What is not working? When did it stop working? Did anything change? What exact text do you see on the screen? The second email answered all of it up front, because that customer had already thought the problem through before they wrote.

Thinking the problem through before you write is not for my benefit. It is for yours. Half the time, the act of writing down what is actually happening — in enough detail to send to someone else — solves the problem before you hit send. I cannot count the number of times I have started drafting a support email to a vendor, gotten to the “what I tried” section, and realized what I had missed. Writing it out forces the diagnosis.

Sometimes the assumption goes further. I occasionally get messages written as if I am already sitting at the sender’s computer — as if I can see what they are seeing, or can pull up some activity log from their machine. I cannot, and that is deliberate. Medlin does not log into customer computers, and Medlin Payroll does not send customer activity reports back to us. We consider both to be security and privacy issues, and we do not want to be the ones to create either. All we have is the email in front of us. Everything we need to help, you need to put in that email.

The shape of a good help email

You do not need a template. You need four things.

What you were trying to do. Not the error message — the task. Print a paycheck. Efile a W-2 batch. Install the program on a new computer. Start with the goal, not the symptom.

What actually happened. The exact error text, word for word. A screenshot is worth ten paragraphs. If there is no error and something is just wrong, describe what you expected and what you got instead. For Medlin users specifically: our error and warning messages are deliberately explicit, and most are used in only one place in the program. Copy the message verbatim and we can usually pinpoint the issue before asking another question.

What changed recently. New computer. Windows update. New printer. Switched internet providers. Moved the data folder. Almost every “it suddenly stopped working” has a “what changed” behind it, and the person writing almost always knows the answer.

What you already tried. This one saves the most back-and-forth. If you rebooted, say so. If you ran the program as administrator, say so. If you reinstalled, say so. Otherwise the first reply will be a list of things to try — and half of them will be things you already did.

That is it. Four items. A good help email is often five or six sentences.

Attach, do not describe

If there is an error message, a screenshot is better than your summary of it. If there is a report that prints wrong, attach the PDF. If the program is behaving oddly, a short screen recording beats a paragraph. You are the one who can see what is happening. The person on the other end cannot. Show them.

One caveat: do not send payroll data that contains real names, Social Security numbers, or amounts you do not want a stranger to see unless you have been specifically asked for it — and even then, only after you understand what the data will be used for and when it will be deleted. If the answer to either of those is vague, do not send it. Blur or black out anything sensitive in a screenshot before you send it. Most support problems can be diagnosed without ever touching real data.

What not to send

“It is not working” is not a help email. Neither is “it is broken.” Neither is “help!” These are not descriptions of a problem — they are descriptions of how you feel about the problem. The person on the other end has nothing to work with.

The same goes for “something is wrong with the program.” Probably. What program? What were you doing? What did you see? Until those questions have answers in the email, no real help can begin.

Everyone has sent a bad help email. I have sent plenty of them myself, usually when I was frustrated or in a hurry — which is the worst possible time to write for help, and the most common time people actually do. Take the extra two minutes. You will get the answer faster than you would have by sending the short version. (There is no such thing as a payroll crisis, so there is no need to write as if there is one.)

One more reason to ask a direct question: when you write to Medlin, you are not just getting the experience of the people who built the software. You are getting the experience of every customer who has ever used it. It is rare to ask a question that someone else has not already asked. As of this writing, we still have customers who first ordered in 1986 — so “every customer who has ever used it” covers a fair amount of ground. Medlin experts have the answer waiting — provided you ask a direct question. And sometimes we can help with very little information at all, because the issue is familiar. The easy ones we have already either prevented in the software or answered with a very literal on-screen message pointing you at the solution.

When we start to see a pattern — even as few as two customers asking the same thing — we ask ourselves whether we can stop anyone from ever having to ask it again. That is how the software gets better. And if you do run across something we cannot answer right away, we will absolutely tell you, and we will be working to get you an answer or solution as soon as possible.

None of this means there are no issues that need a human to work through. There are. Most of those, though, are not caused by Medlin or controlled by anything inside Medlin. The old-school approach at many software shops is to reply with a polite version of “not our problem.” We do not work that way. Even when the issue is not ours, we try to help where we can. Two common examples: a wayward app sets your printer for multiple copies, and then you write to ask why Medlin is printing two copies of every paycheck. Medlin is not — your printer is. Medlin is honoring the printer setting the way any well-behaved program should. The other one, the bane of every support desk on earth, is when an overzealous “security” app flags Medlin as dangerous. In some cases the security app blocks Medlin from even opening, and we get a support email that reads “why did my Medlin app disappear?” It did not. It is still installed, right where it was. Something else on the computer quarantined it.

A related touchy topic: feature suggestions. We welcome them, and always have. A lot of what is good about Medlin started as an email from a customer. But after this many years in business, we are genuinely happy with what we offer — and so are our customers — so we work hard to keep the software from drifting into feature creep. That means some suggestions get a thoughtful “no.” It is not because the idea was bad. It is because the answer to “should we build everything anyone ever asks for?” is also “no” — and we would rather keep Medlin tight and fast and focused than turn it into something no one person can hold in their head anymore. If your suggestion does not make it in, please know it was actually considered.

One honest example, because it is easier to show than tell. A couple of decades ago, a customer suggested we add a way to record tax deposits — back when deposits were typically made by check or in person at a bank. It seemed like a great idea at the time, and we built it. The feature is still in the software today, and a few long-time customers still use it. But it no longer serves a real purpose. Every online deposit portal can produce reports of your actual deposits, without you having to type them into Medlin (hopefully accurately). The feature is a small monument to good intentions. It is also a reminder that every “yes” has a long tail, and that the job of saying “no” to a new suggestion is not about the suggestion — it is about the weight the software already carries.

Help me help you. Better yet: help you help yourself. A good help email does both.

See also: Learning or Declining, The Cost of “If It Ain’t Broke”, and Why We Hung Up the Phone.