5 exercises — practise writing professional English for real IT situations: maintenance windows, vendor escalations, project kickoffs, deadline follow-ups, and first contact with enterprise clients.
IT email scenarios — key principles
Maintenance notice: [tag] subject · exact time + UTC · impact scope · what to do before the window · follow-up commitment
Vendor escalation: error code + duration + account ref in subject · business impact in numbers · what you ruled out · numbered action requests · SLA reference
Deadline follow-up: ticket reference · timeline without accusation · charitable framing · specific ask + alternatives
First client contact: warm-professional · personalised · scheduling offer with timezone · pre-meeting resources · complete signature
0 / 5 completed
1 / 5
You need to notify users of a planned 2-hour maintenance window on Saturday at 02:00 UTC. Which email is most professional and complete?
Maintenance notification email anatomy:
A maintenance notification email must let the reader answer three questions in < 30 seconds: When exactly?What will be affected?What do I need to do?
Why Option B is correct: ① Subject line pattern:[Scheduled Maintenance] Service Downtime — Saturday 22 March, 02:00–04:00 UTC — the [tag] allows users to filter; the date+time+timezone are in the subject so the reader doesn't even have to open the email to get the key fact ② Specific date, time, timezone, duration — "02:00–04:00 UTC (approx. 2 hours)" — never write "Saturday night" for an international audience; UTC is the professional standard ③ Impact scoped clearly — bullet list: what's unavailable, what's paused, what's preserved. The reader can quickly confirm their use case is or isn't affected ④ Concrete recommendation — "complete critical tasks before 01:45 UTC" — gives users something to act on ⑤ Follow-up commitment — "send an update when maintenance is complete" — closes the communication loop ⑥ Contact path — support@example.com — specific, not "email us"
Option A: No timezone, no date, no impact details — inadequate Option C: Overly formal and vague — "forthcoming weekend" and "necessary system maintenance procedures" give no actionable information Option D: Too casual, missing timezone and impact scope for a professional customer-facing notice
2 / 5
Your application depends on a third-party payment API. It has been throwing 503 errors for 4 hours, affecting 30% of your transactions. Your customers are noticing. Which escalation email to the vendor is most effective?
Vendor escalation email — professional incident communication:
When a third-party service is causing a production incident, your escalation email has two goals: get the problem solved quickly, and create a formal record. Angry emails (Option D) often slow support response times. Vague emails (Options A, C) give the vendor nothing to work with.
Why Option B is correct — structural breakdown: ① Subject line — [URGENT] tag + specific error code + duration + account number. Support teams triage by subject line; every detail here means faster routing ② What, when, how long — "503 errors from /v2/charge, since 09:15 UTC, ~4 hours ongoing" — pinpoint context with zero ambiguity ③ Business impact in numbers — "30% of transactions failing, ~$8,000 impact, 400% error rate increase" — converts a technical issue into business urgency the vendor can escalate internally ④ What you've already ruled out — "API keys valid, auth working, isolated to /v2/charge" — this is crucial; it proves the problem is on their side and prevents a slow back-and-forth of basic troubleshooting ⑤ Numbered action requests — "Confirm awareness · ETA or ticket number · fallback endpoint" — clear, specific, and easy to address one-by-one ⑥ SLA reference — "SLA requires < 4h for P1, contract ref: C-2024-0047" — this is professional leverage, not a threat. It signals you know your rights and are documenting the timeline
Escalation formula: [URGENT/P1] [Service] [Error] — [Duration] — [Account/Ref] Body: What broke · Since when · Business impact · What we ruled out · Requested actions · SLA reference
3 / 5
You are a tech lead kicking off a new project with a team of 6 engineers who haven't worked together before. Which kickoff email sets the right foundation?
Project kickoff email — professional team communication:
A kickoff email does four things: establishes who everyone is, sets context for the project, gives people immediate links and actions, and establishes the leader's communication style. It's often the first shared record of the team's structure.
Why Option B is correct — what each section does: ① Subject line — [Project Helios] Kickoff — Team Intro + First Steps — the project name in brackets makes it searchable; "Team Intro + First Steps" tells recipients to read this one carefully ② Short intro sentence — own name + role + brief welcoming tone. Professional but warm. ③ Team roster with roles — 6 people in role bullets. New teams waste days figuring out "who owns what" — this removes that ambiguity on day 1 ④ Project context in 2 sentences — what it is, when the demo is, who the stakeholders are. Every engineer should understand the business context of what they're building ⑤ Link list — Jira, GitHub, Figma, Slack, architecture doc — no one has to ask "where is the repo?" ⑥ Numbered first steps with deadlines — "review by Friday, set up env, join Thursday call" — specific, actionable, time-bounded ⑦ Warm close — "happy to be on this with you all" — professional relationship-building
Option A: No context, no intros, no links — fails the new team completely Option C: Bureaucratic template language ("revert at your earliest convenience", "[to be defined]") — gives no actual information Option D: Too informal — excessive emoji and enthusiasm don't substitute for structure
Kickoff email formula: Subject: [Project Name] Kickoff — [What the email contains] Body: Brief welcome · Team roster with roles · Project context (what + timeline + stakeholders) · Links · First-week actions with deadlines
4 / 5
You need to follow up with a colleague who missed a deadline for delivering a code review you depend on. The review is now 3 days late and is blocking your PR. Which email is most professional?
Follow-up on a missed deadline — professional tone and structure:
Missed deadlines between colleagues happen constantly in software teams. How you follow up affects both the outcome and the working relationship. The goal is to get the task done without damaging trust.
Why Option C is correct: ① Specific subject with ticket reference — "PR Review — #412 auth-refactor — Follow-up" — the reviewer can find the PR immediately without asking ② Timeline stated without accusation — "sent for review on Tuesday, now three days" — the facts speak for themselves ③ Personal impact without drama — "I'm blocked from merging" — explains why this matters without catastrophising ④ Charitable framing — "totally fine if this slipped through" — assumes the best, preserves the relationship ⑤ Specific asks with flexibility — "today or tomorrow?" gives a timeframe; offering alternatives (reassign or split) shows you're solution-focused, not just complaining ⑥ No pressure tactics — no "URGENT", no "please confirm receipt", no guilt
Option A: Accusatory ("why haven't you") — damages the relationship and puts the other person on the defensive Option B: Too vague — "just wanted to remind you" gives no specifics and is easy to ignore Option D: "URGENT" in the subject for a 3-day slip is disproportionate; "please confirm receipt" is passive-aggressive
Missed deadline follow-up formula: Subject: [Task/Ticket] — Follow-up Body: What I sent · When · Impact of waiting → charitable framing → specific timeframe ask → alternatives/flexibility
Tone calibration: Day 3: polite follow-up as in Option C Day 5: add escalation signal ("I may need to reassign to keep the sprint on track") Day 7+: loop in manager with a neutral "FYI I'm still blocked on X, escalating visibility"
5 / 5
A potential enterprise client reached out asking for a meeting to evaluate your company's API platform. You have never spoken to them before. Which reply is most professional?
First outreach reply to a potential enterprise client:
A first reply to a potential enterprise client is a critical first impression. It signals professionalism, competence, and the communication standard they can expect from your organisation. Both extremes — overly formal (Option B) and too casual (Option D, Option A) — miss the target.
Why Option C is correct — element by element: ① Subject line — "Re: API Platform Evaluation — Happy to Connect" — echoes their topic + signals positive response; enterprise clients often triage email by subject ② "Dear [Name]" — not "Hi!", not "Dear Sir/Madam" — standard professional first contact when you know the name ③ Warm acknowledgement in one sentence — "great to hear from [Company Name]" — personalised, not generic ④ Re-states the purpose clearly — "walk you through our API platform and understand your evaluation requirements" — enterprise sales involves understanding their needs, not just pitching ⑤ Specific scheduling offer — 30-minute call + availability window + timezone + willingness to adjust. This removes the scheduling dance ⑥ Pre-meeting resources — links to API docs and platform overview give them something to review before the call, which signals you value their time ⑦ Professional sign-off — name, title, company, phone, email — enterprise contacts need all of this
Option A: Multiple exclamation marks read as unprofessional in enterprise B2B communication Option B: Awkward over-formality ("We acknowledge receipt of your communication") — outdated register that signals bureaucracy Option D: Works for an internal colleague; too informal for a first external enterprise contact
Warm-professional first reply formula: Subject: Re: [Their topic] — [Positive signal] Dear [Name] → thank + personalise → confirm intent + value prop → scheduling offer with window + timezone → optional: pre-meeting resources → warm close → full professional signature