Maintenance is too small a word
Many website maintenance plans are just lists of automatic updates. They promise to install new versions of WordPress, themes, and plugins, then send a report. That work matters, but it doesn't answer the question most organizations actually have: who takes care of the website?
A managed website still needs content changes, help publishing, form checks, accessibility fixes, diagnosis when something breaks, coordination with vendors, and review before releases. It also needs someone to handle the next request that nobody could predict when the contract was signed.
Website management means someone owns all of that work on an ongoing basis. Software maintenance is one part of it.
What the agreement should cover
Your agreement should make the recurring work easy to find. Look for each of these:
- Content and page changes requested by authorized staff.
- Routine WordPress, theme, and extension maintenance.
- Monitoring for availability, security regressions, and visible failures.
- Diagnosis across the site, hosting platform, forms, and connected services.
- Accessible implementation and correction within the agreed scope.
- Staging, release checks, backups, and written records of completed work.
- Coordination with hosting and software vendors when a problem crosses systems.
Response time is not completion time
A response target says when the web team will acknowledge your request and start looking at it. It doesn't promise that every request will be finished within that many hours.
That distinction protects both sides. A typo can often be fixed right away. A broken integration may need evidence, vendor support, credentials, testing, and a safe release. Pretending those jobs share one guaranteed completion time rewards rushed work and vague excuses.
The agreement should state the response target, business hours, what counts as an emergency, and how the team will give you an estimate once it understands the request.
Tasks and projects need a visible boundary
Routine management works well for small changes that fit the existing site and go through the normal request process. Rebuilds, new integrations, migrations, and major new features need their own scope, schedule, price, and acceptance criteria.
You shouldn't learn where the boundary is from a surprise invoice. When a request is bigger than routine management, the web team should explain why, describe the next step, and send a fixed proposal before any project work begins.
Management should leave a record
You shouldn't have to piece together your website's history from old email threads. Requests, decisions, completed changes, monitoring results, and open dependencies should stay visible to your authorized staff.
That record makes handoffs safer and oversight easier. Instead of relying on whether somebody remembers doing the work, you can see what was requested, what changed, when it changed, and what still needs attention.
Nine questions for an incumbent vendor
You can judge your current arrangement without reading any code. Ask these questions and look for specific answers.
- Who can publish an urgent correction?
- Who watches for failures and security regressions?
- Who owns the hosting, domain, and service accounts?
- Does every person use an individual account?
- Where are consequential changes tested?
- How are requests and completed changes recorded?
- What work is included in the monthly fee?
- What turns a task into a separately quoted project?
- Who coordinates the response when the source of a failure is unclear?
Leland Fiegel