Client Technical Communication

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.

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..."

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]