Defining an Ongoing WordPress Care Workflow

Challenge

The agency has built and now looks after many client websites. Care has grown informally. Updates happen when someone remembers, backups are assumed rather than checked, and clients send everything from typo fixes to new page requests through email and chat.

The result is predictable: small requests interrupt project work, larger changes get absorbed without being priced, and nobody is fully sure a site could be restored if an update went wrong.

Proposed approach

Define service coverage

A written definition of what care includes, for example core, theme and plugin updates, backups, uptime monitoring and a set amount of small content changes, and what it doesn’t.

Triage every request

Each incoming request is classified as maintenance, a small included change, a bug, or a change request that needs a quote. The agency sees the classification before work starts.

Backup and restore planning

Backups include both files and the database, are stored away from the website’s own server, and are kept for an agreed period. A restore is tested periodically, because an untested backup is an assumption.

Implementation considerations

• Update checks: updates run on a schedule, after a fresh backup, followed by a short check of key pages, forms and, where relevant, checkout.
• Held updates: major version changes and plugins with known conflicts are tested on staging first and held if needed.
• Access: each site’s access, hosting details and licences are recorded, with access granted per person rather than shared.
• Reporting: a regular report per site lists updates applied, items held and why, backup status and requests handled.
• Separating work: change requests outside coverage become a short quote, so new project work is planned and priced.

QA and handoff

For care, “handoff” is the regular report and the agency’s ability to answer a client’s question confidently. Each cycle would confirm:

• A backup completed before updates, and its location recorded
• Updates applied, with any held items explained
• Key pages, forms and checkout working after updates
• Requests classified, with change requests passed back for quoting
• Restore test completed on its agreed schedule

Expected benefits (not measured)

As a demonstration, these are intended outcomes, not results:

• Fewer interruptions to project work from routine care.
• Larger changes recognised and priced instead of absorbed.
• Greater confidence that a site can be recovered after a problem.

How success would be measured

• Share of requests correctly classified at triage.
• Number of change requests quoted that would previously have been absorbed.
• Restore tests completed and their outcome.
• Issues caused by updates, and how quickly each was resolved.

Constraints and lessons to consider

• Coverage only works if clients understand it. The agency may need to explain the change.
• Some hosting environments limit backup or staging options, which affects what can be offered.
• Very old or heavily customised sites may need a stabilisation project before routine care is practical.