Content updates: do it yourself, or send them to your partner?
Which content changes a business should make itself, which should go through the partner, and how a preview-based process makes both safe.
The short answer
Content changes split into two kinds, and the tooling should make the split obvious. Changes to text, images, articles, prices, hours and other content within existing templates belong with the business, made through an editing interface with a preview, published or sent for review, and versioned so anything can be undone. Changes to structure, new templates, layout, integrations or anything touching code belong with the partner through the normal change process with previews and rollback. A good setup makes the first kind easy and safe for a non-technical editor and makes the second kind impossible to do by accident. Both paths go through previews and version control, so nothing is published unseen.
Who does what
| Change | Who | How |
|---|---|---|
| Text and images on existing pages | Business | Editing interface; preview; publish or request review |
| New article or news item within the template | Business | Same, with the article fields |
| Prices, hours, contact details, team members | Business | Structured fields; preview; publish |
| New page of an existing type | Business or partner | Editing interface if the type exists; partner if it does not |
| New page type or template | Partner | Change process; preview; deploy |
| Navigation and structure changes | Partner, with the business | Change process |
| Forms, integrations, tracking | Partner | Change process; tested end to end |
| Anything touching layout, styling or code | Partner | Change process |
| Legal and policy pages | Business writes; partner publishes if structure is involved | Review before publish |
Setting the business up to edit safely
- Structured content types for the things the business changes often: pages, articles, team, locations, products, with fields, not free layout.
- An editing interface the team learns in an hour: fields, preview, publish or request review.
- Previews for every change, on a phone, before publishing.
- Version history, so any edit can be reverted.
- Roles: who may publish directly and who requests review.
- A short guide with examples for the team, kept with the setup document.
- The change process for everything else, with a change budget so it is never a surprise.
Where the partner adds value on content
Not by typing your text, which costs more through a ticket than through the editor, but by building the content types that make editing safe, by reviewing when asked, by producing the images and structured data that content needs, by writing when the business wants that, and by keeping the whole thing fast and indexed as content grows. The partner’s job is the system in which the business edits, and the changes the system should not allow.
What this means for you
Make routine content changes yourself, through structured fields with previews and history, and send structural changes to the partner through the change process. Insist on tooling that makes the first easy and the second impossible by accident. The business gets speed on the changes it makes daily, the partner gets the changes that need care, and nothing reaches visitors without having been seen.
Frequently asked questions
Do we need to learn a content system?
A good editing interface is a form with a preview: fields for the content, a button to see the result, a button to publish or to request a review. Most people learn it in an hour. What you do not need to learn is anything about layout, code or deployment, because the interface does not expose them.
What if we break something while editing?
In a proper setup you cannot break the layout, because the editor exposes content fields, not templates. A wrong word or image is corrected in the next edit or reverted from the history, because every change is versioned. If editing can break the site, the setup is wrong, not the editor.
Is it cheaper to do updates ourselves?
For routine content, yes, and faster: a price change or a new article should not wait for a ticket. For anything structural it is more expensive to do yourself, because it goes wrong and then needs the partner anyway. The split is by kind of change, not by cost, and a change budget covers the partner's side without surprises.