How Do You Write In-App Messages for a Feature Nobody Uses?

How do you write in-app messages for a feature nobody uses?

Write one short message, aimed at one type of user, shown at the moment they hit the problem the feature solves. Lead with the outcome, not the feature name, and give one action that takes under a minute. Low adoption is usually a timing and relevance problem, not an awareness problem.

Every B2B SaaS team has a feature like this. It took a quarter to build, the launch email went out, a few customers tried it, and then usage flattened. The usual response is a big announcement modal that every user sees on login. It gets dismissed in under a second, and adoption does not move.

This article is about the alternative: small, targeted messages that show up when a user actually needs the feature. I will cover how to diagnose why adoption is low, where messages should appear, what they should say, and how to tell whether they worked.

Why do so many SaaS features go unused?

Because most users learn a product once, settle into a few workflows, and stop exploring. New features compete with habits. Unless a feature shows up exactly where a user already works, at the moment they feel the gap it fills, most people never discover it, even if they would value it.

The data on this is stark. Pendo analyzed feature usage across 615 subscriptions and found that 80 percent of features in the average software product are rarely or never used (Pendo, 2019). The same study found that an average of 12% of features generate 80% of average daily usage volume (Pendo, 2019).

A later Pendo benchmark put the median feature adoption rate at 6.4%, measured as the share of features driving 80% of click volume, and found that products in the top 10% reached 15.6% (Pendo, 2024). So even the best teams ship plenty of features that barely get touched. Low adoption on your newest feature is normal. Doing nothing about it is the mistake.

How do you diagnose why adoption is low?

Check three things in order: whether the right users can see the feature, whether they understand what it does for them, and whether trying it is easy. Each failure needs a different fix. A message only helps with the middle one, so confirm the first and last are not the real problem.

Visibility first. If the feature lives behind a menu that the target user never opens, no message copy will save it. Look at which pages and screens the target user actually visits. If the feature is not reachable from there, move the entry point before you write a single message.

Then friction. If trying the feature requires setup, permissions, or data the user does not have, a message just leads them into a wall. I ask a simple question: can a new user get value from this feature in their first try? If the honest answer is no, fix the first-run experience or narrow the audience to users who already have what they need. Only then does messaging become the lever.

Who should see the message?

Only the users for whom the feature solves a real problem right now. Define them by behavior, not by plan or job title. A message shown to everyone is a message that most people learn to ignore, and that habit spreads to every future message you send.

Good targeting usually combines a role or plan condition with a behavior signal. For example, an admin on a paid plan who exported a report manually three times this month is a perfect audience for a scheduled reports feature. That user has felt the pain recently and repeatedly. A brand new user who has never run a report is not.

I like to write the targeting rule in one plain sentence before building anything: show this to people who do X and have not yet tried Y. If you cannot write that sentence, you do not understand the feature's job well enough to promote it. This connects directly to how you define value moments, which I covered in what counts as activation in your SaaS.

Where in the product should the message appear?

Put the message at the point of friction, inside the workflow the feature improves. A tooltip next to the manual export button beats a modal on the dashboard. The closer the message sits to the moment of pain, the less explaining it needs to do.

There are a few common formats, and each has a job. Tooltips and inline hints work best for small, adjacent improvements. Banners inside a specific page suit features that change how that page works. Checklists help when a feature needs a short setup. Full-screen modals should be rare, reserved for changes that affect almost everyone.

Tools like Intercom, Pendo, Appcues, and Userpilot all exist to help place and target these messages, and many teams build simple versions in their own product. The tool matters less than the placement decision. I would rather see a plain inline hint in the right spot than a beautiful modal in the wrong one.

What should the message actually say?

Name the outcome the user wants, connect it to what they just did, and offer one action. Skip the feature name in the headline. Users do not care that you shipped Scheduled Reports. They care that they never have to export this file by hand again.

A structure I use is simple. First line: the outcome, in the user's words. Second line: one sentence on how, tied to their current context. Then a single button with a verb that describes the result, like "Schedule this report," not "Learn more." Keep the whole message under about thirty words where you can.

Compare two versions. "New: Scheduled Reports are now available in the Analytics tab" is an announcement. "Tired of exporting this every Monday? Send it to your inbox automatically" is an invitation, placed next to the export button. The second one speaks to a habit the user already has and offers to remove a chore. That is the version that moves adoption.

How often should a message appear?

Show it once, maybe twice, then stop. If a user dismisses a contextual message, respect that. Repeating it trains them to dismiss everything you show, which damages the next message before you even write it. Frequency caps protect the channel.

A simple rule I recommend: a given user sees at most one promotional in-app message per session, and a dismissed message does not return for at least a few weeks, if ever. Service messages, like a failed sync or an expiring card, are a different category and should not count against that cap.

It also helps to coordinate in-app messages with email and customer success. If a user just got an email about the feature and a call from their account manager, a tooltip on top of that feels like being chased. One owner for adoption messaging across channels, even informally, prevents that pile-up. For the broader launch side, I wrote about how to launch a feature only a few customers asked for.

How do you know if the message worked?

Measure whether targeted users tried the feature and whether they kept using it. Clicks on the message are a weak signal. Repeat use over the following weeks is the real one. Compare against a holdout group that did not see the message, so you know the change came from the message.

A holdout does not need to be fancy. Leave a random slice of the target audience out of the message for a few weeks. If the exposed group adopts the feature at a meaningfully higher rate and keeps using it, the message is doing its job. If both groups look the same, the message is noise, and the problem is somewhere else.

I recommend tracking three numbers for each campaign: the share of targeted users who saw the message, the share who tried the feature within a week, and the share still using it a month later. The third number is the one I report. A spike in first-time use that fades in two weeks is curiosity, not adoption.

When should you stop promoting a feature?

When targeted, well-placed messaging still produces little repeat use, the feature probably does not solve a problem users feel often enough. At that point, more messaging is the wrong tool. Talk to the users who tried it once and stopped, and decide whether to fix it, reposition it, or retire it.

This is the uncomfortable part, and it is why I think adoption messaging is partly a research tool. A good message sent to the right user at the right moment is a fair test of whether the feature has value. If it fails that test, you have learned something important about your roadmap, and you learned it cheaply.

Retiring a feature is also a valid outcome. Every feature you keep has a cost in support, documentation, and interface complexity. If a feature serves a tiny group, consider moving it out of the main interface so it stops cluttering the experience for everyone else.

What should you do next?

Pick one underused feature, write the one-sentence targeting rule, find the exact screen where that user feels the pain, and write a thirty-word message with one action. Ship it to most of the audience with a holdout, and check repeat use after a month.

Resist the urge to launch five messages at once. One well-targeted message teaches you more than a campaign of announcements, and it keeps your in-app channel trusted for the next feature that deserves attention.

I help B2B SaaS teams connect product messaging to the systems behind their go-to-market. If you have a feature that deserves more use than it gets, reach out and let's chat.