Guides

Client requests arrive everywhere: email, text messages, phone calls, a comment on a shared document. The work itself is usually small, but tracking it across four channels is what actually eats the time. A simple, consistent system fixes more of this than any amount of discipline.

Give clients one place to ask

A single link where a client describes a change, pastes the page it's on and attaches a screenshot removes the guesswork on both sides. No password to remember, no new account to create, just a form that's always the same. The fewer places requests can arrive, the fewer places they can get lost.

Use a short, honest set of statuses

Four statuses cover almost everything: received, in progress, waiting on the client, done. "Waiting on client" matters as much as the others: it makes clear the ball is in their court, not yours, which quietly prevents the "did you see my message" follow-up email. When a client replies with the missing information, the request moves itself back to in progress.

Comment where the client can see it

Keep the back-and-forth on the request itself rather than splitting it across email threads and the request tool. A client who replies to an update email should have that reply land in the same place as everything else, not create a second parallel conversation that someone has to reconcile later.

Log time as you go, not at the end of the month

Time logged against a request the moment you do the work is accurate; time reconstructed from memory two weeks later usually isn't. Logging as you go also means the monthly report writes itself: a list of completed requests with the time each took, no digging required.

Set expectations on response time, once

Clients don't need same-day turnaround on every request; they need to know what to expect. A plain line, stated once, up front ("requests are usually handled within 2 business days") removes the anxious follow-up messages that come from not knowing.

Attachments belong with the request, not scattered in email

A screenshot or a file makes a request far clearer than a description alone, but only if it's attached to the request rather than sent in a separate email that has to be matched up manually later. Keep attachments tied to the original submission.

Let "done" mean done

Once a request is marked done, resist reopening it for anything but a genuinely related follow-up. A client's new idea, even a small one, is a new request. This keeps the numbers in the monthly report accurate and keeps "done" meaning something.

A request system doesn't need to be complicated to work. It needs one link, four honest statuses, and time logged close to when the work happened. Everything else is a nice-to-have.

Web shops already sell care plans; the trouble is usually structure, not demand. Here's a plain setup that holds up once you have more than a handful of clients.

Pick a small number of tiers

Three tiers cover most shops. A basic tier for hosting, SSL and uptime monitoring; a standard tier that adds a couple of hours of content updates a month; a premium tier for larger scope and faster response. Clients today pay roughly $75 to $150 a month for basic, $200 to $400 for standard, and $500 to $1,200 for premium, depending on the market and the work involved. Fewer tiers means fewer conversations about which one someone needs.

Decide what "included hours" means, in writing

The most common failure in care plans isn't the price, it's the ambiguity: does "2 hours a month" mean content edits only, or does it include troubleshooting, small design changes and answering emails? Write down what counts, once, and reuse the same wording for every client. If a plan includes 2 hours and a request takes 3, the extra hour is an overage, not a discussion.

Decide whether hours roll over

Rollover is a real feature clients ask for, but it needs a rule: usually the smaller of "the previous month's unused hours" and "one month's worth," so it can't build up indefinitely. Whatever the rule, apply it the same way every month. Clients notice when the math doesn't add up twice in a row.

Track time against the plan, not against a spreadsheet

Requests arrive by email, text and phone call, and hours quietly go unbilled when nothing captures them in one place. Log time against each request as you do the work, plus a general care line for anything that doesn't tie to a specific request, like the monthly check of forms and key pages. At the end of the month, hours used against hours included should be a lookup, not a reconstruction.

Flag overages, don't hide them

When a client goes over their included hours, say so in the same report that shows everything else. An overage that shows up as a surprise invoice erodes trust; the same overage shown next to the work that caused it reads as fair. Whether you bill for it is a separate decision, but the client should see it either way.

Report monthly, on a fixed date

Pick a date (the 1st of the month is a reasonable default) and send every client's report on it. Consistency matters more than perfection: a report that arrives reliably, even a plain one, builds more trust over a year than an occasional detailed one.

Start the plan before the trial ends

If you're testing a new plan structure or a new tool, look at a real report before you commit to it. A two-week trial with no card and a sample report from day one lets you and a client both see what the plan actually produces before either of you commits to a year of it.

Care plans work when the client can see, every month, exactly what they're paying for. Everything above is in service of that one sentence.

An expired certificate turns a working site into a browser warning in one second, and most clients notice it long before anyone at the shop does. It's a solvable problem, but it needs a bit of ongoing attention even on sites that are supposed to renew themselves.

Most certificates renew automatically, until they don't

Modern hosts and platforms mostly handle certificate renewal without anyone touching it. That's exactly why the failures are so disruptive: nobody's watching a process they've never had to think about. A renewal can fail quietly because a domain moved providers, a DNS record changed, or an automated process hit an error nobody saw. The certificate silently ages toward its expiry date with no one aware it stopped renewing.

What actually breaks

An expired certificate doesn't slow a site down or make it partially work; browsers show a full-page warning and most visitors leave rather than click through it. The same warning appears for a certificate issued to the wrong hostname, or one with a broken chain to a trusted authority. All three look identical to a visitor: the site is effectively down, even though the server is running fine.

Warn well before the deadline

A single alert on the expiry date is too late to matter; by then, a fix needs to happen immediately, often outside business hours. Multiple warnings, spaced out (three weeks out, one week out, one day out) give enough room to investigate a stalled renewal and fix it calmly, without anyone racing a countdown.

Check validity, not just the date

A certificate can be technically unexpired and still be broken: issued for the wrong domain after a site migration, or missing an intermediate certificate in its chain. Checking that the certificate is valid, in addition to checking how many days remain, catches problems a date-only check misses entirely.

Where the checks come from

Reading a certificate's details reliably needs an actual TLS handshake with the site, not just a normal page request. That's a different kind of check than uptime monitoring, and it's worth confirming your monitoring covers it specifically rather than assuming a general uptime check catches certificate problems too. It usually doesn't.

What to do when a warning arrives

First, confirm it's real: load the site directly and check the certificate details in the browser. If it's genuinely expiring, most hosts have a one-click renewal or a support channel that resolves it quickly, once someone actually looks. The expensive part of a lapsed certificate is never the fix, it's the delay before anyone notices.

Put it in the report either way

Even when nothing's wrong, showing the renewal date in a monthly report (domain and certificate renewals both) tells a client someone is watching for the problem before it happens, not just reacting after it does. That's worth more than the two seconds it takes to check the date.

The fastest way to make anyone ignore monitoring alerts is to send one for every blip. A single failed check is common and usually meaningless; a real outage is rarer and worth interrupting someone for. Here's how to tell them apart.

Check often, but don't alert on the first failure

A single timeout can mean the site is down, or it can mean one request from one place had a bad moment. Checking every 5 minutes catches problems quickly, but only if a failed check leads to a retry, not an alert. A short wait and a second attempt clears the majority of blips before anyone needs to know about them.

Confirm from more than one place

A network problem between the checker and the site can look identical to the site actually being down, if you're only checking from one location. Confirming a failure from two or three separate regions, and requiring most of them to agree, filters out the failures that are really about the path between checker and site rather than the site itself. An outage only becomes an incident once independent checks agree.

Tell a firewall block from an outage

Sites behind a firewall or bot-protection service sometimes block automated checks outright, and that response can look like an error. A `403` with the site's own "blocked by firewall" message, or a challenge page, means the site is up but the check needs to be let through, not that anything is actually wrong. Treating that as a setup problem instead of downtime avoids alerting on something the client experiences as nothing at all.

Alert once per incident, not once per failed check

If a site is down for 20 minutes and checked every 5 minutes, that's up to 4 failed checks. One alert when it goes down and one when it's confirmed back up is enough; a message for every failed check during that window trains people to skip past your alerts entirely.

Use generous timeouts

A slow page isn't necessarily a broken one. A timeout that's too short flags ordinary slowness as an outage; a longer timeout, paired with a retry, tells the difference between "slow right now" and "not responding at all."

Write the "what happened" note while it's fresh

Once an incident resolves, a short note on what caused it and what was done travels well into a client report later. It also becomes useful the next time something similar happens: patterns show up across a handful of these notes that a single incident never reveals.

What false alarms actually cost

Every alert that turns out to be nothing spends trust, both from the client and from you. The first false alarm gets a quick check; the fifth gets ignored, right up until the one that matters. Confirmation and retries aren't caution for its own sake, they're what keeps the alert worth acting on when it finally fires.

Calm monitoring isn't monitoring less. It's making sure that when something does alert, it's real, and everyone still trusts it enough to act.

A care plan is easy to cancel when the work behind it is invisible. The clearest fix is a monthly report that shows what happened, in words a client understands. Here's what belongs in it.

Start with the overall status

Lead with one sentence a client can read in five seconds: the site was up 99.97% of the month, or it went down once and is fixed. Numbers over adjectives. "Down for 13 minutes on August 14" tells a client more than "a brief outage."

Uptime, in one chart

A simple daily bar for the month, with any downtime marked, says more than a paragraph. Keep the axis plain: the date range and nothing else. Most months this section is a quiet, steady line, and that's the point: it's proof the site was watched, even on the days nothing happened.

Incidents and fixes

For every incident, three facts: when it happened, how long it lasted, and what was done about it. "We contacted your host, who restarted the server. Then we checked the booking page and the contact form, and both worked." That last sentence matters: it tells the client someone checked, not just that a script logged a number.

Requests completed

List each request with its date and the time it took. This is where a care plan earns its keep: it turns scattered emails and texts into a record the client can see. A total at the bottom (2 hours, 45 minutes this month) gives the number real weight.

Hours used

Show hours used against what the plan includes, split by requests and general care work. If the plan doesn't roll over unused hours, say so plainly, rather than letting the client guess. If hours ran over, say that too: clients read reports as an honest record, and hiding an overage from the report while billing for it separately breaks that trust.

Renewals coming up

Domain expiry and certificate renewal dates, with how many days away they are. Most months there's nothing to do, and saying so ("nothing to do yet, we'll tell you if a renewal needs attention") is more useful than a blank section.

A few recommendations

Two or three suggestions, each tied to something the report already showed: a slow page, an image without alt text, a domain renewal coming up. Recommendations that come from data the client can see in the same report feel earned, not sold.

What to leave out

Raw response times, server logs, anything that reads like a monitoring tool rather than a person watching a site. A client doesn't need to know the check ran every 5 minutes from three regions; they need to know their site was fine, or that someone fixed it when it wasn't.

The report works when it reads like an update from someone paying attention, not a printout from a dashboard. Everything above fits on one page. If it doesn't, something in the list above is trying too hard.