Advertising isn’t the only way to make money, even for an advertising platform. Discover how I recovered 6.9% more revenue per support issue with content design.
A billion-dollar enterprise that relied heavily on advertising had consistently lost about 2% of its revenue to bugs, convoluted product settings, and poor in-product communication. The company’s already-complicated ad platform was powered by even more complex software engineering beneath the surface, making direct fixes to the product itself too difficult in the short term.
That’s where I entered the picture. My assignment was to update troubleshooting content for an internal tool that diagnosed technical issues for this company’s advertisers that empowered sales and support to solve those issues.
This is how I turned that into a revenue boost.
The process
The first challenge was to understand how this client’s advertising platform worked—but from the inside. This meant learning many of the technical secrets behind the curtain that even the most experienced pay-per-click advertisers might never hear about.
Spoiler: it was a lot.
Unfortunately, the company’s internal documentation was both sparse and fractured. It had operated for years without translating much of its major technical concepts into standardized plan language.
I worked with an internal engineering team to get the inside track on how these technical issues occurred, as well as how they affected the rest of the advertising launch process for the company’s clients.
I realized that synthesizing documents alone wasn’t going to cut it. Accessing that institutional knowledge was still crucial, so I had to tap into another source to get it: support specialists and engineers.
This was a bit of an exercise in stakeholder management and detective work all rolled into one. Not everyone wanted to dedicate their valuable time to someone else’s project. Their input became increasingly critical, though. The knowledge just didn’t live anywhere else.
I turned these subject matter experts into collaborators much faster by positioning my new content as a benefit to their daily lives.
- To engineers, I framed this as a way to reduce technical support requests.
- To support specialists, I framed this as a way to reduce escalations to their desks.
- To administrators, well, I just kept bugging them until they answered.
And it worked.
I created a document to collect feedback and to track sign off from those subject matter experts. There was no mandate to get their approval, but—given the lack of credible documentation—I wanted to establish a pattern of trust and legitimacy with the new and improved troubleshooting content.
The action
That process led me to expand the existing troubleshooting content considerably. Most of that existing material was only 2-3 sentences, yet it became clear that most issues contained too much context and technical detail to compress into such a small size.
Clearly, users had trouble understanding these troubleshooting problems, let alone solving them.
I discovered key user information while learning all of this, too: most users had a rather short tenure at the company. The salespeople tended to be under 2 years with the company, while the support users were outsourced call center agents with very high turnover rates.
That explained a lot. At best, it meant that most users had a low-to-intermediate proficiency with this ad platform’s issues. At worst, they were expected to resolve issues with nearly zero context or company documentation.
Ouch.
That’s when this pattern emerged.
Instead of just giving the users a brief description and expecting them to go find answers for themselves (with documentation that didn’t exist), I developed this pattern for each piece of troubleshooting content:
- The problem statement
- Extra context
- Solution steps for the advertiser
- Solution steps for the agent
- Internal and external resources
I gave each section below the problem statement a header, too. This gave new users the information they needed up front while still empowering the more experienced users to scan those headers efficiently.
This was my hypothesis for the new content format:
- Contextualizing issues would reduce time spent researching each issue.
- Including multiple solutions per issue would improve the problem resolution rate.
- Ordering solutions would make both agents and advertisers feel more in control.
I was on to something.
The results
The test results weren’t just good—they were great. The data scientist’s report showed that the new content resulted in an average of 6.9% additional revenue recovered per support issue. For a company that makes revenue in the billions, that number made a serious impact on its bottom line.
Here’s where content tapped into the power of scale: those 35 technical issues each occurred anywhere from 1,000 to 4,000,000 times per month (that’s not a typo). That extra 6.9% revenue reflected many, many support tickets (and it continues to do so).
The users received better tools to do their jobs, and the company’s performance improved significantly in this area. The scale of this content improvement made the project well worth the money by several orders of magnitude.
And that’s how I improved the business with the power of content design.
