By EmailBetter · · 7 min read

Professional writing

How to Report a Technical Problem by Email

Explain a technical problem clearly in an email. Separate observed and expected results, state what you tried, and practise writing an accurate support request.

Report a technical problem by email with a clear description of the affected task, what you did, and what happened. Explain the result you expected, include relevant error text, and ask for the help you need. You can write a useful report without knowing the cause.

“The system is broken” gives a support colleague little to investigate. It can also overstate the situation when one function fails but other parts still work. A more useful opening names the specific difficulty: “I couldn’t export the schedule as a CSV file.”

This is a writing lesson for workplace software problems, not a troubleshooting procedure. The examples and exercise describe fictional events.

Name the affected task in the subject and opening

Use the subject to identify the problem, rather than announcing only that you need help.

Help needed

Schedule CSV export fails for 9–15 November

The second subject gives the reader a task and a date range. It does not claim that the whole scheduling tool is unavailable or propose an unverified fix.

In the opening, state the problem before the longer explanation. The British Council’s guidance on explaining a problem by email recommends presenting the problem first, adding important details and explaining the desired next step. Its lesson uses a different situation, but that organization also works for a support request.

Separate your actions, expected result and actual result

Imagine the reader trying to understand the event without seeing your screen. Give them three kinds of information:

  • Actions: what you actually selected, entered or opened.
  • Expected result: what you intended the tool to do.
  • Actual result: what appeared or failed to happen.

Mozilla’s bug-writing guidance distinguishes expected and actual results and asks writers to separate observations from speculation. These reporting principles are useful in an email even when the recipient does not use Mozilla’s bug tracker.

For example, “I selected Export CSV” describes an action. “I expected a file to download” explains the expected result. “The page displayed ‘Export unavailable’ and no file downloaded” describes the observation.

Include exact error wording when it is relevant. Replacing a specific message with “something went wrong” removes information the recipient might need. In a real report, check that any copied text or screenshot is appropriate to share with that recipient.

For several actions, a short numbered list can make the sequence clear. Write what you did in the past tense: “I opened the Schedule page,” not a guessed set of instructions that you have not tried.

Be precise about frequency and scope

“It failed on both of my attempts” is different from “It always fails.” Two attempts tell the reader about two attempts, not every user or every future attempt.

The same distinction applies to scope:

I can still view the schedule. I haven’t checked whether anyone else has the export problem.

That statement preserves both a useful observation and a limit. It does not claim that only your account is affected.

Mention relevant checks you actually made. Do not add a restart, browser test or colleague’s experience simply because it would make the report look more complete. If you have a theory, separate it from the facts: “I don’t know whether this is related to the recent change.” Include that theory only when there is a real basis for mentioning it.

Explain the work affected and request a next step

Connect the problem to a concrete task. “I need the export to prepare the staffing worksheet” is more informative than an unsupported claim that nobody can work.

Then specify the help you want: investigation, advice on obtaining the file, or clarification of the expected behavior. Avoid demanding a particular technical fix when the cause is unknown.

If the issue needs a management decision rather than technical investigation, use the guide to asking your manager for help. Different recipients may need different details from the same incident.

Practice: report a failed schedule export

You are Lina. You use a fictional internal scheduling tool and need a CSV file for a staffing worksheet. A CSV file contains table data that can be opened in a spreadsheet.

Use only these supplied facts:

  • On 6 November, you used Chrome on Windows to open the tool’s Schedule page.
  • You selected the date range 9–15 November and clicked Export CSV. The expected behavior was a download containing the selected schedule.
  • You tried at 10:10 a.m. Paris time and repeated the same actions at 10:15 a.m. Paris time.
  • Both attempts displayed “Export unavailable. Try again later.” No file downloaded on either attempt.
  • You could still view the schedule. You had not tested another browser or asked whether other users were affected.
  • You needed the export for the staffing worksheet. You wanted the support team to investigate or advise how to obtain the file.
  • No cause, workaround or resolution was known. No screenshot had been prepared for this exercise.

Write an email to the support team before reading the model. Replace “The whole system is broken” with an account supported by these facts. Include a subject and a specific request.

Here is one possible answer:

Subject: Schedule CSV export fails for 9–15 November

Hi Support team,

I couldn’t export the 9–15 November schedule as a CSV file. I need it to prepare our staffing worksheet.

On 6 November, using Chrome on Windows, I:

  1. Opened the Schedule page.
  2. Selected 9–15 November.
  3. Clicked Export CSV.

I expected the selected schedule to download. At 10:10 a.m. Paris time, the page displayed “Export unavailable. Try again later.” and no file downloaded. I repeated the same actions at 10:15 a.m. and got the same result.

I can still view the schedule. I haven’t tried another browser or checked whether other users are affected, and I don’t know the cause.

Could you investigate the export problem or advise how I can obtain the file?

Thanks, Lina

The model keeps the actions separate from their result. It preserves the exact error, identifies both attempts and explains why the file matters. “I can still view the schedule” prevents the report from implying that every function is unavailable.

Check your version for an invented detail. Did you claim the server is down, say that colleagues have the same problem, attach an imaginary screenshot, or promise a deadline that was not supplied? Remove those claims or replace them with what the facts establish.

Revise the report when a retry succeeds

Now change one fact: the 10:15 a.m. attempt downloaded the expected CSV successfully. The earlier failure is still part of the record, but you now have the file needed for the worksheet.

Rewrite the subject, result paragraph and request before reading this example:

Subject: Schedule CSV export failed once, then succeeded on retry

At 10:10 a.m. Paris time on 6 November, the page displayed “Export unavailable. Try again later.” and no file downloaded. I repeated the same actions at 10:15 a.m., and the expected CSV downloaded successfully.

I now have the file for the staffing worksheet. I’m reporting the earlier failure in case it helps your investigation. Please let me know if you need more information about that attempt.

These are replacement sections, not a complete second email. Update the original opening too: “The 9–15 November schedule export failed on my first attempt and succeeded on the second.” Retain the relevant tool, browser and action details, but remove the obsolete request to obtain the file.

Do not describe this as proof of a permanent fix. The revised report says what changed in your experience without claiming to know why it changed.

Before sending, check that the subject, opening, evidence and requested next step all describe the same current situation. If support asks a question you do not understand, the clarification-email guide can help you ask for an explanation. For more write-first tasks, try the professional email writing exercises.

To build your own wording through practice, start practicing for free. EmailBetter sends workplace scenarios tailored to your profile to your inbox. You write your reply in your usual email app, then review AI feedback in your dashboard.

Frequently asked questions

What should I include in an email about a technical problem? +

Identify the tool and affected task, the actions you took, the expected result and the actual result. Include relevant error text, the attempts you made, the work affected and a specific request for help. State any important limits on what you have checked.

How do I report a problem when I do not know the cause? +

Describe the behavior you observed without assigning a cause. If you mention a possible explanation, label it as a possibility. You can ask support to investigate while giving a useful account of your actions and results.

Should I mention that a retry worked? +

Yes. Say which attempt failed and which succeeded, and update any request for a file you now have. A successful retry changes the current situation, but it does not establish why the first attempt failed or prove that the problem is permanently fixed.

Practice this kind of email in your own inbox

EmailBetter sends you a workplace scenario. Reply from your usual email app and get AI feedback on your wording, with a suggested rewrite you can learn from. Start practicing for free.

Start practicing free →

See how EmailBetter works.