Why nobody dares to update old in-app help
There is a paragraph in your product that everybody knows is out of date. It describes a screen that changed two releases ago, or a step that no longer exists, or a limit you raised last spring. People work around it. New colleagues are told to ignore it.
And still nobody touches it. Not because it is hard to rewrite, but because of what happens when you try.
The four reasons, in the order you meet them
You cannot find where it lives. The sentence is on screen, and the screen is a component, and the component gets its text from somewhere. Twenty minutes later you have three candidates and no certainty.
You cannot tell where else it appears. The same explanation is probably in two other places, written slightly differently. Change one and you have made your product less consistent, not more.
You do not know what depends on it. Maybe a support macro quotes it. Maybe a test asserts on it. Maybe a customer wrote a runbook around that exact wording.
You have to ask someone. And the person you ask has a sprint, and your sentence is not in it.
Each of those is small. Together they are enough to make anyone choose something else to do, which is why old help text is not a writing problem but an access problem.
What it costs to leave it
The visible cost is a support ticket now and then. The invisible one is larger.
Text that is known to be wrong teaches users to stop reading. Once someone has been misled twice, they skip the explanation and click until something happens, and then they write to you. Your help then costs you money without doing any work.
It also compounds. Every release that goes out while the paragraph is wrong widens the gap between what your product does and what it says. At some point a rewrite is no longer an edit but a project, and projects need a quarter.
What makes it fixable
Nothing about ownership, priorities or courage. Three properties of where the text lives.
One place per explanation. If a sentence exists once and is requested by key wherever it is needed, changing it is changing it. Not hunting for copies.
A record of where it is used. Before you change a sentence you want to know where it shows up. HelpCCMS keeps that as a note on the key, and a coding agent can write it back while it integrates, so the register shows it. What it will not do is discover that by itself: if nobody records it, nobody knows.
Publishing that is one action. When the change reaches users because you published it, the editor stops being a request form.
Add one more, which is easy to forget: you need to be able to read all of it at once. Most out of date paragraphs are not found by a user complaining. They are found by someone reading the whole set for the first time.
A way to start that does not need a project
Pick the paragraph you already know about. The one people warn each other about.
Give it an address. Publish it as it is, wrong and all, and point your product at that address. Now change it. If the new version is live within minutes, and you can see every place that requests it, you have the only thing that was missing.
Then do the next one. The list is shorter than it feels, and it ends.