Recently, we shared how we pulled 2,500+ support tickets to figure out what users were getting stuck on. The goal was simple: reduce support volume by helping people move forward—without needing to reach out.

This time, we’re sharing what happened next:

• How we built in-app help for each question
• The patterns we picked (and why)
• A few practical tools to help you do the same

If you missed part one, you can catch up here before diving in.

Step 1: Matching themes to in-app patterns

Once we had our list of top questions, we had to figure out how to actually solve them inside the product. That started with understanding the theme behind each question—and matching it to the right in-app pattern. We asked ourselves:

• What’s the theme of the question we’re solving?
• Where were users getting stuck—understanding the feature, using it, or something else?
• Was there existing content we could update instead of starting from scratch?
• Who needed to see this help, and did we already have a segment for that audience?

Once we scoped the experience, we chose the right in-app pattern to match the need.

Here’s how we matched each pattern to a real support moment:

Step 2: Build the experience

We tackled each experience one by one—writing helpful, focused content and making sure it showed up at the right time for the right users. It looks like:

• Writing content that directly answered the question
• Tailoring the tone, placement, and timing
• Testing logic to make sure it showed up in the right context for the right users
• Linking out to a support doc when deeper explanation was needed—but keeping help in-product wherever possible

Here’s how one of our new Pins looked:

And one of our new video explainer Slideouts:

Pro Tip: Need help writing Tooltip copy?

Use this AI prompt to speed things up:

I'm trying to answer this frequently asked user question with a small in-app Tooltip. Tooltips are small, so character count should be less than 200. Give me copy that provides the answer in clear, plain language using this support doc: [Insert link to doc here].

Text copied

Step 3: Use clean segmentation

We relied on existing segments as much as possible and avoided nested or one-off logic that would be hard to maintain.

Step 4: Share for review

Before anything went live, we shared each experience in our #AppcuesforAppcues Slack channel to get quick feedback from the team. We included:

• The experience name
• A screenshot and test link
• Who it targeted
• What it solved

This made it easy for the team (including Support and CSMs) to weigh in quickly, without slowing things down.

Here’s a Slack template we use (and another resource that might help too—this Notion Team Project Hub template is a great starting point for organizing shared reviews and cross-functional feedback).

Slack Review Template

Hey everyone! Would love your feedback on this new Appcues experience we’re publishing.

The goal: [Address a commonly asked question in our product]

Audience: [All Users / Specific Segment Name]

Test link: [Insert test link here]

Solves for: [Quick description of the question or issue this addresses]

Let me know if you see anything we should tweak before it goes live!

Text copied

We’re expanding this approach across more parts of the product and starting to track how it’s impacting support ticket volume.

We’re also working on better ways to report on performance from inside Appcues—and we’ll share more on that soon.

Want the next update?
Subscribe here to get future Made with Appcues posts straight to your inbox.