Keep every website change request on one shared list: what is asked, who asked, what was decided and when it was done. Agree who can approve changes, and let the email thread go.

The thread nobody can follow

It starts with one line: please update the hours on the website. Someone replies with a correction. Someone else forwards it to a colleague, who adds a request for a new photo at the bottom.

Three weeks later the subject line still says hours, and the thread holds a staff change, a question about the contact form and two versions of the same paragraph.

Whoever does the work reads it top to bottom and tries to work out what was decided. Often they guess right. Sometimes they do both versions.

Nobody did anything wrong. Email is simply a poor place to keep a list.

How requests go missing

The fourth causes the quietest mistakes. The wrong photo or last year's price list goes up, it looks finished, and nobody notices until a customer quotes it back to you.

What it costs

Each missed request means another email, another round of work and often another line on an invoice, since reading a long thread is time the web company has to spend.

Requests done twice are worse. The header says one thing and the contact page another, and customers act on whichever they read first.

And the people asking start to feel unheard, so they ask more loudly, copy more people and make the thread longer.

One list instead of the thread

The fix is a single list of requests that everyone involved can see. A shared spreadsheet works; so does the request system your web company may already use.

Each request gets one line: the date, who asked, the page, exactly what should change, what was decided, when it went live and who checked it.

Email can still announce a new request. The list is the record, and when the two disagree, the list wins.

Keep finished lines rather than deleting them. A year later, the list is the only reliable record of when a price, a policy or a staff page changed.

Who asks and who decides

Most contradictions come from several people giving instructions directly. Agree that one person, or two at most, approves changes before they go to whoever makes them.

Everyone else sends requests to that person. The web company acts on approved lines and asks the approver when something is unclear.

This is not bureaucracy. It is the difference between one decision and three competing ones.

A worked example

A walk-in clinic in a suburban strip mall has a dozen physicians on rotating shifts, a clinic manager and an owner who is also one of the doctors.

Its hours change with the seasons and the staffing, so the website needs updating several times a year.

One summer the manager emailed the web company to change the Saturday hours. A few days later the owner replied to an older thread with different Saturday hours, starting in August.

The web company did both. The header showed one set of hours and the contact page the other, and patients began arriving before the clinic opened.

Each request had gone into a different branch of the conversation, so neither sender saw the other's, and the web company read both as instructions.

The clinic now keeps a shared list. The manager is the only person who approves website changes, hours are always given with a start date and an end date, and the web company marks each line when it is done.

The manager checks every change on her phone before closing the line.

A request that can be done once

A good request names the page, quotes the old wording and gives the new, and says when it should go live. A temporary change also says when it should come off.

Compare a request to change the hours with this one: on the contact page and in the header, change Saturday to 10 a.m. to 4 p.m., from August 6 until the end of September.

Attach final files only, named for what they are. A photo called final-final-2 is a guess waiting to happen.

Closing the loop

A change is not finished until someone who asked for it has seen it on the live site, on a phone and on a computer.

Mark each line with the date it went live and the date it was checked. A line marked done but never checked is still open.

For seasonal notices and temporary hours, put the removal date in the calendar when the change goes up. Holiday hours still online in March are a common sight.

A short weekly note from the web company listing what went live closes the loop for everyone at once, including the people who asked.

Where your web company fits

A good web company will welcome the list, because it turns guesswork into clear instructions and makes its own invoices easier to explain.

Ask how it prefers to receive requests. Many have a ticket system or a request form; if yours does, the list can simply be that.

Larger requests deserve a short written estimate before work starts, recorded on the same line, so nobody is surprised later.

The counter-case

A business that changes its website twice a year, with one person emailing one person, does not need a system. A clear subject line and a short message will do.

Urgent problems, such as a wrong phone number, should be phoned through rather than queued. Add the line to the list afterwards.

But once more than one person asks for changes, or there are more than a few a month, one list beats any thread.

One place for requests

  1. Start a shared list with seven columns.
  2. Copy open requests out of current threads.
  3. Name one person who approves changes.
  4. Write one request per line.
  5. Give the page, wording and dates each time.
  6. Record when each change went live.
  7. Check it on the live site before closing.

Step three is the one that prevents contradictions. A list keeps requests from getting lost, but only a single approver stops two people asking for opposite things.

Deciding when a whole project counts as done is covered in agreeing on what finished means.

Frequently asked questions

Why do email threads lose website requests?

Replies branch off older messages, new requests hide under old subject lines, and decisions made by phone never get written down, so whoever does the work has to guess.

What should the request list include?

One line per request: the date, who asked, the page, exactly what should change, what was decided, when it went live and who checked it.

Who should be allowed to request changes?

Anyone can suggest one, but one person, or two at most, should approve changes before they reach whoever makes them. That prevents contradictory instructions.

What makes a good change request?

It names the page, quotes the old wording and the new, gives the date it should go live and, for a temporary change, the date it should come off.

When is a change actually finished?

When someone who asked for it has seen it on the live site, on a phone and a computer, and the line on the list has been marked checked.

Do small businesses really need this?

Not if one person emails one person twice a year. Once several people ask for changes, or there are more than a few a month, a single list helps.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Website changes lost in long threads?

Send us the thread. We will turn it into one list of what is open, what is done and what is undecided.

Start a Conversation