How to improve customer self serve with Ozmo 3.2

An in-depth look at how Ozmo’s Experience & Design team enhanced the self serve experience

At Ozmo, we’re constantly examining our content when it comes to what questions and problems exist for customers while developing solutions around them. Taking our literal content aside, there’s an experience that exists around the content enabling customers to sort through our library of content and find the answer they’re looking for. This is Ozmo self serve and is one of many products at Ozmo that the Experience & Design team works on every day. 

With the 3.2 release of our self serve offering, Ozmo has made great strides in creating more seamless means for users to find the right content. Months ago, we began an investigation into the current state of the product where we asked two questions: how do customers expect to find the content they’re looking for and can they find it easily?

The Experience & Design team at Ozmo poured over analytics, looking at metrics such as utilization and how far into Ozmo’s help content users were progressing. Taking these goals of delivering even more customers to the most helpful answers, the Design team developed several hypotheses for potential areas that might be hindering solution seekers.


Hypothesis #1: Having more routes or abilities to arrive at a possible answer is valuable and it ultimately results in guiding more people to solutions.

Depending on the integration method of our self-serve content, many customers were starting their path by orienting themselves with their device or app they have questions about. This device and app selection process, or flow as we refer to it, had areas for improvement. In other words, there was only one option for how you could find your specific device and app. This initial step was for many, the gateway to arriving at a potential solution. What if this process of finding a device or app could be better optimized? Could we take some cues from what’s become typical e-commerce and offer many alternative ways of selecting your device? 

Hypothesis #2: The appearance of the device and app selection step could be modernized and more consistent to foster additional trust with our customers.

As a team of product designers, our more typical tasks are thinking about the experience of the software we’re designing – how a user moves from one area to another and how that movement delivers them to their goal. Additionally, we concern ourselves with how the aesthetic or visual appearance of our products influence our users and how it makes them feel. 

Did arriving at this first step feel like a warm welcome for customers? What are we communicating to individuals in need of support?

Hypothesis #3: The amount of content and possible solutions presented at this point in the user journey could be streamlined for better decision-making.

Ultimately, in any design process, too many choices for a user can possibly lead to no choices being made at all, a concept otherwise known as decision paralysis. As users seek help and support after choosing a specific device or app, Ozmo exposes all relevant support content. Here, they’re now faced with finding a solution that sounds appropriate for their specific, unique problem. 

The impressive amount of tutorial content that exists for a single device or app necessitates layers of categorization, which essentially resulted in a lot of work for a user trying to navigate their device while still on the lookout for their anticipated solution. How can we keep this feeling approachable and digestible?


With all of these hypotheses in mind, several rounds of ideation and brainstorming across teams of designers, engineers and product ensued. At Ozmo, we believe in plentiful ideas and teams of cross-discipline cohorts are the best to deliver them. 

Ideas in hand, the Ozmo Experience & Design team laid out milestones and dug into some rapid research and investigation. With industry and competitive insights, several experiments emerged where we quickly exposed new ideas into our products to see what moved the needle and performed better. Experiments lead to confidence in possible new features or shifts in user flows, which lead to user testing and more iteration and refinement. This brings us to Ozmo 3.2.

What’s new in release 3.2

Look, feel and usability

Across both steps in our product journey — selecting a device or app and then subsequently finding answers — our research suggested that we needed to modernize our aesthetic and strengthen our relationship with possible users. Trust is paramount, especially in a support-scenario where a customer might already be frustrated or stressed.

At the initial device or app selection step, visual improvements to hierarchy and emphasis were made to help users easily find their preferred starting point and begin their search for solutions. We created clear distinctions between possible device and app selection opportunities making sure our rhythm, spacing and sizing all supported a user in understanding what’s related and what belongs together. 

The team also investigated and improved on the verbiage across this initial step. In what we fondly refer to as the “economy of language”, we examined what we’re saying to our users and shifted towards being as succinct as possible while still speaking in a human-like, friendly way. All these changes influenced how this initial step was perceived. Users felt secure that they were now on a pathway to their support content, as expected.   

The Experience & Design team carried this visual consistency across the full product, ensuring a sense of familiarity as a user selects their device or app and then shifts into the following step of exposing support topics.

Once at the support topic selection step, our research and experimentation found our assumption valid: the way we were presenting our content was overwhelming. From a visual standpoint, our resulting solution here aimed for simplicity. Blurbs of unnecessary text were chopped and the search bar was emphasized and visually distinguished. 

Perhaps the biggest change here was to shift all available topics into a tile pattern, where each possible category of support could be presented in a simple, more pleasing grid of iconographic tiles. 

Simply clicking on a category tile causes it to expand, revealing additional layers of sub-categories and topics that could be quickly examined. Using a mixture of these tiles and subsequent accordions tested overwhelmingly positive in user tests where we heard feedback like “It looks easy to navigate”, “I think it makes sense. It’s simple. It’s systematic”.

The sweet sound of user validation: a Product Designer’s dream.

New features

Not only did we make improvements to the aesthetic of self support and how we are re-establishing a trustworthy feeling experience, we also refined how users can sift through a collection of topics with less stress and more efficiency. As for our remaining hypothesis, would having more avenues guide more users to various topics?

Our research and investigation pointed to yes, it would

Circling back to our aforementioned ideas, the Experience & Design team needed to take our device and app selection process from a single, lone highway to a multi-directional interstate system. Our ideas were shifted into experiments and then back into an iterative design process with user testing throughout to ensure optimal usability. 

Here are the features that bubbled to the surface as part of the product in 3.2.

Popular tiles

At the step of finding and selecting your device or app, Ozmo is introducing popular devices. This assortment of devices is dynamically presented based on utilization metrics relevant to each of our customers. This set of tiles acts as a pathway for users to see their device immediately and jump right into content relevant for them. This achieves both a new route in along with increased efficiency by providing a faster means to possible solutions and content. 

Tile selection

With 3.2, an entirely new method of finding and selecting a device or app has been layered into the product. Users are now presented with a tile-selection pattern, highlighting manufacturers and their branding as a recognizable first step in choosing their device or app for relevant topics. Upon choosing the manufacturer of your device or app, a secondary set of tiles are exposed, showcasing device or app imagery along with clear labels. This pattern feels fast and simple but leans into a more scannable, visual approach to selecting a device or app. 

The future of customer self service

All in all, Ozmo’s self serve portal is now more polished and congruent for its customers. A user’s steps to answers and problem resolution have become more varied, which has allowed us to capture a broader set of users and understand how they might be uniquely seeking support. 

As with any major release, we are keeping an eye on the data. Post-release validation is an important part of Ozmo’s product design and development process. Any indications of change in metrics or behavior will be our guiding light to dig in deeper with more user testing and investigation, ultimately driving continued iteration and improvement of our product.

Want to see how Ozmo’s new 3.2 advancements can help improve your customer self service? Request a free demo with our team of experts to get exclusive information and product details on our self serve solutions and how they can transform your business today.

Building a world-wide, real-time search service

At Ozmo, we produce thousands of device and app tutorials and heavily utilize Amazon Web Services (AWS) managed Elasticsearch to enable customers to easily search for answers to their support inquiries. This started with a single Elasticsearch cluster in us-east-1 and eventually expanded to us-west-2, using a simple nightly sync job with us-east-1 as the master cluster location, illustrated below.

Elasticsearch Pipeline Architecture (Old)
Old search architecture

As Ozmo has grown, however, our customers need real-time updates wherever they are, in addition to not being susceptible to a single point of failure. Our search service should be able to easily expand to additional regions wherever needed. This post describes the many issues we faced in migrating to a highly available, real-time architecture and how we dealt with them.

Goals of the upgrade

First, we established our goals, which spanned four primary areas: make the service highly available, allow easy recovery, provide real-time updates and of course not impact the end-user at all during the process. Implementing real-time updates across all regions proved to be the largest task because this requires reliably replicating all data to all regions.

High availability

  • No single point of failure. If one region has issues or goes down it should not affect any other regions.
  • Fast fail-over, no matter where a request originates from. Requests normally routed to the us-east-1 region should automatically go to us-west-2 (and vice-versa) without any human intervention.

Disaster recovery

  • Elasticsearch should not be the main storage location for documents. Currently, quite a bit of processing must be done when retrieving metadata from S3, creating a properly structured indexable document, to finally indexing it into Elasticsearch. Ozmo wants something in the middle to hold the processed documents before indexing it into Elasticsearch.

Real-time updates

  • The above diagram shows data is only replicated to us-west-1 nightly. Instead, all regions should receive updates simultaneously.

User experience

  • No end-user impact. The changeover should be seamless and the end user should not notice anything different.

Options we considered

We considered Elastic-hosted Elasticsearch Cross-Cluster replication, but didn’t pursue this option because it was just recently released when this project began. We had already been heavily utilizing AWS-managed Elasticsearch so instead, a replication middle layer was chosen to distribute documents globally prior to indexing.

Commonly mentioned replication layers include S3 region mirroring, DynamoDB, and Amazon Kinesis[1]. DynamoDB stood out to us in particular because it acts as a database and has great support for triggering Lambdas with a 24-hour retry period.

What we did and why

To summarize our approach, data originates in S3, is sent to DynamoDB and replicated globally, then is sent to Elasticsearch. The new event-driven architecture, illustrated below, utilizes Lambdas to process and transport data between services.

Elasticsearch Pipeline Architecture (New)
New search architecture

We utilize Infrastructure-as-Code practices as much as possible to make testing and deployment easier, and CloudFormation works very well to manage all the various components (Lambdas, IAM policies, VPC subnets, etc). This project was a great way to try different strategies to see what worked best since building Lambdas with CloudFormation is still relatively new to us. Conveniently in this new pipeline, Elasticsearch updates are only generated internally, so even if there is an issue there is some flexibility to fix it before the end user is affected.

Issues building the new pipeline

Going into this project, some challenges were definitely anticipated around designing the service to be highly available and real time. This included learning about and working with AWS CloudFormation, Lambdas and other parts of the AWS ecosystem we hadn’t used before. Many smaller issues during document processing, however, came as a surprise during testing. These issues were harder to catch since they only came up in the final stage where new search results were compared to old results.

  • CloudFormation: We utilize CloudFormation to help set up and provision many infrastructure components, but most of these cases use a pre-built template. Combining CloudFormation with Lambdas meant learning about the details of how CloudFormation works and how to use Lambdas alongside it – both of which were somewhat new to us.
  • Lambdas: We are utilizing several Lambdas in production, but this project was a great opportunity to create a better workflow applicable to other teams for developing and testing Lambdas. The whole Lambda ecosystem is quite frustrating at first between deployment, versions, aliases, testing and tying it all together with CloudFormation. Many of these issues were solved by a simple Python wrapper around AWS tools along with an in-house build script to help local development.
  • Document variation: The final Elasticsearch documents had some variations that were not completely obvious until we started testing. The final month or so was mostly comparing Elasticsearch results, finding a small edge case, taking that edge case into account and repeating. We intentionally didn’t simply create and restore an Elasticsearch snapshot to ensure the new pipeline was backwards-compatible.
  • S3 events: S3 only allows a single destination for a particular action/prefix/suffix pattern. Thankfully this just required a simple SNS trigger to fan out events to multiple destinations.


Most of the slowdowns encountered were due to not completely knowing how a service works (Lambdas, CloudFormation) or not being familiar with small internal metadata details. Eventually these details were worked though and the upgrade was very successful. The new architecture can easily be expanded to even more regions without much effort. Utilizing the new event driven architecture, documents are now processed almost instantly and available to customers no matter where they are in the world.

Over 6,400 support agents benefit from free access to Ozmo for Agents

During these times when the world is practicing social distancing, people are connecting through technology in new, innovative ways and spending more time on their devices. With this comes a spike in technical issues and questions we may not normally encounter. For many enterprises, this means higher service requests and longer wait times for consumers. To help enterprises manage customer support during COVID-19, we are offering free access to our assisted support product, Ozmo for Agents, to create a seamless, contact-free interaction.

Since March, we have successfully onboarded new enterprises to Ozmo’s platform and have expanded support to current customers. Companies can now offer support agents access to Ozmo’s extensive virtual device library free of charge. To date, the program has been met with an overwhelmingly positive response from businesses and their support agents.

This is amazing, please keep developing this!

Direct feedback from call center agent, top tier mobile device OEM

In the last month, we have brought on four new mobile operators and expanded service support to seven of our customers. Over 6,400 agents within their support centers have benefitted from free access to Ozmo for Agents, using it over 18,000 times in the short time this has been live. In addition, hundreds of agents from our current customers on the Ozmo platform have benefitted from expanded library access with more virtual devices at their fingertips than ever.

Reps are happy because they have been asking for device emulators forever.

CX Manager, tier one US mobile operator

Support staff can offer customers more efficient and accurate answers

With safety in mind, our purpose is to ensure enterprises can provide an optimal experience for both agents and customers alike. By using Ozmo for Agents, support staff can offer customers more efficient and accurate answers while adapting to their at-home work environments and remove the need to handle physical devices.

The Work from Home team is delighted to have such a robust capability on-board so quick and easy and FREE!

CX Manager, tier one US mobile operator

Free access to Ozmo for Agents

We invite you to use our platform free of charge, no strings attached. Email us at to discuss how we can help you expand your customer support using our platform today.

Promoting self support featuring the Google Pixel

At Ozmo, we believe that every support interaction is an opportunity to rewire customer behavior to self-support. Not only do we have the world’s leading support platform for the call center that drives millions of interactions to self-support channels, but Ozmo also offers a consumer-facing product built for self-serve, scalable digital support.

Nobody wants to call into the call center. In fact, 80% of people between the age of 18 and 65 said calling traditional customer service phone lines is inconvenient. Ozmo’s support platform offers solutions for support in channels that your customers actually prefer to use.

Watch the above video to see the brand new Google Pixel live in Ozmo’s interactive tutorial product.

To learn more about what Ozmo can do for you, contact us here.