Website change requests: who decides, and how a weekly update slot keeps the site calm

A company website changes more often than most people think. A new price, a changed phone number, a team member who left, a new case description, a sentence that sales does not like any more. The requests come from everywhere: an email to the person who "does the website", a message in a chat, a remark at the end of a meeting.

The result is familiar. Some changes are done twice, some never, and some contradict each other. The person who maintains the site becomes a bottleneck, and the people who ask do not know whether their request was seen. This article describes a simple setup that avoids it: one intake place, one owner per page group and one weekly update slot.

Why requests get lost

Three things usually go wrong at the same time:

• No single entry point. A request in a private chat is invisible to everyone else.
• No decision rule. When sales wants one wording and the founder another, the one who asks last or loudest wins.
• No rhythm. Changes go live whenever someone has a spare hour, so the site is edited at random moments, sometimes just before a customer meeting.

None of this needs a tool. It needs three small agreements.

Step 1: one place for requests

Choose one place and say clearly that nothing else counts. It can be a shared form, a shared mailbox such as web@yourcompany.com, or a board in the tool you already use for tasks. What matters is that everyone can find it and that the maintainer sees every request there.

Ask each request to contain four things:

1. The page: the link or the name of the page.
2. The change: the exact new text, number or image, not "please update the prices".
3. The reason: for example a new price list or a legal change.
4. Who asks: so there is someone to answer.

A request that lacks the new text goes back to the sender. This sounds strict, but it saves the maintainer far more time than it costs the sender.

If you already handle change requests for internal software, you can reuse the same rule; see handling change requests after launch.

Step 2: one owner for each group of pages

Divide the website into a few groups and give each group one owner. Three to five groups are enough for most small companies:

The owner does not write the change. The owner says yes, no or "later", and that answer is final. When a request touches two groups, the owner of the more sensitive group decides, and the other one is informed.

Write the table on one page and put it next to the intake place. It also helps new colleagues who wonder whom to ask.

Step 3: one weekly update slot

Pick one fixed time per week, for example Tuesday at 10:00, when approved changes go live. The maintainer collects what the owners approved since last week and publishes it in one go. A slot of one hour is enough for small sites.

The benefits are practical:

• The site is not touched on Friday afternoon or just before a customer call.
• Related changes, such as a new price and the matching offer text, go live together.
• Requesters know when to expect their change, which cuts the follow-up questions.
• Checking the result is easy: one person reads through the changed pages after publishing.

Keep a short list of what may be published outside the slot. A typical list has only three items: a wrong phone number or address, a legal or safety correction, and an error that blocks customers, such as a broken contact form. Everything else waits for the slot. If the list grows long, the slot has no meaning.

A simple weekly rhythm

• Any day: requests arrive in the intake place.
• Monday: owners look at new requests in their group and answer yes, no or later.
• Tuesday, the slot: the maintainer publishes the approved changes and checks the pages.
• Tuesday afternoon: the requesters get a short note that their change is live.

For small companies the Monday review can be ten minutes by email. It does not need a meeting.

Check after publishing

After each slot, open every changed page once. Look at the text, the links, the phone numbers and how the page looks on a phone. Keep a simple log, one line per change with date, page and requester. A log is useful when someone asks "when did the price change?", and it shows how many requests really arrive. The same habit works for product updates; see release notes for an internal tool.

Common mistakes

• Too many owners. If every page has a different owner, nobody sees the whole picture. Start with a few groups.
• No answer to rejected requests. "No" is fine, silence is not. Send one sentence with the reason.
• Skipping the slot for "just this one". One exception is a favour, three exceptions are the new habit.
• Requests without new text. The maintainer then writes the text, and the owner has nothing to approve.
• Never cleaning up. Once a month, close requests nobody has touched for weeks.

How to start this week

1. Choose the intake place and tell everyone by email.
2. Write the page groups and owners on one page and get each owner to confirm.
3. Set the weekly slot and put it in the calendar of the maintainer and the owners.
4. Write the short list of urgent exceptions.
5. After one month, look at the log: how many requests, how many rejected, how long a change waited.

Changes to how people work also need a little care in communication; the article on change management and technology adoption covers that side.

Summary

Website changes stay under control when there is one place to ask, one owner per page group and one weekly slot to publish. Ask for the page, the exact new text and the reason, answer every request, and keep the exceptions list short. After a month you will know how much change your site really needs.

Sources

• Our related articles linked above.
• The approach described here is common practice for small and mid-sized companies, used as a practical guide. No client results or market figures are claimed in this article.