A maintenance request only needs a separate quote when it falls outside what the plan already covers — patches, small content edits, and routine fixes go out at no extra charge. Every request follows the same four-step path through the client portal: logged, scoped, quoted only if it's outside the plan, and tracked to done, with no billable hour starting before the client approves the quote.
Most "unlimited support" maintenance plans don't actually say what unlimited means, and that vagueness is where the disappointment lives. A plugin security patch takes minutes to apply. A new booking flow, a payment integration, or a redesigned section takes design time, build time, and testing — hours, not minutes. A flat monthly fee sized for the first can't quietly absorb the second: either the provider eats the cost until the plan stops being worth running, or the client gets an invoice for something they thought was already covered. Neither is honest, so we don't do either — we scope it and say so before any of it is billed.
What actually stays inside the plan
The rule of thumb is whether the request changes what the site already is, or just keeps it working as it already is. A text swap, a new product photo, a broken link, a security patch, a restore from backup — all of it operates on the existing design and structure, so it's covered. The moment a request adds something that wasn't part of the site when the plan was scoped — a new page, a third-party integration, a different layout for a whole section — it stops being maintenance and starts being new work, and new work gets a quote, the same as it would for any other project.
Why the quote comes before the work, not after
Every request enters the same log in the client portal — the same one we hand over at launch and cover in our handover checklist — and if it needs a quote, that quote sits attached to the request itself. Nobody starts a billable hour against it until the client approves it there. That ordering is the actual point: a client can see the cost before committing to it, rather than finding out what a "quick add-on" cost after it's already built. It's the same transparency habit behind being able to see exactly what a maintenance plan did each month, not just being told it happened.
What this looks like when it works
A client asks for a new appointment-booking page mid-plan. It's logged, scoped against what the integration actually needs (calendar sync, confirmation emails, a staff-facing view), and a quote goes back on the request before a single hour is spent building it. If the client approves, it's built and tracked to done like anything else in the portal. If they don't, nothing was ever billed for scoping it — the conversation itself doesn't cost anything, only the decision to proceed does.
Frequently asked questions
What kind of request typically stays inside a maintenance plan?
Anything that works on the site as it already exists: security patches, a text or image swap on an existing page, a broken-link fix, restoring from a backup. None of it changes what the site is or does, so it doesn't need a fresh scope.
What usually needs a separate quote?
A new page or section, a third-party integration (payments, booking, a CRM), or a structural redesign — anything that wasn't part of what the plan was priced against when it started. It's new work, not upkeep on existing work, so it gets scoped and quoted like a small project of its own.
Do I have to approve a quote before any work starts?
Yes. The quote sits attached to the request inside the client portal, and no billable hour starts against it until the client approves it there. There's no version of this where work happens first and the invoice explains itself after.
What if I think a request should be inside the plan but it comes back quoted?
Say so on the request thread in the portal before approving anything — scoping is a conversation, not a one-way notice. Most disagreements come down to a request being bigger than it looked from the outside, and that's worth resolving before work starts, not after.
Does this work the same way for app maintenance plans?
Yes — the same logged, scoped, quoted-if-outside-plan, approved path applies whether the request lands on a website or a business app. The only real difference is that an app change past a certain size may also sit in app-store review once it's built, which a website change never does.