5 exercises — identifying email parts (subject · context · CTA · closing), writing effective subject lines, and choosing the right professional tone.
Professional email anatomy
Subject: one-line summary — status keyword + topic + date/deadline if relevant
Greeting: "Hi [Name]," (informal) — "Dear [Name]," (formal) — never skip it
Context: What happened? Which system? Since when? Who is affected?
Call to Action: specific ask + who needs to do it + deadline
Closing: "Thanks," / "Best," / "Regards," — one word is enough
0 / 18 completed
1 / 18
A colleague sends you this email:
"Hi, I was wondering if maybe we could potentially fix the bug that's been causing some issues with the login flow at some point before the next release if it's not too much trouble?"
Which part of a professional email is most broken here?
The main problem is the call to action — the actual request is buried in uncertainty ("wondering if maybe", "potentially", "some issues", "at some point", "if it's not too much trouble"). A professional email CTA should be: specific (what needs to happen), scoped (which bug), and time-bound (by when). Better: "Could you prioritise the login-flow bug before the v2.4 release on Friday?" The five parts of a professional email: Subject · Greeting · Context/Body · Call to Action · Closing.
2 / 18
You need to email the team that the production deployment is delayed until tomorrow. Which subject line is most effective?
"DELAYED: Production deployment — rescheduled to 2026-03-17 09:00 UTC" — A good subject line should be a one-line summary that lets the reader decide urgency without opening the email. Best practices for IT email subjects: ① Start with a status keyword if relevant: DELAYED / ACTION REQUIRED / FYI / RESOLVED / REMINDER. ② Name the system or project. ③ Add a time or date if actionable. Option A is too vague. Option B assumes the reader knows the context. Option D is a full sentence — subject lines should be fragments, not sentences.
3 / 18
Read this email and identify which labelled section is the Context (background) rather than the Call to Action.
"[A] Hi Sam, [B] The staging environment has been returning 503 errors since the overnight deployment at 02:00 UTC. [C] Could you roll back the deployment and confirm once staging is stable? [D] Thanks, Alex"
Section B is the Context: it states what happened (503 errors), which system (staging environment), and since when (since the overnight deployment). Section A is the Greeting. Section C is the Call to Action ("Could you roll back…"). Section D is the Closing. The structure Greeting → Context → CTA → Closing is the baseline for clear professional emails. Good context sentences answer: What happened? Where? Since when? Who is affected? — so the reader has everything they need before the ask.
4 / 18
You need to tell a client that a feature they requested cannot be delivered this sprint. Which response is most professionally worded?
Option C is the most professional: it gives a reason ("outside current sprint scope"), takes clear ownership, and provides a next step ("added to backlog, prioritised for next release"). Professional declining emails: ① Acknowledge the request. ② Give a brief reason. ③ Offer an alternative or next step. Option A is too blunt — correct but sounds dismissive. Option B is short but gives no reason or next step. Option D over-apologises and sounds informal ("hopefully next time" is vague and unprofessional).
5 / 18
Which subject line correctly follows professional IT email conventions for an action-required message?
"ACTION REQUIRED: Review architecture proposal — deadline 2026-03-20" follows three conventions: ① Status prefix (ACTION REQUIRED) — tells the reader immediately that a response is expected. ② Clear topic (architecture proposal) — no need to open the email to know what it's about. ③ Deadline in subject line — a date in the subject is the single most effective thing you can do to get a timely response. Option A is good but lacks an urgency signal and deadline in the subject. Option C is too brief. Option D is vague and informal.
6 / 18
Sarah: 'Hey team, just ran some tests on the new API endpoint. Response time is consistently around 8 seconds for requests with over 100 items. I've attached the full report. Let me know if you have any questions!'
Which of the following best describes Sarah's email and how it should be revised to improve clarity and professionalism for a code review discussion?
Sarah's email is adequate but lacks strategic direction for a code review. A good code review update shouldn't just present raw metrics; it should *interpret* them and suggest actions. The explanation highlights the need to frame the response time within a broader context—user experience—and propose potential causes or areas for investigation, which are crucial steps in productive technical discussion. It's important to move beyond simply reporting data and towards actionable insights.
7 / 18
Maria sent this email to the team regarding a recent code change:
Subject: Fix - Bug in User Profile Update
Hey guys,
Just pushed the fix for the bug where user profiles weren't updating correctly. It was a simple typo in the database query, and I've added comments to the code explaining the fix. Let me know if you have any questions.
Thanks,
Maria
The best response acknowledges that Maria's email isn't *bad*, but could be improved for clarity and professionalism in a code review context. While concise is good, providing context - specifically mentioning the user profile issue and its impact - strengthens the message. The subject line needs to be more specific than 'Fix - Bug in User Profile Update'. Including a link to the change would also be beneficial, but adding excessive technical detail isn't necessary for this stage.
8 / 18
Sarah: 'Hey team, just ran some tests on the new API endpoint. Response time is consistently around 8 seconds for requests with over 100 items. I've attached the full report. Let me know if you have any questions!'
Which of the following best describes Sarah's email and how it should be revised to improve clarity and professionalism for a code review discussion?
Sarah's email is adequate but lacks strategic direction for a code review. A good code review update shouldn't just present raw metrics; it should *interpret* them and suggest actions. The explanation highlights the need to frame the response time within a broader context—user experience—and propose potential causes or areas for investigation, which are crucial steps in productive technical discussion. It's important to move beyond simply reporting data and towards actionable insights.
9 / 18
Maria sent this email to the team regarding a recent code change:
Subject: Fix - Bug in User Profile Update
Hey guys,
Just pushed the fix for the bug where user profiles weren't updating correctly. It was a simple typo in the database query, and I've added comments to the code explaining the fix. Let me know if you have any questions.
Thanks,
Maria
The best response acknowledges that Maria's email isn't *bad*, but could be improved for clarity and professionalism in a code review context. While concise is good, providing context - specifically mentioning the user profile issue and its impact - strengthens the message. The subject line needs to be more specific than 'Fix - Bug in User Profile Update'. Including a link to the change would also be beneficial, but adding excessive technical detail isn't necessary for this stage.
10 / 18
Sarah: 'Hey team, just ran some tests on the new API endpoint. Response time is consistently around 8 seconds for requests with over 100 items. I've attached the full report. Let me know if you have any questions!'
Which of the following best describes Sarah's email and how it should be revised to improve clarity and professionalism for a code review discussion?
Sarah's email is adequate but lacks strategic direction for a code review. A good code review update shouldn't just present raw metrics; it should *interpret* them and suggest actions. The explanation highlights the need to frame the response time within a broader context—user experience—and propose potential causes or areas for investigation, which are crucial steps in productive technical discussion. It's important to move beyond simply reporting data and towards actionable insights.
11 / 18
Maria sent this email to the team regarding a recent code change:
Subject: Fix - Bug in User Profile Update
Hey guys,
Just pushed the fix for the bug where user profiles weren't updating correctly. It was a simple typo in the database query, and I've added comments to the code explaining the fix. Let me know if you have any questions.
Thanks,
Maria
The best response acknowledges that Maria's email isn't *bad*, but could be improved for clarity and professionalism in a code review context. While concise is good, providing context - specifically mentioning the user profile issue and its impact - strengthens the message. The subject line needs to be more specific than 'Fix - Bug in User Profile Update'. Including a link to the change would also be beneficial, but adding excessive technical detail isn't necessary for this stage.
12 / 18
Sarah: 'Hey team, just ran some tests on the new API endpoint. Response time is consistently around 8 seconds for requests with over 100 items. I've attached the full report. Let me know if you have any questions!'
Which of the following best describes Sarah's email and how it should be revised to improve clarity and professionalism for a code review discussion?
Sarah's email is adequate but lacks strategic direction for a code review. A good code review update shouldn't just present raw metrics; it should *interpret* them and suggest actions. The explanation highlights the need to frame the response time within a broader context—user experience—and propose potential causes or areas for investigation, which are crucial steps in productive technical discussion. It's important to move beyond simply reporting data and towards actionable insights.
13 / 18
Maria sent this email to the team regarding a recent code change:
Subject: Fix - Bug in User Profile Update
Hey guys,
Just pushed the fix for the bug where user profiles weren't updating correctly. It was a simple typo in the database query, and I've added comments to the code explaining the fix. Let me know if you have any questions.
Thanks,
Maria
The best response acknowledges that Maria's email isn't *bad*, but could be improved for clarity and professionalism in a code review context. While concise is good, providing context - specifically mentioning the user profile issue and its impact - strengthens the message. The subject line needs to be more specific than 'Fix - Bug in User Profile Update'. Including a link to the change would also be beneficial, but adding excessive technical detail isn't necessary for this stage.
14 / 18
John: 'Hey team, I've just run a load test on the new authentication service. The average response time is currently 3 seconds under normal traffic, but spiked to 15 seconds when we simulated 50 concurrent users. I've attached the full report.'
Which of the following best reflects John's intention in this message?
The core purpose is to highlight a significant problem (spike in response time) with accompanying evidence. Options A and D are too strong – it's not an immediate emergency request or a casual report. Option B accurately captures the message's intent: reporting a critical issue with data backing it up. Note that a good follow-up would include suggestions for improvement, but this email focuses on alerting.
15 / 18
You're drafting a Slack message to your team regarding an unexpected error in the payment processing module. The error is intermittent and only affects transactions over $100. Which of the following options provides the most effective communication?
This option strikes the right balance between urgency (highlighting the problem) and avoiding panic. Option A is too alarming and unproductive. Option D lacks detail and doesn't clearly communicate the scope of the issue. Option B uses informal language which might be acceptable in Slack but isn't suitable for a formal update. Option 2 provides context, acknowledges the potential nature of the problem, and invites collaboration.
16 / 18
You need to write a PR description for a change that improves the efficiency of database queries. The change reduces average query execution time by 30%. Which phrasing is most suitable?
This option is concise and directly states the key benefit of the change. Option B provides too much detail and could be seen as boastful. Options C and D are vague and don't explain *why* the change was made. A good PR description should clearly articulate the value delivered to the system.
17 / 18
During a daily standup meeting, you need to update your team on the progress of a feature implementation. You've completed the core functionality but are still working on integrating with the third-party API. Which statement would be the most professional and informative?
This option provides a clear and concise update on your progress. It highlights what you *have* achieved (core functionality) and where you are currently focused (API integration). Options A and D sound overly optimistic or negative without context. Option B is more detailed and professional than the other options. Focusing on specific tasks and challenges demonstrates accountability.
18 / 18
You receive an email from a colleague stating: 'We need to investigate this performance issue ASAP.' What is the most appropriate response regarding the 'Call To Action' section of the email?
The 'Call To Action' is the demand for information. The colleague is requesting specifics – what *exactly* is the performance issue and how serious is it? Options A and D are too detailed at this stage; Option B is a reasonable follow-up but doesn't address the immediate need for clarification. Effective call to actions require precise requests, not vague instructions.
What does the "Professional IT Email Structure — Email Writing Exercise" exercise cover?
Practice writing and identifying the parts of professional IT emails. 5 exercises on subject lines, calls to action, context sections, and tone.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
How many questions are in "Professional IT Email Structure — Email Writing Exercise"?
This exercise has 18 questions. Each one gives instant feedback with an explanation, so you can see exactly why an answer is right or wrong.
Do I need to create an account to save my progress?
No account is required. The progress bar and score are tracked in your browser for the current session -- the exercise is designed to be a quick, repeatable drill rather than something you resume later.
What happens if I get an answer wrong?
You'll see the correct answer highlighted immediately, along with a short explanation of why it's correct. Wrong answers aren't penalized beyond your score, and you can keep going through every question.
How is this exercise different from reading an article?
Articles explain vocabulary and concepts through prose, while exercises like this one are interactive drills -- multiple-choice questions -- that test and reinforce your recall of specific terms and phrasing.
Can I retry this exercise?
Yes -- use the "Try again" button on the results screen to reset your score and go through all the questions again from the start.
Where can I find more Email & Writing exercises?
Browse the full Email & Writing hub for related drills, or check the site-wide exercises index for other IT English topics.
Is this exercise suitable for beginners?
This exercise assumes basic familiarity with IT terminology. If a term feels unfamiliar, check the site Glossary for a plain-English definition before attempting the questions.
How often is new content like this published?
New exercises are added regularly across all categories, alongside new vocabulary sets and articles. Check back on the exercises hub to see what's new.