3 exercises — communicate technical topics professionally with external clients: outages, feature declines, and system limits.
0 / 3 completed
1 / 3
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 / 3
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 / 3
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]