Overview
Cloud resource limits were hidden blockers. Users would get stuck completing forms with no clear reason why, and support engineers were overloaded with fragmented requests — each triggering a separate 48-hour SLA without context.
The Opportunity
A preliminary limit-request system shipped with the cloud console launch, but it carried real problems: users often filed unrelated tickets unaware multiple limit requests were needed, and support engineers couldn't see linked requests despite them belonging to the same task. The ambiguity caused delays, confusion, and needless operational drag.
What if the product could detect when a user might be blocked by a limit? Could multiple limit requests be bundled to expedite approval and signal to the support engineer that they were related?
Where we started
The UX team was brought in with an existing process in place. I was selected as lead designer and mentored another designer through the engagement. There was clear room for improvement.
Users completed forms expecting outputs only to be blocked by a limit restriction — sometimes without knowing why. From the company's side, every request entered the queue without context, and each one engaged its own 48-hour SLA, even when several belonged to the same user task.
First Improvement
Our first move was to stop users from filling out forms that wouldn't result in the service they wanted. An API call on page load surfaced their limit restriction before they engaged with the form, and we deactivated the submit CTA to reinforce the block.
Once redirected to a limit request form, users entered a multi-step process designed to bundle requests and give support engineers the context they were missing.
Future-proofing the pattern
Splitting the form into two steps unlocked a powerful advantage. With 180+ services in the cloud, every limit request can vary. Step one captures which service the user wants to increase, so step two can dynamically load exactly the information that engineer needs — no more, no less.
Review & bundle
The final enhancement was a review step — a shopping-cart-like experience where the user could confirm the bundled set of limit increases before submitting. One last check that they were requesting everything they needed to keep moving.
The new process
Customers now group the limit requests they need for a task. Support engineers see them together — engaging a single 48-hour SLA window — and the customer is freed up to begin their work faster.
Faster removal of restrictions delights customers and shows up directly in satisfaction metrics — a key KPI for software retention. But that wasn't where I stopped tracking.
What's next?
Like most things, there's still room to grow. My future thinking is to bring AI into the system to populate limit requests for the customer — moving from service-based limits toward task-based limits so AI can suggest related increases before a customer knows they need them. Marrying the limit process with task-driven AI requests will further compound customer satisfaction and business impact.
