🏗 Customer Scenario

User reports: “Room list with ~60 rooms takes too long to load availability in Outlook Scheduler.”
Expectation: faster response. Observed delay: noticeable versus user expectation.

✅ Testing & Baseline

No official guidance on “acceptable” baseline time, so we reproduced in lab:

• Environment: Exchange Server 2016 + Outlook 2016 (LAN).
• Room list: ~30 rooms.
• Result: ~10 seconds from selection to full availability load.

Customer result (~60 rooms = ~20 seconds) scales proportionally → comparable to test.

🔍 Analysis

Fiddler trace shows Outlook flow:

1. Initial request → retrieve room list.
2. Single batch request → get availability for all rooms.
3. Additional refinement request → final updates.

All server-side responses = milliseconds → Exchange performance is optimal.
Delay occurs between steps 2 and 3, where Outlook processes and visualizes data sequentially.

Conclusion: bottleneck = client-side rendering, not server.

✅ Recommendations

• Product team guidance: Avoid lists exceeding 50 rooms
  → 📎Microsoft Docs
• Split large lists into smaller groups (by floor, department, etc.) for better UX.
• Understand: 50 rooms = recommended upper limit, not a guaranteed fast experience.

🧩 Key Takeaways

• Exchange processes requests efficiently.
• Rendering large availability sets in Outlook is inherently slow → client design.
• Organizational room list design impacts user experience.

The end.