How to write a website care plan a small business will understand
What to put in a website care plan, the recurring revenue of a one-person AI agency: what's covered, what costs extra, a monthly routine and plain words.
Picture a florist whose new website goes live in spring. A month later she texts a new photo for the Mother's Day page. The next month she emails asking for a gift card shop. Then the contact form stops sending, and she assumes that's covered. Is it? Is the shop? Nobody wrote it down, so every answer turns into a small negotiation.
A website care plan settles those questions before they're asked. It's the monthly service you sell after the launch, and where recurring revenue for a one-person AI agency starts: you keep the site working, safe and up to date, and you make small changes when the business needs them. Written well, it gives the client a clear promise and gives you a clear line between "included" and "extra".
This guide shows what to put in one, in words a busy shop owner will read.
What should a website care plan include?
Start with the work that keeps the site running. The client can't see most of it, so name each part plainly.
- Updates. The site's software, and any add-ons it uses, updated on a schedule. WordPress's own documentation recommends backing up before an update so the site can be restored if something goes wrong. Put that order in your plan: backup first, then update.
- Backups. How often you take them, where they're kept, and how long you keep them. A backup nobody has ever restored is a hope, so say you test a restore now and then.
- Security certificate. The padlock in the browser comes from a certificate that expires and has to be renewed. Let's Encrypt, a free certificate provider, announced in December 2025 that it will shorten its certificates from 90 days to 45 days in stages by 2028. Automatic renewal handles this for most sites. Your plan should say you check it's working.
- A check that the site is up. A tool that tells you when the site stops loading, and what you do when it does.
- Forms and bookings. A monthly test that the contact form and any booking link still reach the business, done the same way as testing links and forms before handover. This is the failure clients notice last and mind most.
- Small content changes. A fixed amount each month. More on this below.
- Replies. How you can be reached, and how quickly you'll answer on a working day.
- A monthly note. Three or four lines on what you did, what you found, and anything the client needs to decide.
Then the harder half: what the plan doesn't include. Write that list too. New pages, new features, redesigns, online shops, copywriting, photography and paid advertising are common examples. A short "not included" list does more to keep the relationship friendly than any amount of fine print.
What counts as a small change?
This is where most care plans fall apart. "Small updates included" means one thing to you and another to a café owner with a new menu every season.
Define it by example, not by hours. Clients don't think in hours, and you'd have to track them.
| Usually a small change | Usually an extra, quoted first |
|---|---|
| Swap a photo or a price | A new page or section |
| Update opening hours or a phone number | A booking or payment system |
| Add a staff member to the team page | A new menu layout or design |
| Fix a typo or a broken link | Moving to a new host or domain |
| Add a seasonal notice to the home page | Anything that needs a new tool or account |
Then set a number: for example, up to four small changes a month, with unused ones not carried over. Pick a number you can keep in a busy month.
Opening hours deserve a special mention. When a business changes its hours for a holiday, customers often check Google before the website. Google Business Profile has a "special hours" setting for exactly this, and Google's help page suggests confirming hours even for official holidays when they don't change. If your plan covers the business's Google listing, say so, and add "check holiday hours" to your routine. If it doesn't, tell the client it's theirs to update.
How do you explain what's covered and what's extra?
Use the client's own requests. Before they sign, walk through three things they're likely to ask for in the next year and say where each one lands.
A family dentist might ask to add a new hygienist to the team page (covered), to put a notice up for the summer closure (covered), and to let patients pay online (extra, quoted first). Saying that out loud at the start is worth more than a paragraph of terms.
When a request arrives later, answer it the same way every time:
- Thank them and repeat the request in one line, so you both agree what it is.
- Say whether it's included in the plan or not.
- If it's included, say when it will be done.
- If it's extra, say you'll send a price before starting, and send it.
The fourth step is the one people skip. A "quick" extra done for free once becomes the expectation the next time.
How much should you charge for a care plan?
Price the plan from your own time and costs, not from someone else's price list. Published prices for care plans vary so widely that copying one tells you little about your own work.
Work it out in three lines:
- Your fixed costs per client: hosting if you include it, backup storage, any paid tools.
- Your time: the monthly routine, plus the small changes you've promised.
- A margin for the months when something breaks.
Then decide what you'll do when a client regularly uses more than the plan covers. A clear answer, such as "we'll move you to the larger plan or quote the extra work", saves an awkward conversation later.
A service recipe is a simple way to write each one down. Some designers offer two or three levels. That can work, as long as each level is described by what the client gets, not by the software you run.
What does a monthly care plan routine look like?
Keep it short enough that you'll do it every month, even in a bad week. Here's a routine you can adapt:
| When | What you do | What the client sees |
|---|---|---|
| First week | Backup, then updates; check the site loads afterwards | Nothing, unless something needed their decision |
| First week | Test the contact form and booking link | Nothing, unless it failed |
| Any time | Small changes as they arrive, against the monthly allowance | A reply confirming each one |
| Before holidays | Check holiday hours on the site and, if covered, the Google listing | Correct hours |
| Last week | Short monthly note: what you did, what you found, what they need to decide | One email |
Write the routine down once and keep it with the client's details, so the next month starts from the list, not from memory.
How do you write the care plan down?
One page is enough. The client should be able to read it on their phone between customers. Use these headings:
- What we look after: the site's address, and whether hosting is included.
- What we do every month: the routine above, in plain words.
- Small changes: the number per month and three examples.
- Not included: your list, with "quoted first" beside it.
- How to reach us and how fast we reply.
- Price, billing date, and how either side can stop.
- What you get if you stop: a copy of the site, and who owns the domain and accounts.
That last heading matters more than it looks. If the plan ends, the client should know they keep their domain, their email and their listing, and how they get a copy of their site; who should own each client account sets that out account by account. Saying it at the start makes the plan easier to agree to.
Where should care plan requests live?
Care plan requests arrive by email, text and phone. The plan is in one place, the request in another, and the answer in a third. Pick one place where each client's plan and their requests sit together, so "is this covered?" takes a glance, not a search.
Volant keeps each client's messages next to the plan they're on. Your agent drafts the reply with the plan in view, and nothing goes out until you approve it. The services page shows what you can offer after the website, from care plans onwards.
Whatever you use, the rule is the same: write down what's covered, check each request against it, and quote before you build.