How do you keep everything consistent as the business changes?
- In the section "What moves in days, and what waits for you," the draft sorts updates into three groups and gives no timing from your own engagements. When a client changes a price or drops a service, how long does it take you to get the site, the sequences, and the profiles current? The post publishes with the groups and no numbers, and your figure would let it say how fast this happens.
- In the section "Old versions have to leave," the draft describes retiring a superseded guide so the system stops reading two answers. Is that how you handle it, and what do you name the retired file? Your answer replaces a general rule with your own procedure, which is a process fact the guides require from you.
- In the section "Change enters in one place," the draft says a client's change reaches you through the monthly recording rather than through a support ticket. Is that right, and what do clients usually do first when something changes? Your answer decides whether that passage stays as written.
- In the section "What this does not fix," the draft says a business that changes direction every few months will pay for it regardless of the system. Have you seen that, and what did you tell the owner? The post argues the point now, and one instance would let it report instead.
Change enters in one place
You raise your fee. You drop the service that never suited you. You narrow to one kind of client, because those are the engagements worth having.
Now your site describes a business you no longer run. So do the email sequences, the profiles, and the bios you sent to three podcast hosts. So do the last 40 blog posts.
The update starts with the documents the whole system writes from. The new fee goes into the services guide. The narrower client goes into the client profiles. Everything produced afterward derives from those two edits.
That is the whole mechanism. One edit point, and the assets follow.
Editing the asset first leaves the old answer in place
Say you change the homepage instead, because the homepage is what people see. The page now reads correctly and the guides still describe the old business.
Two weeks later, the system writes a launch email and three posts. Each one reasserts the old positioning. It is doing exactly what it was built to do, which is write from the guides.
So the order runs one way. The decision goes into the guides, the guides update the assets, and the homepage is one of the things downstream.
What moves in days, and what waits for you
Derived text moves first. Page copy, email sequences, profile bios, and service descriptions come out of the updated guides. So does everything published from now on. They change as fast as someone can review them.
Anything factual waits for you. A new price, a credential, a client result, a case study, a claim about what you deliver. The system can draft those sentences and it cannot verify them, so they publish after you confirm them.
A third group never updates itself. Printed material already in circulation. PDFs someone downloaded. Your bio on a conference site. A guest article on another firm's blog. A directory listing. Those live on other people's servers, and someone has to go and change them one at a time.
The reason change feels slow is the asset count
Bynder surveyed 1,002 marketers in 2023 and found that a typical rebrand touches 215 assets and runs about seven months. Updating those assets was the part marketers named as hardest.
Your practice is smaller than the companies in that survey, and the shape is the same. Change is slow in proportion to how many separate places hold a version of your positioning.
Deriving assets from one source shrinks the list of things anyone has to edit by hand.
That is the argument for the structure, and it is worth being exact about what it buys. It does not make the third group disappear. It makes the third group small enough to work through in an afternoon.
Update on change events, not on a calendar
A quarterly reminder to review your brand documents is a reminder most people dismiss. What works is tying the review to the event that made it necessary. That is how teams keep documentation from going stale.
The events are easy to name in a small firm. You change a price. You add or retire a service. You take a client in a new field. You win a result worth telling. You change your mind about something you have said in public for years.
In my engagements, those arrive in the monthly recording. The client talks for an hour about what happened that month. The new material goes into the guides. The assets that depend on it get revised.
Old versions have to leave
One rule does more work than the rest. When a guide changes, the old version comes out of the system.
A project reading two versions of your services guide has no way to know which one is current. It will use whichever it finds, and half the time that is the retired answer. The same failure happens with people. Standard advice in shared documentation is to edit at the source, never a private copy.
So the current file keeps its name, and the retired one gets renamed and moved out of the system's reach. It stays available for reference and it stops being read as fact.
What this does not fix
The guides are current as of your last conversation. The system does not know your business changed until you say so. A change you never mention keeps producing accurate work about a business you have left.
It does not decide anything for you. The system can tell you that a new fee touches 14 pages, and the fee is still your call.
And it does not turn a repositioning into an update. Moving from one market to another means new capture and mostly new guides. Those decisions belong to a rebrand rather than a revision. The structure makes that project cheaper. It does not make it small.
There is also a limit worth naming for its own sake. A business that changes direction every few months will feel the cost anyway. Each change asks the audience to relearn who you are.
One place the change lands first
A moving business stays coherent when a change has one place to land. Everything else sits downstream of that place.
So when you raise your fee on a Tuesday, the fee page is not where the work starts. The number goes into the guide first. Then the pages, the sequences, and the next three months of writing say the new number. That is where they read it.
