How to Empower Clients to Use Their Website (and Client-Proof Them at the Same Time)

Speaker Introduction

Michelle Frechette introduced herself as a self-described "Jill of all trades" within the WordPress ecosystem. Her background spans direct contributions to WordPress core, involvement in sub-teams including the photography team and marketing teams, extensive podcasting, and community leadership. At the time of this session she held the role of executive director at Post Status and was also working with WP Includes Me. Beyond that, she runs a marketing boutique through her personal website and does marketing consulting independently.

She has also written a book titled "A Good Firm Handshake and Other Essential Business Tips," which covers topics including how to qualify clients, a subject she referenced briefly in the session to provide context for why not every client is worth taking on in the first place. 01 02 03 04 05 06 07 08 09

The Core Problem: Clients with Website Access

Michelle framed the central tension cleanly. Once a website is built and handed over, the client has a right to access it. They own the hosting. They own the site. But that access, combined with varying levels of technical competence, creates real risk for the work the developer has done.

She noted that clients span an enormous range of technical ability. Some people can log into WordPress for the first time and figure it out within an hour. Others struggle to operate a smartphone. The challenge for developers is identifying who within a client organisation needs access, what level of access they actually need, and how to protect the site from well-intentioned but damaging interference.

Step 1: Assessing User Levels

Matching Role to Task Michelle's first principle is to never assign access beyond what the client actually needs to do. WordPress offers a range of user roles, from subscriber and author through to editor, and at the top, administrator. Each role unlocks different capabilities.

She gave the example of someone who wants to write blog posts for a company website.

That person does not need admin access. Author or editor access is sufficient. Editor access is appropriate if they will also be managing or approving content from others. Admin access should only be given when it is genuinely necessary.

Questions to Ask Before Assigning Roles Michelle recommended walking through a specific set of questions before setting any user up: What does the client want to be able to do?

What do they actually need to be able to do?

Are you still going to be involved in maintaining the site, or are you fully handing it off?

Who in the organisation will need access, and what will each person be doing?

She gave a pointed example: for an HVAC company, a field service technician probably does not need website access at all. He might need to receive emails that originate from the website's contact form, but that is very different from having a login to the back end.

Fine-Tuning with Plugins Beyond WordPress's built-in roles, Michelle noted that user role management plugins allow developers to fine-tune permissions further. These tools can restrict access to specific areas

of the dashboard even for users who nominally hold a certain role, giving developers a more precise level of control.

Step 2: Making Clients Understand the Stakes

What Can Go Wrong Michelle was straightforward about the kinds of damage clients can do. They can: Delete or overwrite content Restore old backups, inadvertently rolling back work that was done after that backup point Accidentally revert pages or posts to earlier versions using the revision history feature Break live pages in real time because they forget, or never understood, that changes are applied immediately when they hit "Update"

She acknowledged that the white screen of death is less common now than it once was, but noted that plugin conflict errors that produce strings of text across the top of a page are still very much a reality, and clients will not know what to do with them.

Explaining Sensitive Areas She recommended explicitly telling clients which areas of the admin they should not enter, even if they have the access to do so. Examples include the theme editor, the plugin editor, and certain settings panels. Anyone who thinks they understand technology is likely to poke around in those areas out of curiosity, and that curiosity can cause real damage.

The Plugin Accumulation Problem Michelle told a story about a church client whose young pastor was given admin access.

When she logged back into the site about three weeks later, there were five weather and clock plugins installed. Leaving aside that a local church has little practical use for even one, having five plugins doing the same thing creates unnecessary bloat and potential conflicts.

She used the story to illustrate that even seemingly harmless plugin installations can cause problems, and clients need to understand that.

Step 3: Financial Consequences as a Teaching Tool

Michelle was emphatic that money is the most effective motivator for responsible client behaviour. When abstract warnings about "breaking" a website fail to land, a clear price tag for fixing mistakes tends to get attention.

Her formula: charge triple your standard hourly rate to fix errors the client caused. Not double. Triple. Her reasoning is practical. Being called in to fix a client-caused problem

disrupts your entire day. The emotional cost, the context-switching, the urgency, and the actual repair time all combine to make it far more disruptive than standard billable work.

Charging triple reflects that reality and also, she noted, scares clients into leaving things alone.

She framed this as a feature rather than a threat. If the pricing is high enough, clients may prefer to simply let the developer handle all changes, which is often a better outcome for the quality of the site anyway.

Being called in to fix a client-caused problem disrupts your entire day.

Step 4: Delivering Training That Actually Works

Require Full Attention Michelle was insistent on one ground rule for training sessions: no interruptions. Phones off.

Email closed. No colleagues wandering in. She described the experience of trying to teach someone who is simultaneously answering calls and checking messages as essentially futile.

Nothing sinks in under those conditions.

Teach Only What They Need to Know A common mistake is showing clients everything out of a desire to be thorough. Michelle argues for the opposite approach. If someone is only ever going to write blog posts, teach them only how to write blog posts. Show them how to use the relevant blocks in Gutenberg, how to insert images, how to work within whatever theme is in place. Do not walk them through settings panels or plugin menus they will never need and should never touch.

Structure: Two to Three One-Hour Sessions Rather than a single long session, Michelle structures client training across two to three one-hour meetings. She finds that around the one-hour mark, people begin to lose focus.

They start thinking about lunch, their missed calls, their inbox. Breaking the training into shorter sessions with time between them allows clients to absorb what they have learned, practice in a sandbox environment, and come back with genuine questions.

She mentioned WordPress Studio as a useful tool for giving clients a safe environment to practise without touching the live site.

Build on Previous Sessions At the start of each session, Michelle briefly recaps what was covered in the previous one.

She makes explicit the connection between what was learned before and what is being

introduced now. This layered approach helps clients build a mental model of the system rather than accumulating isolated facts.

Answer Questions Honestly, with Warnings When clients ask "what happens if I do this?", Michelle answers truthfully. She explains the likely outcome and any risks. This includes being direct about what plugin installations can do, why editing certain files is dangerous, and what "publishing" versus "saving as a draft"

actually means in terms of visibility.

Step 5: Creating Reference Materials

The FAQ Sheet Michelle described a simple FAQ sheet she puts together for clients. It begins with the words "don't panic" at the top, which she noted is intentionally reassuring. The sheet covers: What plugins are installed and what each one does Basic editing instructions How to add a form Basic SEO steps for filling out the relevant fields in their SEO plugin when writing posts How to back up the site before making any changes The importance of keeping the site updated How to view and use page and post revisions She recommends giving clients something they can print out and pin up at their desk, or file away and retrieve when they need it. A plain document beats an email buried in an inbox.

Recommended External Resources Michelle put together a list of resources she points clients toward for self-directed learning: W3Schools for CSS basics and other reference material WP Beginner as a general WordPress learning resource WP101 for structured WordPress tutorials (also available as a plugin, see below) LinkedIn Learning for structured courses Udemy for affordable video courses YouTube for free tutorials on virtually any specific task She also encouraged developers to suggest that clients attend local WordPress meetups (findable on meetup.com and events.wordpress.org) and, where possible, WordCamps. She sees community events as a meaningful supplement to developer-led instruction.

Her advice to developers: pre-curate the list. Find specific courses or channels that are appropriate for the client's level, not too long, not too advanced, and recommend those specifically rather than sending people to search for themselves.

Step 6: Recommended Plugins

Michelle named a handful of plugins she considers standard equipment for client-proofed sites: User role management plugins to fine-tune dashboard permissions beyond what WordPress's default roles allow Backup plugin automation (she stressed not relying solely on hosting company backups, but having a dedicated plugin-level backup in place as well) WP Rollback (free, available in the repository): allows rolling back a plugin or theme to an earlier version if an update causes a problem. She sees this as especially useful when clients update something and break the site.

WP101: a plugin that places visual tutorial content inside the WordPress dashboard, allowing clients to watch short instructional videos without leaving the admin interface

Step 7: Contracts and Boundaries

Scope of Work Must Be Explicit Michelle was clear that contracts need to define not only what is included in a monthly maintenance fee but also what is not. She recommended adding a section to every contract that explicitly lists exclusions and the hourly rate that would apply if the client requests them.

Examples of things that should be in the contract:

• What routine updates and changes are covered in the monthly fee
• Whether blog post updates, hour changes, and minor content edits are included
• What falls outside the scope
• The rate for out-of-scope work
• The rate for fixing client-caused errors (which, as noted, she recommends setting at triple the standard rate) Do Not Take Pity She was candid about a mistake she made repeatedly early in her career: discounting fees or offering concessions for clients who seemed to need it. She found consistently that the clients she gave the most ground to financially were the ones who needed the most support afterward, creating a situation where she was doing more work for less money. Her advice is simple: hold the line on pricing from the start.

Red Flag Clients When asked by the host how to spot a client who is going to be difficult before the relationship even starts, Michelle noted that some clients reveal themselves early. She described receiving a call from a prospective client who responded to her starting price by swearing at her. Her response was to calmly note that they were clearly not a match and end the conversation. She did not attempt to negotiate or apologise. She considers that the right approach.

Their Emergency Is Not Your Emergency Michelle was firm on this point. Client problems, even urgent ones, are not automatically the developer's problem to solve at the client's timeline. She sets and communicates her own contact hours clearly. Clients can email her at any hour if the site goes down at 3 a.m., but they cannot call, text, or message her through social platforms. And in any case, she will respond during her working hours, not theirs.

She acknowledged that a site being offline for a couple of hours is not catastrophic for most clients, and normalising that helps set realistic expectations from the start.

She also pointed to a recent personal example. During a family medical crisis, she had to reschedule client meetings. She did so directly, offered to suggest alternative service providers if the timeline was urgent, and did not apologise for having a life outside of client work.

Fixing Mistakes as a Revenue Opportunity Michelle offered a reframe that is worth noting. When a client makes an expensive mistake that requires emergency repair work, that income is legitimate. She referenced the old joke about orthodontists paying for ski trips with braces money. She encouraged developers to think of high-value emergency repair fees the same way: a client's mistake, billed at triple rate, might be the equivalent of a nice dinner out. It is not guilt money; it is earned money.

Time Management and Calendar Discipline

In response to a question from the host about managing time across multiple projects, speaking engagements, travel, writing, and community work, Michelle described her calendar system.

She blocks Tuesdays and Friday afternoons completely. No client meetings are scheduled on those days. That time might be used for photography, for focused building work, for writing, or for whatever the week demands. The key is that those windows are protected without exception.

For the days that are open for meetings, Monday, Wednesday, Thursday, and Friday morning, clients book into available slots through a shared calendar. They choose from her availability; they do not propose times and expect her to accommodate them.

She also addressed the concept of setting expectations around turnaround time. When a client asks for something to be added to the site, she tells them when her calendar permits it to be done. If they need it sooner, she offers the option of subcontracting it at a higher cost. The point is that her schedule drives her commitments, not client urgency.

Personal Story: The WordCamp Montreal Incident

Michelle shared the most dramatic client crisis of her career in response to Andrew's question about the worst middle-of-the-night emergency she had ever dealt with.

She was driving to WordCamp Montreal when a hosting issue took down every single one of her client sites simultaneously. She had multiple sites hosted under the same folder structure with the same host, and the server was found to be sending spam. The hosting company shut everything down. She had no way to fix it while driving. When she arrived in Montreal, she went to the speaker dinner and then spent the entire night cleaning up and restoring every site before she delivered her talk the following morning.

She described it as her worst web crisis and noted that she had since learned to separate client hosting environments. She also offered it as a direct cautionary example for clients: even if neither the developer nor the client does anything wrong, things can go wrong due to factors outside everyone's control, and knowing who to call and what to do matters.

Quotes Worth Noting

Michelle cited Will Rogers: "Good fences make good neighbors." She uses it as a framing device when discussing client boundaries. The parallel is direct: clear, well-defined limits in professional relationships create better outcomes for both parties.

About the speaker Michelle Frechette Director of Community Engagement, StellarWP

Michelle Frechette is Director of Community Engagement at StellarWP. She has spent years helping agencies think through client training, handoff, and support boundaries.