The training session after a website goes live
- 2 days ago
- 3 min read
Introduction
A website launches, the client is delighted, and a fortnight later they message asking how to change a phone number. A month after that the site has an out-of-date opening time, no new content and a blog with one post from launch week.
The build was fine. Nobody ever taught them to use it, or somebody did it in a rushed forty minutes covering everything at once, which amounts to the same thing. A client who cannot edit their own site gets less value from it, blames the site, and eventually rebuilds it somewhere else. The training is what prevents all of that.
1. The training session after a website goes live should be planned, not squeezed in
Treat it as a deliverable with a date, not a favour at the end. Put it in the proposal.
Book it as a separate appointment
Not on launch day. Launch day is full of adrenaline and last-minute checks, and nothing said then gets retained. A week later works far better.
Have the right person in the room
Whoever will actually update the site, not only whoever commissioned it. Training the wrong person is the same as not training anybody. Ask who it will be early.
2. Teach the tasks they will actually do
Not the whole content management system. Most of it they will never touch.
Start with their five real jobs
Change text, swap an image, add a page, publish a post, update opening hours. Five tasks done confidently beats a tour of every menu. Ask them which five they need.
Let them do it, not watch you do it
Hands on the keyboard. Somebody who has made the edit themselves once will do it again; somebody who watched will not. Sit back and let them struggle briefly.
3. Leave something they can refer back to
Nobody remembers a session a month later. Assume they will forget everything.
Record the session
A screen recording of the actual site is more useful than any written guide, and it costs nothing to make while you talk. Send them the file to keep.
Write a short cheat sheet
One page, five tasks, in order. Long documentation goes unread; a single page gets pinned up. Use screenshots of their own site.
4. Cover the things that go wrong
Confidence comes from knowing the recovery.
What to do if something breaks
Who to ring, what not to touch, how to undo a mistake. Clients avoid editing mainly out of fear of breaking something. Show them the revision history.
Logins, passwords and access
Make sure they own the accounts, the domain and the hosting. A client who does not control their own domain discovers it at the worst possible moment. Hand over every credential.
5. Explain what needs doing regularly
A site is not finished at launch.
Updates, backups, security and who does them
Say plainly what is your job and what is theirs. Ambiguity here is how sites end up two years out of date. Put it in writing.
Point at the next useful thing
Content, reviews, analytics, page speed. Ending the session with a suggestion turns a handover into the start of ongoing work.
Conclusion
Clients who cannot edit their own site get less from it, blame the site, and eventually rebuild elsewhere. So book training as a separate appointment rather than squeezing it into launch day, and make sure the person who will actually make the updates is present.
Teach their five real tasks — text, images, a page, a post, opening hours — and put their hands on the keyboard rather than demonstrating. Record the session and leave a one-page cheat sheet, because nobody remembers a month later. Cover what to do when something breaks, confirm they own the domain, hosting and accounts, and state plainly which ongoing jobs are yours and which are theirs.
.png)



Comments