3 exercises — communicate technical topics professionally with external clients: outages, feature declines, and system limits.
0 / 8 completed
1 / 8
Your SaaS platform had a 47-minute outage. A client emails: "What happened? This caused us to miss an important deadline." Which response is most professional?
Option C is the professional client outage communication. It follows the AIRR framework:
• Acknowledge — "sincerely apologise for the disruption to your work" — personalised, not generic • Inform — exact timeline (UTC), specific root cause (misconfigured failover rule), mechanism of failure • Resolve — "restored service at 15:19 UTC by reverting the change" • Remediate — concrete, numbered prevention steps + RCA document commitment with timeline
What makes this work: 1. UTC timestamps — clients in different time zones need UTC to correlate with their own logs 2. Acknowledges real-world impact — "real impact on your team's deadline" — shows you understand the business consequence 3. Specific root cause — "misconfigured database failover rule" (not just "a technical issue") 4. Numbered prevention steps — concrete and auditable, not promises 5. RCA commitment — "within 48 hours" — professional accountability
Generic apologies ("sorry for any inconvenience", "our team is looking into it") damage trust because they signal vagueness and lack of ownership.
2 / 8
A client requests a feature: real-time push notifications for every data change in their workspace. You know this would cost hundreds of thousands of engineering hours and create infrastructure issues. How do you decline professionally?
Option C is the professional feature decline with a redirect. It:
• Validates the request — "thank you, helps us understand how you're using the platform" — not dismissive • Is transparent about why — engineering cost (6–9 months), pricing impact — honest and specific • Frames as constraint, not refusal — "engineering constraints" vs "we don't want to" • Asks about the underlying need — "what use case is driving this?" — classic needs discovery • Offers an alternative — webhooks in Q2 that may solve the real problem
This is the Jobs-to-be-Done approach to client feature requests: clients request solutions, not needs. The real need here ("don't make me poll your API") might be solvable without building the costly feature they asked for.
Decline language patterns: • "Here's the constraint that makes this difficult at this time..." • "What problem are you solving for? We might have an alternative..." • "This isn't in our current roadmap, but we're building [X] which may address this..."
3 / 8
A client asks: "Can your API handle 10,000 requests per second?" Which response correctly communicates system limitations?
Option C is the correct technical limitation communication for clients. It:
• States the specific limit precisely — "1,000 req/s per organisation" — not vague hedging • Explains the failure mode — "429 Too Many Requests" — the client can check their error logs to confirm • Offers a path forward — Enterprise tier, up to 50,000 req/s • Shows the math — "10,000 req/s" vs "50,000 req/s limit" — explicitly demonstrates fit • Reduces commitment risk — "load testing session on staging before you commit"
Options A ("we can handle anything") is dangerous false commitment. Option B ("no, we can't") is technically correct but doesn't offer a solution. Option D is the worst — completely uninformative.
System limitation communication template: [Current limit] → [What happens if exceeded] → [How to get more capacity] → [How to verify before committing]
4 / 8
Sarah from the Sales team just messaged you: 'The new integration is *amazing*! Users are loving it.' You're a backend engineer reviewing the recent PR. Which response best acknowledges her feedback while maintaining technical clarity? (Note: avoid overly enthusiastic or subjective praise)
This scenario tests framing positive feedback constructively. Option A is too informal and enthusiastic. Option B shifts the focus to technical aspects – a good approach for a PR review. Options C and D are vague and don't directly address her comment or acknowledge the effort involved. It's important to validate user experience without over-hyping the product.
5 / 8
David, a Product Manager, asks you: 'Can we roll out this new feature with just basic error handling? We need to get it live ASAP.' You're responsible for the API. Which response is most appropriate? (Focus on risk mitigation)
This question emphasizes risk management – a crucial aspect of tech-to-business communication. Option A is entirely inappropriate given your role. Option B highlights the importance of robust error handling and monitoring, demonstrating you understand potential consequences. Options C and D deflect responsibility or avoid addressing the core concern about feature quality.
6 / 8
You're drafting a PR description for a change that improves database query performance. The client is non-technical. Which of the following best summarizes the impact in business terms? (Consider the value proposition)
The goal here is translating technical details into business benefits. Option A is overly technical. Option B is also too detailed for a non-technical audience. Option C clearly states the impact – faster response times and a better user experience – which resonates with the client's priorities. Option D describes an internal implementation detail, not the outcome.
7 / 8
Mark, a Sales representative, asks you: 'Our customers are complaining about slow API calls when they're processing large datasets. What's going on?' You've just investigated and found the issue is due to inefficient batch processing. Which response communicates this clearly? (Focus on actionable information)
This tests explaining technical limitations in a way that's useful to sales. Option A is dismissive and doesn't explain *why* it's slow. Option B indicates ongoing work – good, but not immediately helpful. Option C provides the key information about breaking down large requests, offering a practical solution. Option D simply passes the buck.
8 / 8
You're responding to an API response that indicates a '503 Service Unavailable' error. The client reports: 'Our users can't access the system!' Which statement best explains the situation and manages expectations? (Focus on transparency and next steps)
Option A provides a clear and concise explanation of the common cause – high traffic. It acknowledges the impact on users without making overly technical claims. Option B offers vague reassurance. Option C is evasive. Option D minimizes the severity, which can frustrate the client.
This exercise, "Client Technical Communication", tests your understanding of tech-to-business vocabulary and phrasing through 8 multiple-choice questions drawn from real workplace scenarios.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 8 questions. Each one presents a realistic sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Who is this Tech-to-Business exercise for?
It's designed for IT professionals and learners who want to sound natural discussing tech-to-business topics in English — useful for meetings, documentation, interviews, and day-to-day communication with English-speaking teams.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more Tech-to-Business exercises?
Browse the full Tech-to-Business exercises hub for more practice, or explore other exercise categories covering vocabulary, grammar, interviews, and workplace communication.