4 August 2026

Training a non-technical client on a CMS in ten minutes

The handover decides whether a CMS pays for itself or becomes a support channel. What to demo, what to hide, what to write down, and the measure that tells you your setup is wrong.

You have built the site, configured the CMS, and now you have twenty minutes with the client to show them how to use it. Whether that CMS pays for itself or turns into a recurring support channel is decided almost entirely in those twenty minutes.

Most developers use them badly, and predictably. This is what works instead, from doing it repeatedly with people who do not think about websites.

The mistake almost everyone makes

The instinctive handover is a tour: here is the dashboard, here are your collections, here is the media library, here are the settings, here is where you publish.

The client nods throughout and remembers none of it. Not because they were not paying attention, but because a tour is organised around the tool’s structure rather than around anything they want to do. Nothing attaches to a goal, so nothing sticks.

Three weeks later they need to change a price, cannot remember which of the six things you showed them contains prices, and email you instead. You have now paid for the CMS and kept the support load.

What works: do their actual job, in front of them

Before the meeting, ask one question: what will you change most often?

The answer is always concrete and always small. Prices. Opening hours. The photo on the home page. A new item on the menu. That answer is your entire agenda.

Then, in the session:

1. Do that task yourself, slowly, narrating. “You want to change the price of this service. Click here, this field, type, click Publish.” Thirty seconds.
2. Do it again, in silence, so they see the shape without commentary.
3. Hand over the mouse and have them do it, on a real page, with a real change you revert afterwards. This is the only part that matters. Watching someone do it once is the difference between remembering and not.
4. Show them what “published” looks like, including the wait. Sit through the minute or two with them so the first time they experience it is not alone and worried.
5. Show them how to undo. For most clients this is the single most reassuring thing in the session. People edit timidly when they believe mistakes are permanent, and confidently when they know they are not.

That is ten minutes. Everything else is optional.

What to deliberately not show them

The settings. If they can reach settings, one of them eventually will. Anything structural should be behind a role they do not have. This is not distrust: it is the same reason we do not give ourselves production database access by default.

The media library as a destination. Show uploading a photo inside the task that needs a photo. A media library visited on its own is a place to accidentally delete something.

Anything they will use less than twice a year. It will not be remembered, and mentioning it dilutes the five things that matter.

Your admiration for the architecture. They do not care that content is fetched at build time. They care that their prices are right.

The one-page note

Leave something written, on one page, in their language, with screenshots. Not a manual: a reminder.

What it should contain:

• The address to log in, and how to get a new password.
• The three tasks they will actually do, one screenshot each.
• What Publish does and roughly how long it takes.
• How to undo.
• Who to contact and what to include in the message.

What it should not contain: everything else. A twelve-page manual is read by nobody and signals that the tool is complicated.

If your CMS has decent end-user documentation, link to it rather than rewriting it, and keep your page to the parts specific to their site.

The measure that tells you your setup is wrong

Here is a rule worth adopting: if a client is stuck for more than ten minutes on a routine edit, that is a bug in your configuration, not a training failure.

Every time we have investigated one of those, the cause was on our side:

• A field labelled with an internal name instead of what the client calls it. hero_subtitle means nothing to a florist.
• A required field they had no way of knowing was required until publishing failed.
• Two similar collections with no obvious difference between them.
• A photo that looked wrong because the crop was centred and their subject was not.

None of those are the client being slow. All of them are fixable in the schema, and the fix takes minutes. Treat the ten-minute mark as a signal to change your setup rather than to explain harder.

Labels are the highest-leverage thing you will do

The single biggest determinant of whether a client can use a CMS is whether the fields are named in their vocabulary.

Not subtitle but “Sentence under the title”. Not excerpt but “Short summary shown on the list page”. Not cta_label but “Text on the button”.

Help text matters just as much: one line under the field saying where it appears. “Shown on the cards on the services page” removes an entire category of question, because the client’s real uncertainty is usually not how to type, it is where this text will end up.

This costs ten minutes when you write the schema and saves hours over the life of the site. It is the cheapest investment in the whole project, and it is the one most often skipped because the developer knows what excerpt means.

Setting expectations about publishing

One thing genuinely surprises clients on a static site, and it is worth saying out loud rather than letting them discover it: there is a short delay between publishing and the page being live.

Say it plainly: “When you click Publish, the site rebuilds. It takes a minute or two, and the screen tells you when it is really online. If you refresh your site immediately you may still see the old version.”

Clients accept this completely when told in advance. When they find out alone, at 8pm, with a customer waiting, they conclude the tool is broken and call you.

The corollary is that your CMS should actually show that state. A tool that says “published” the instant it saves is setting your client up to believe something false.

The follow-up that costs you nothing

Two weeks later, send one message: “Have you had a chance to change anything? Anything unclear?”

Most say yes and fine. The ones who say “I did not dare” are telling you something important, and it is nearly always fixable: an unclear label, a fear of breaking the site, or nobody having shown them how to undo.

That single message is the cheapest support you will ever provide, and it converts the CMS from a thing you sold them into a thing they use.

Handing over to a client who did not choose the tool

A specific and common case: the client did not pick this CMS, you did, and they used something else before, usually WordPress.

They arrive with expectations shaped by that tool, and the two that cause friction are worth pre-empting.

“Where is the page builder?” They expect to drag blocks around. On a field-based CMS they cannot, and framing matters enormously here. The honest framing is not “this is simpler”, which sounds like less; it is “you cannot break the design, because the layout is fixed and you fill in the content”. Clients who have broken a WordPress layout once find that genuinely reassuring rather than limiting.

“Why can I not add a page?” On a brochure site with a designed structure, adding an arbitrary page is usually not something you want to be one click away. Explain that new pages are a small job you do together, not a self-service action, and that this is what keeps their site coherent. Almost nobody objects.

The general principle: describe every constraint as protecting something they care about, because that is what it does. A constraint explained as a missing feature reads as a downgrade; the same constraint explained as a guarantee reads as care.

Why any of this matters commercially

An agency’s real cost across a fleet is not the subscription. It is the stream of small interruptions: a forgotten password, a photo that will not upload, a change that “did not save”, a page that is not live because a build failed quietly.

Forty editors at one interruption per quarter is one hundred and sixty interruptions a year, each costing ten minutes and a context switch. That is several working weeks, and it is invisible on every comparison table.

Good field labels, a short written note, a real hands-on handover and a follow-up message cut that stream substantially. The tool matters less than most vendors would like you to believe, but the setup matters enormously, and the setup is entirely yours.

If you want the product side of the same argument, what a multi-site CMS needs covers the fleet economics, and our own help pages are written for the end client rather than for the developer, so you can hand them over as they are.