Your cart is currently empty!
I’ve adopted a new Maintenance Agreement. This came about following several occasions where I suddenly found new Administrators and plugins on a site that I was maintaining. It’s come mostly from clients I hadn’t worked with for some time. Still, surprise!
I understand the reasons folks have for introducing new parties to help out. To name a few there’s new partnerships, marketing expansions, special deals they want to try, or just drumming up new ideas. Clients can find new designers, SEO helpers, assistants, or plugin vendors and end-up granting them full Administrator access without proper vetting. Some didn’t realize the effect this was having on my ongoing maintenance and support services. There’s a right way to go about it and a wrong way to go about it, and it’s really up to me to figure this out and give it the clarity that the situation demands.
I followed the advise of Nathan Ingram in his Fencing the Friendly Monsters series, on clarity, commitment, communication, and documentation. My solution is a new Maintenance Agreement that establishes a circuit breaker stopping all maintenance and limiting support whenever a non-vetted Administrator gets introduced or code is changed by anybody unfamiliar to me.
I’m always looking to keep things fair and high value, but I must also advocate for my needs as their chief technical support resource. I can’t control what clients do with their sites, but I can control my services. I need to know where I stand and I achieve it by clearly setting and enforcing boundaries. Here’s some further detail on how this works:
Sites that I’m in charge of
- I use the only full access Administrator account.
- Client and staff use Shop Manager (or lesser) user roles, plus they have a backup Administrator account.
- Myself and in some cases an automated service that I monitor maintains the site components.
- I provide a full level of support for the site.
- I approve or deny and collaborate with any third party developers they wish to bring in.
- I release all code or coordinate with third parties whenever they have code to release.
Sites that I’m not in charge of
- Client maintains their site or has a third party do it.
- Before any new development begins I conduct brief site evaluations to catch-up on changes since I had last worked on the site.
- Client or their responsible third party handles the releases or we closely coordinate them.
- This fits well with white-labeling services for other agencies where my work is more project based than ongoing.
Alternatively, I’ve heard of agencies disabling filesystem access in WordPress by setting DISALLOW_FILE_MODS=true to limit Administrator privilege with plugins and themes. They then lift the restriction during maintenance windows or use deploy tools to overcome. That seems like extra work and doesn’t necessarily guard areas where settings or code is stored in the database. I believe that managing roles is a better solution.
Share this:
Note: I may receive compensation for referrals.
