| Quick answer:
A website management proposal should define nine things in writing: scope, exclusions, response times, escalation path, uptime responsibilities, reporting, ownership and access, exit terms, and pricing basis. If any of these uses words like “timely”, “regular” or “as needed” instead of a number, a named person or a clear rule, the proposal lists services without committing to them. Every commitment should then carry over word for word into the signed website management agreement and its website management SLA. |
A website management proposal exists to settle responsibility before something breaks, not to describe a service menu. By the time you finish reading it, you should be able to answer eight questions without calling the provider:
• What exactly is being managed on your site?
• What isn’t, and what happens when an issue lands there?
• How quickly will someone acknowledge a problem, and during which hours?
• Who handles an emergency, and who takes over if the first fix fails?
• Who owns the domain, hosting, code, backups and accounts?
• What will you receive each month as proof of the work?
• How does the relationship end, and what do you get when it does?
• How is the price calculated, and what triggers extra charges?
If you can’t answer one of these from the document, that line is still open, and an open line usually defaults to your cost.
This applies whether you’re hiring a first management partner after years with a freelancer, switching after a provider let you down, or renewing with your current one.
Renewal is the moment most people skip. Terms written when the site did $400K often stay untouched long after it’s doing $2M.
With those questions in mind, the next step is to look at the specific lines in a proposal that determine who is responsible, how quickly they need to act, and what happens when something falls outside the plan.
Related Read: WordPress Maintenance Is Not Website Management
The 9 lines to read in a website management proposal before you sign
Nine lines carry almost all of the accountability in a website management proposal.
Read each one with three questions in mind: what should it say, what should you watch for, and why does it matter on the night something actually breaks?
We’ll start with the scope itself, because you can’t judge response times or accountability until you know exactly what the provider has agreed to manage.
1. Scope of management
What it should say: The scope should list the specific parts of your site the provider is responsible for: the theme, the plugins your revenue depends on, the payment gateway, your LMS or subscription engine, key integrations and the hosting environment. A named system is a commitment. An activity like “updates” or “monitoring” is a description.
What to watch for: Generic scopes that could be pasted into any client’s proposal. If your site isn’t named in the scope, nothing specific to it is covered.
Why it matters: Most incidents on a scaling site happen inside an integration, not inside WordPress itself. If renewals fail at 2am because a gateway update clashed with a plugin, the scope line decides whether that’s your provider’s problem or yours.
Our 12-point website management plan scope checklist goes deeper on this line.
2. Exclusions
What it should say: A useful exclusion line lists what isn’t covered and what happens next: the hourly rate, whether the work needs your approval first, and how fast out-of-scope work starts. Exclusions themselves aren’t a red flag. Every provider has them. Unpriced exclusions are.
What to watch for: Three patterns:
• No exclusions listed at all, which means the boundary gets decided during an incident.
• A blanket “third-party issues excluded”, on a site that is mostly third-party code.
• Security patching left undefined, or tucked into “updates as needed”.
That last one matters more than it looks. Patchstack reports that more than 60% of attacks target vulnerabilities that already had a patch available, and puts the average exposure window to update, test and patch at 120 days.
Why it matters: Vague scope hurts both sides, and providers know it.
| EXAMPLE · A WooCommerce subscription store: when “third-party issues excluded” covers the whole incident
A supplements brand runs around 1,800 active monthly subscriptions through WooCommerce Subscriptions and Stripe. Its management proposal covers “plugin updates and monitoring” and excludes “third-party issues.” A routine gateway plugin update conflicts with a custom renewal hook, and renewals start failing overnight. The provider applied the update, but it classifies the failure as a Stripe issue, so the fix lands outside scope. Three days pass while both sides argue about whose problem it is. By then, hundreds of renewals have failed and customers are emailing support.The update was in scope. The failure it caused was not. That is the gap an exclusions line creates when it names a category instead of a boundary. |
Patching Not Spelled out in your Proposal?
Before you negotiate who handles security updates, see how many known vulnerabilities your plugins and theme carry today. A baseline turns that line from a promise into something you can check.
3. Response times
What it should say: A response-time commitment in a website management SLA has three parts: a time in hours, the hours it applies (24/7 or business hours, and in which time zone), and the severity level it’s attached to. “Support available” with none of those describes availability, not speed.
What to watch for: Response and resolution getting blurred. Response means someone has acknowledged the issue and started on it. Resolution means it’s fixed or a workaround is live. A proposal that promises a one-hour response but says nothing about resolution has committed to an email, not a fix.
For reference, guidance from Canada’s Business Development Bank (BDC) gives “4 hours response and 12 hours resolution, 24 hours a day, 7 days a week” as an example service level for round-the-clock support. Revenue sites often negotiate tighter targets for critical issues.
Why it matters: There’s a real trade-off here. Round-the-clock cover costs more, and a B2B site whose buyers order during office hours may not need it. A store running weekend promotions, or a course platform with learners in three time zones, almost certainly does.
Pay for the clock your revenue actually runs on. We cover what good answers sound like on a sales call and how to vet a website management agency.
4. Escalation path
What it should say: An escalation path names who takes ownership when an issue isn’t resolved within the expected time, and when that handover happens. Without one, a stuck P1 sits in the same support queue as a font change.
What to watch for: Escalation that ends at a shared inbox, or a “dedicated account manager” with no stated authority to pull in more people or approve emergency work.
Why it matters: Escalation sounds like a formality until you look at why outages run long. Uptime Institute’s 2025 outage analysis found that nearly 40% of organizations had a major outage caused by human error in the past three years. Of those, 85% came from staff not following procedures or from flawed procedures.
A written escalation path is the procedure. If it isn’t in the proposal, it depends on whoever is on shift.
5. Uptime and downtime
What it should say: An uptime commitment should state a percentage, what is being measured, what is excluded and what happens when the target is missed. The percentage alone tells you very little. Here’s what common figures allow in a month:
| Uptime commitment | Downtime allowed per month (approx.) |
| 99.99% | 4.4 minutes |
| 99.9% | 43.8 minutes |
| 99.5% | 3.6 hours |
| 99% | 7.3 hours |
What to watch for: Four questions the line should answer:
• Is it measuring the homepage, or checkout, login and course access?
• Does scheduled maintenance count against it?
• Is this the hosting company’s uptime passed through, or the provider’s own commitment?
• Are there service credits, or any consequence at all, for a miss?
Many proposals quote the host’s SLA as if it were the management provider’s. Those are two different promises from two different companies.
Why it matters: Your homepage can be up while checkout returns errors. For a store or course platform, the page that matters is the one that takes money or delivers access.
Uptime measured on the wrong page is a reassuring number about the wrong thing. If you haven’t put a figure on what an hour offline costs, website downtime is costing you revenue.
| EXAMPLE · A LearnDash course platform during a cohort launch
A professional certification business opens enrollment for a 600-learner cohort. The provider’s uptime report shows 99.98% for the month, because it checks the homepage every five minutes. Meanwhile, a membership plugin update has locked paying learners out of their lessons for most of launch day. Support fields 140 tickets, and the report still says green. Five lines in, four to go. Everything so far governs the bad night: what’s covered, how fast someone moves, and who owns it when the first fix fails. The last four govern something different: what you can prove, what you own and what you can walk away with. For a course business with a 200-lesson library and years of learner records, those four lines often matter more than any response time. The fix: Write the monitored transactions into the SLA (login, lesson load and checkout) and measure the uptime figure against those, not the homepage. |
6. Reporting
What it should say: A monthly report should show what changed on your site and what was found, not just confirm that checks ran. The test is simple: could you hand the report to a new provider and have them understand the state of your site?
What to watch for: Dashboards full of green ticks with no incidents, no versions and no open risks. A month with nothing to report is possible. Twelve of them in a row on a busy store is unlikely.
Why it matters: Backups are where this shows up most. A backup that has never been restored is an assumption. Ask whether the report confirms a test restore, and see if your site went down right now, could you restore it fast? for what that test involves.
It also helps to have your own security baseline from before you signed, so the provider’s first report has something to be checked against. If a report can’t be checked against anything, it isn’t proof of work.
7. Ownership and access
What it should say: Your business should own the domain registrar account, hosting account, code repository, backups, analytics, and payment and email service accounts, with the provider given delegated access. The proposal should say this explicitly, not leave it to whoever happened to set the accounts up.
What to watch for: Phrases like “we’ll host it for you” or “included in our infrastructure” with no mention of transfer. Also backups stored only in the provider’s storage, with no stated retention period and no copy to you.
Why it matters: Registrar access deserves extra care. Domain Name Wire reported a lawsuit in which a business that had run its site since 1998 said a contract developer used registrar access to move the domain into his own name. The developer disputed the claim.
Whatever the facts, the lesson holds: delegate access, keep ownership. It’s also one of the gaps in our WordPress security checklist. The provider should be able to manage everything and own none of it.
Not Sure whose name is on your Hosting Account!
In our arrangements, your code, accounts and documentation stay yours from day one, with delegated access for our team. See how that's set up before you compare it with the proposal on your desk.
What it should say: Exit terms should state the notice period, exactly what you receive at handover, the format it comes in and how many days the handover takes. Leaving a provider should be a process written in advance, not something you negotiate while you’re unhappy.
What to watch for: Exit fees, data held back until undefined “outstanding invoices” are settled, and minimum terms longer than six months for a first engagement. For ecommerce and eLearning sites, confirm that customer, order, subscription and learner data are named in the handover list.
Why it matters: A poor exit usually costs you later, not on the day you leave. One site owner posted in the WordPress.org support forums after a designer finished the build and went silent: “he didn’t give me admin access and I can’t access all the features.”
Handovers can also break things that keep running in the background. We at WisdmLabs worked with a lifestyle magazine brand whose renewals froze after an earlier migration. We restored them within 30 hours, but a documented handover would have prevented the problem. Write the exit terms while everyone still gets along.
9. Pricing basis
What it should say: The pricing line should explain what the fee buys: a number of hours, a defined scope, or both. It should also say what happens to unused hours, the rate for out-of-scope work and when the price can change. A monthly figure without that basis can’t be compared with anything.
What to watch for:
• “Unlimited small tasks” with no definition of small.
• Hour banks with no rollover rule. BDC’s guidance suggests asking what happens to unused hours at month-end.
• Price reviews at the provider’s discretion, with no notice period.
Why it matters: Price should rise and fall with responsibility. A provider committing to a one-hour P1 response around the clock is carrying more risk than one offering next-business-day email, and should cost more.
Compare commitments, not monthly totals. Our guides to website management services cost and hourly billing vs a monthly retainer cover the pricing models in more detail.
These nine points give you the framework for reviewing a proposal. The next step is to apply that framework to the wording itself, because a proposal can cover all nine areas and still leave important commitments vague.
Vague proposal wording should become a question before it becomes a contract
Vague wording in a website management proposal isn’t always a sign of bad faith. Often it’s a template nobody tailored. Either way, every vague line should go back to the provider as a written question before you sign.
| Vague wording | What to ask | What a committed version looks like |
| “Timely support” | What response time, for which severity, during which hours? | “P1: 1-hour response, 24/7” |
| “Regular backups” | How often, stored where, kept how long, and is restore tested? | “Daily off-site backups, 30-day retention, monthly test restore” |
| “Emergency support available” | What counts as an emergency, and is it included or billed extra? | “P1 defined as site down, checkout, login or course access failing; included in plan” |
| “Minor updates included” | What counts as minor, and who decides? | “Content and layout changes up to 2 hours each; larger work quoted first” |
| “Proactive monitoring” | Monitoring what, how often, and who is alerted? | “Checkout and login checked every 5 minutes; alerts to on-call engineer” |
| “99.9% uptime” | Measured where, excluding what, and with what consequence for a miss? | “Measured on checkout; scheduled maintenance excluded; credit for misses” |
| “Best efforts” | What happens if best efforts aren’t enough? | A named escalation step with a time trigger |
| “Unlimited small tasks” | What’s the size limit, and what’s the queue time? | “Tasks under 30 minutes, completed within 2 business days” |
| “You own your website” | Which accounts are in our name today? | “Registrar, hosting, repository and backups held in client accounts” |
| “30 days’ notice” | What do we receive at exit, in what format, by when? | A handover list with a delivery timeline |
A good provider will answer these in writing without pushback. If a question about response times gets a sales answer instead of a number, that tells you something too. It also helps to know which document you’re looking at, because a plan, a proposal and an agreement promise different things.
The common gap sits between the last two. Commitments made in a proposal don’t always survive into the agreement, so compare the two side by side before you sign.
If you’re still at the stage of choosing between providers, how to choose a website management company when downtime costs you revenue covers that earlier decision.
If the written proposal still leaves you with questions, take those uncertainties directly to the provider. A few specific questions can reveal much more about how the relationship will work in practice.
Ask the provider these five questions before you sign the website management agreement
Five questions turn a proposal review into a conversation that shows how the provider actually works. Ask them in writing, so the answers become part of the record.
1. “Walk me through the last P1 incident you handled, with times.” You want timestamps for detection, response and resolution. A provider that tracks its SLA will have them.
2. “Who is our named escalation contact, and what can they authorise?” You need a name and a role, and to know whether they can approve emergency work or bring in extra people.
3. “What would you charge for [a specific out-of-scope task on our site]?” Pick something real, like adding a payment method or a new course bundle. The answer shows how exclusions work in practice.
4. “Which accounts will be in our name on day one?” The answer should be all of them.
5. “If we leave in month seven, what do we receive, in what format, and within how many days?” This tests whether the exit terms are a process or a sentence.
That’s the full set: nine lines, the wording to question and the questions to ask. Where your own proposal stands is the open part, and it takes about five minutes to find out. Run the check below with the document open beside you. If you run more than one store or course site, check each proposal separately, because providers often write different terms for different properties.
| Score your website management proposal: a 7-question check
Answer yes or no for the proposal in front of you. 1. Does the scope name your actual systems (theme, key plugins, integrations, hosting) instead of generic activities? 2. Are exclusions listed, with a rate or approval process for out-of-scope work? 3. Is there a response time in hours for each severity level, with the coverage window (24/7 or business hours) stated? 4. Is there a named escalation step beyond the support queue, with a time trigger? 5. Does the uptime line say what it measures, what it excludes and what happens when it’s missed? 6. Are the domain, hosting, code and backups in your business’s name, or transferable on request within a stated time? 7. Do the exit terms specify a notice period, a handover list and a timeline? 6 to 7 yes: The proposal makes real commitments. Confirm the same wording appears in the signed agreement. 4 to 5 yes: A normal first draft, and a negotiable one. Send the “no” lines back as written questions before signing. 0 to 3 yes: The document describes services without committing to them. Ask for a revised proposal, or compare it against one that fills these lines in. See how we define these terms in our Website Management Services → |
Conclusion
A good website management proposal makes it clear who is responsible, how quickly they will respond, and what happens when something goes wrong.
At $300K to $4M a year, renewals, enrollments and repeat orders all run through the site, so each undefined line carries more weight than it did when the business was smaller.
Use the 7-question check above on the document in front of you. Which lines have numbers? Which have names? Which only have adjectives?
If the proposal in front of you leaves you guessing who owns downtime, see how we at WisdmLabs define it in our Website Management Services →
FAQ
What is the difference between a website management proposal and a website management agreement?
A website management proposal is the provider’s offer: what it will manage on your site and on what terms. The website management agreement is the signed, enforceable version. Before signing, check that every commitment in the proposal, especially response times, ownership and exit terms, appears word for word in the agreement.
What is a reasonable response time in a website management SLA?
It depends on severity and on when your revenue runs. Canada’s Business Development Bank gives “4 hours response and 12 hours resolution, 24 hours a day, 7 days a week” as an example for round-the-clock support. Revenue-critical sites often negotiate a 1 to 2 hour response for outages that affect checkout, login or course access.
What uptime should a website management agreement guarantee?
99.9% is a common target, and it still allows about 43.8 minutes of downtime a month. What the figure measures matters more than the figure itself. Confirm it covers checkout or course access rather than just the homepage, and what happens when it’s missed.
Should my provider or my business own the hosting and domain accounts?
Your business should own them. The provider should get delegated access to the domain registrar, hosting, code repository and backups, not ownership. That way a change of provider never depends on someone else agreeing to hand over your accounts.
Can I negotiate a website management proposal before signing?
Yes, and a good provider expects it. Vague scope causes disputes for both sides, so turning adjectives into numbers protects the provider as much as you. Send your questions in writing and ask for a revised proposal that answers them.
