Overview
Oracle Cloud Infrastructure customers had no centralized way to manage support requests, forcing them to leave the console to create, track, and resolve issues. This fragmented experience increased support costs, slowed resolution times, and created friction during critical customer workflows.
The Challenge
One of the fastest ways to identify product gaps is by understanding how competitors solve the same customer problems. During a competitive analysis of AWS and Azure that I conducted, one gap stood out immediately: Oracle had no modern, integrated support experience. Oracle was still establishing itself in cloud computing and needed to close critical experience gaps to compete with the market leaders.
I identified five areas that needed focus in the competitive analysis for support:
- Homepage: How does support live on the homepage?
- Header: Where is support on the global navigation items?
- Dropdown Menus: What kind of dropdowns or menus does the service employ?
- List View Support Pages:How does the service list previous or active support tickets?
- Support Detail Pages: What does an active support ticket details view look like?
Support tickets shouldn't require a secondary product to get help. Much of the support tickets that were being generated never had the necessary information to be solved and would require engineer and customer communication constantly to find a resolution. The ping pong game of back and forth responsibilities was too high to result in fast ticket closure. OCI needed a fast in-console solution.
What I inherited (My Oracle Support)
My Oracle Support (MOS) has existed for over a decade at this point and when it was launched, was an industry leader, but it hasn't been updated since. This lack of care had started to make its way into the products MOS was serving, including our Cloud Console. Support tickets would come into the central hub of MOS with no context. Engineers had to figure out what the customer was trying to do, where they were, and how to fix their issue.
Partnering with Engineering
There is a special relationship between developers, product managers/business interests and designers. I wrote about this relationship in an article for Linked In (you can read that here). Developing those "hey, have a second" kind of relationships is what senior-level design requires. Because of this, I engaged development early in the product design cycle.
The way OCI's Console is built is very siloed. Each service within the console was controlling their settings and their content. OCI had a styleguide that was stitching everything together, but the siloed nature of the Console was ever-present. Working closely with developers early on, I learned that there was an element that persisted across the console's architecture and would remain present on all pages. This was called "The Shell", our global header and footer on the page was being sent code consistently across all pages of the Console product. On top of this, The Shell knew what content was being loaded underneath it. It could provide context of where the user was. Discovering this architectural advantage was only possible because I partnered closely with the engineering team early in the design process. It reinforced how critical that collaboration was to the product's success.
A pivotal advantage
By involving engineering from the beginning, I uncovered an architectural advantage that significantly reduced implementation effort while improving discoverability and support efficiency. Adding a support engagement icon off of The Shell would mean the support ticketing system would be ever-present, require only one team to implement, and provide context of where the user was when they engaged the support request.
What context within the Console provided
Knowing where the user was when they engaged the support request form would enable us to speed up the support request submission process, a feature that a third-party tool could never have being outside of our system. A user engaging support from a database page would more than likely have a question or concern about a database. I still needed to account for users whose support requests weren't related to the page they were viewing. The workaround to solve this edge case was pre-population. Pre-populating the form reduced effort for the majority of users without adding friction for the minority whose requests fell outside the detected context. For 94% of our users, this meant faster support ticket creation just based on the context of where the ticket was engaged and a zero cost to the other 6% of users who could mimic empty form behavior by interacting with the unwanted suggested data.
Decision point in the workflow
Another advantage was that the user's place in their workflow wasn't lost, it was only paused via a drawer overlay. Keeping this drawer at 75% of the page's width enabled the user to make a choice on their next step. Would they like to see, in more detail, the statuses of their support tickets and other support related topics, or, would it be easier to return to the work they were doing and no longer engage with support after their ticket was opened. The choice was easily available to the user. They could see where they came from, and call to actions on where to go if they wanted to go deeper into support. Rather than forcing users into a support workflow, the Console preserved their place and let them decide whether to continue working or explore support resources in greater depth.
Solving problems before they become tickets
The persona of a worker in the cloud computing industry was one that was highly knowledgeable and self-starting. This meant that a support ticket and interaction with our support engineers wasn't always the best answer for them. To reduce superfluous support tickets and provide these users the solution they were seeking themselves, I designed the product to offer tabbed options of documentation and lists of previous support solutions (and eventually AI tailored assistance). The goal was to never stop a user from filling out a support request, but, should they find the answer elsewhere, they could do so with the alternative solutions the new support designs were providing.
The support center, OCI edition
For users who needed more than contextual assistance, I designed Oracle's first integrated Support Center. The Support Center would use an API call to grab certain data points from MOS (My Oracle Support) but display them in-console enabling the user to stay within the app they were using. The resources of the support center included learning, documentation, global announcements and support chat (our first version of chat that would eventually become AI powered). Users no longer had to rely on a secondary product to get help, they could stay within the product they were using. Support engineers would get context to the support tickets they were assigned, expediting their closure rates, and superfluous tickets were diminished with the help of self-service resources via the documentation and learning components. Support center brought a nearly two-decade-old system up to par with our competitors without having to replace or redesign the system.
What's next?
LLMs, agentic AI and conversational support agents would be my next step. So much of the early OCI days were centered around services within the Console. Each service acted as its own product but that isn't how our users were using the Console. Everything became task-based when users were involved. For example, provisioning a virtual machine required compute, database, storage, and licensing services working together. Our AI agents know these requirements and can start knitting together these services as tasks for the user. Looking ahead, conversational AI represents the natural evolution of this work.
Conclusion
The Support Center transformed Oracle Cloud Infrastructure from relying on external support workflows to providing a fully integrated, self-service support experience. Beyond reducing support costs and accelerating issue resolution, the project established a foundation for future support capabilities while strengthening customer trust in the OCI platform. The project reinforced my belief that the best enterprise products don't simply add features—they remove friction from the moments that matter most while improving operational efficiency for both customers and the business.
