What Goes In a Webflow Retainer Agreement: Hours, SLA, Exclusions

A Webflow retainer agreement is the document that settles what recurring work the client is buying, how fast you answer when something breaks, and where your responsibility stops. Six clauses carry almost all of that weight, and the retainers I have seen go wrong went wrong in one of those six places rather than in the legal boilerplate around them. Get these written plainly and the monthly conversation becomes a status update instead of a negotiation.

• Hours. The size of the monthly block, and the rule that converts a request into hours.
• Rollover. Whether unused hours expire at the end of the month, carry forward, or carry with a cap.
• Response and resolution. Two separate clocks: one for acknowledging a request, one for fixing it.
• Scope boundary. The test that decides whether a request is retainer work or a new quote.
• Exclusions. The named list of things the retainer does not cover, in the client's words, not in legalese.
• Platform costs and term. Who pays Webflow directly, and what happens when Webflow changes its prices mid-term.

What goes in a Webflow retainer agreement?

A Webflow retainer agreement contains six clauses: the monthly hour block with its minimum billing unit, the rollover rule, separate response and resolution windows, the test that separates retainer work from a new quote, the named exclusions list, and the platform-cost pass-through with its review date. Each one works only when it is anchored to something checkable rather than to goodwill. On the retainers I run for agencies, every clause gets paired with the platform fact that constrains it, because a promise Webflow itself will not honour is a promise the retainer has to absorb. The clearest example is a clause agencies write without checking: Webflow's backup documentation states that Webflow "doesn't offer scheduled backups, but restore points are created automatically on every 50th auto-save", so a retainer promising weekly backups is promising something the platform does not produce. Write the clause against the mechanic, not against the feeling. If a clause cannot be traced to a documented platform behaviour or to a stated commercial rule, it will be argued about in month three.

Clause	What the agreement must state	The Webflow fact that constrains it
Hours	Block size, the minimum billing unit, and how a request becomes hours	Webflow's Data API caps Site Publish at "one successful publish per minute", which binds automated publishing; manual edits are bound instead by the agency's own context-switch cost (Webflow rate limits)
Rollover	Whether unused hours expire, carry forward, or carry with a ceiling	A commercial term, not a platform setting: Webflow bills Site plans, bandwidth and add-ons, not agency time (Webflow pricing)
Response and resolution	Separate acknowledgement and fix windows, by severity	Webflow states "We do not provide phone or video call support (except for Enterprise customers)", so out-of-hours escalation is yours to define (Customer Support Policy)
Scope boundary	The test separating included work from a new quote	Changing the baseline pulls in work Webflow meters separately, such as redirects: Webflow "executes redirects in the order they were added" and recommends "1,000 maximum as best practice" (Webflow 301 redirects)
Exclusions	The named list, quoted rather than summarised	Webflow states "You are responsible for implementing and maintaining custom code (e.g., JavaScript, CSS) and integrations with third-party services" (Customer Support Policy)
Platform costs and term	Who pays Webflow, and the renewal date that triggers a price review	Webflow applies plan price changes on a site's next renewal or billable change, so the renewal date is when a change lands and the agreement must name the subscriber and the review month (Webflow pricing update)

The table above is the whole agreement in miniature. For the project-phase document that sits underneath a retainer, including ownership and copyright language, the Webflow developer contract guide covers what belongs there instead.

How should Webflow retainer hours be defined and counted?

Retainer hours should be defined as a monthly block with a stated minimum billing unit and a written rule for turning a request into time. A block with no minimum unit invites a stream of two-minute asks that cost fifteen minutes each once context switching, publishing and a reply are counted. On client projects I bill in fifteen-minute units, group same-day requests into one publish, and state in the agreement that the publish, not the request, is the billable event. Grouping is not a concession extracted from the client, it is the only honest way to price the context switch: the fifteen minutes a two-minute edit really costs are spent on opening the project, finding the element, publishing and replying, and none of that shrinks because the edit was small. If a client needs changes to go live individually and immediately, that is a different and more expensive product than a retainer block.

• Block size. State the hours per month as a number, not as "ongoing support".
• Minimum unit. State the smallest increment you bill, so a one-line change does not read as free.
• Billable event. Name what triggers the clock: the publish, the ticket, or the review.
• Overage rate. State the rate for hours beyond the block, and whether the client approves overage in advance.

Do unused Webflow retainer hours roll over?

Unused Webflow retainer hours roll over only if the agreement says so, because rollover is a commercial term rather than a platform setting: Webflow's billing covers Site plans, bandwidth and add-ons, not an agency's hours. Only the agreement decides, and only three shapes are in common use.

• Expiry. Hours end with the billing month. Defensible when the retainer sells availability rather than output, as long as the agreement says plainly that a response time is the thing being bought.
• Unlimited carry. Hours accumulate indefinitely. Easy to sell and the main source of unstaffable demand later.
• Capped carry. Hours carry for a limited period up to a ceiling. The rule I apply on retainers is a single month of carry with the balance capped at one block.

Define which month you mean, because Webflow's own billing does not use the calendar one: the surge protection documentation explains that a billing month for an annual subscriber starts on the subscription date, so a site subscribed on the 5th runs from the 5th to the 4th. A retainer that says "end of the month" while the Site plan renews mid-month has two calendars in one agreement.

If the client treats the block as a bank, cap the balance before the first invoice goes out.

How do you decide whether a request is retainer work or a new quote?

A request is retainer work when it operates inside the baseline the retainer maintains, and a new quote when it changes that baseline. Editing content inside an existing component on an existing page is inside the baseline. Adding a component, a page, a Collection, a field or an integration changes it, and so does restructuring a template, because every one of those creates something that has to be maintained from then on. The rule I apply on client projects is a single question asked out loud on the ticket: after this ships, is there more site to look after than there was before? If yes, it is quoted.

Baseline changes also drag in work Webflow meters on its own terms, which is why the boundary is not just about effort. A page whose URL changes needs a redirect, and Webflow's 301 redirect documentation states that Webflow "executes redirects in the order they were added to the site" and recommends "1,000 maximum as best practice", so redirect order and redirect count are permanent consequences of a request that looked like a content edit. A clause that cannot see that will absorb it.

• Retainer work. Swapping a hero image and headline, updating pricing copy, publishing a blog post into an existing Collection, fixing a form that stopped submitting.
• New quote. A new page, a new component, a new CMS field or Collection, a new integration, a template restructure, or any URL change that creates redirects.
• The borderline case. Adding a testimonial block is retainer work if the component exists and a quote if it has to be built, and the agreement should say so in exactly those terms.
• The size override. Anything estimated above a stated share of the monthly block goes to a quote even when it sits inside the baseline, so one large request cannot swallow a month.

Define small while you are here, because "unlimited small changes" is the clause that causes the most friction and the least documented meaning. A change is small when it alters content inside an existing component, on an existing page, without new styles, and can go live in the next publish. If a reader cannot apply that sentence to their last ten tickets without asking you, it is not written tightly enough yet.

What should a Webflow retainer SLA promise, a response time or a resolution time?

A Webflow retainer SLA should promise a response time and a resolution time as two separate clocks, because a reply that lands inside the window while the site stays broken still reads as a failure to the client. A response time commits to acknowledgement and triage; a resolution time commits to a fix, and it works only when it is tiered by severity, since a down site and a wrong button colour are not the same event. When I write this clause, the resolution tier is attached to a definition of severity that the client can apply without me, so nobody argues about which tier a ticket is in while the clock runs. Note what you cannot promise. Webflow's Customer Support Policy puts site hosting, performance and uptime inside Webflow's own support scope, which means an outage caused by the platform is Webflow's to fix and not something an agency should write a fix deadline against. The same policy states that "We do not provide phone or video call support (except for Enterprise customers)", so escalation on a non-Enterprise site moves at the speed of a support queue you cannot jump. Write the resolution clause so it promises your action by a deadline, not Webflow's.

The tiers below are the ones I write into Webflow retainers, stated in business hours and business days rather than wall-clock time, and offered as my own contract practice rather than as an industry benchmark.

Severity	What qualifies	Response	Resolution	Who owns the fix
One	Site down, checkout broken, forms not submitting	One business hour	Four business hours to a fix or a working workaround	Agency, unless the cause is the platform
Two	A page or component broken, content unpublishable, tracking broken	Same business day	Two business days	Agency
Three	Copy, styling and content requests	Two business days	Inside the current block	Agency
Vendor-caused	Platform outage, Designer or CMS defect	One business hour	Diagnosis and a Webflow ticket the same day, fix timing not promised	Webflow

For the performance numbers a developer can reasonably commit to in the first place, the vetting questions in what to ask before hiring a Webflow developer are the better reference, and a retainer should not restate them.

What does Webflow's own support cover, and what falls to the retainer?

Webflow's own support covers account access and verification, billing for Workspace owners and admins, help with the Account and Workspace Dashboard, "platform tools and functionality" such as the visual canvas and the CMS, and "site hosting, performance, and uptime" for published sites, per its Customer Support Policy, last updated March 26 2026. Everything else on a client site falls to the agency retainer. A retainer that quietly promises uptime or platform-bug fixes is therefore reselling something the client already owns, for free, with no ability to deliver it.

• Account access and verification. Webflow's queue, not the retainer's, and worth saying so when a client is locked out on a Friday.
• Billing. Covered for Workspace owners and admins, which is one more reason the agreement must name who holds that role.
• Account and Workspace Dashboard. Webflow's remit, including plan changes and seat administration.
• Platform tools and functionality. The visual canvas and the CMS themselves, so a genuine Designer or CMS bug is a Webflow ticket.
• Site hosting, performance and uptime. Named in Webflow's scope for published sites, which is exactly the clause agencies most often absorb by accident.

What falls to the retainer is everything the same policy pushes back to the site owner, and all of it is work a client will still expect somebody to do. Webflow states that "You are responsible for implementing and maintaining custom code (e.g., JavaScript, CSS) and integrations with third-party services", that "Webflow does not provide support for third-party Templates, Libraries, or Apps available in the Webflow Marketplace", that "We're unable to provide feedback or guidance on design aesthetics, branding, or UX strategies", and that "Once code is exported from Webflow, you are responsible for its integration and maintenance on other platforms". What I see agencies get wrong here is leaving that list implicit, so the client discovers it during an incident and assumes the agency is dodging. Quote the policy lines in the retainer and the boundary stops being a matter of opinion.

• Custom code and integrations. Webflow puts implementation and maintenance on the site owner, which in practice means the retainer.
• Marketplace apps, templates and libraries. Explicitly unsupported by Webflow, so app breakage is agency work or nobody's.
• Design and UX opinions. Outside Webflow's remit entirely, and the most common informal ask inside a retainer.
• Exported code and non-Webflow environments. Responsibility transfers to the owner the moment the code leaves Webflow.

Access and role questions around an inherited or transferred site are answered in the guide to auditing a Webflow site you did not build and the white label Webflow workflow, which is where the Workspace and seat mechanics belong.

What should a Webflow retainer explicitly exclude?

A Webflow retainer should exclude six categories by name: ranking and lead-volume outcomes, new pages and CMS schema changes, migration and rebuild work, copywriting and asset production, out-of-hours work, and platform fees and app subscriptions. The custom-code, Marketplace-app, design-advice and exported-code boundaries are already settled above by Webflow's own policy, so the retainer's own exclusions list covers the things Webflow never had an opinion about. Outcomes head that list, because outcomes are not deliverables: Webflow warns that SEO changes "can take days, weeks, or even months to index", per its SEO settings documentation, so no retainer can carry a dated ranking promise. The rule I use is that anything whose completion depends on a third party, a vendor queue or an algorithm is named as excluded or named as best-effort, never as a deliverable.

• Ranking, traffic and lead-volume outcomes, as opposed to the implementation work behind them.
• New pages, new components and CMS schema changes, which are quoted as projects.
• Migration, redesign and rebuild work, which replaces the baseline the retainer maintains.
• Copywriting, content production and asset creation, unless a stated monthly allowance is included.
• Out-of-hours and weekend work, unless the agreement names an out-of-hours rate.
• Platform fees, bandwidth add-ons and app subscriptions, passed through at cost rather than absorbed.

Where the scope boundary meets price, the margin maths in the agency Webflow pricing guide and the ongoing-cost breakdown in Webflow developer cost do that job properly.

Where do Webflow retainers go wrong?

Webflow retainers go wrong in five named places: unlimited small changes with no definition of small, a single clock covering both response and resolution, rollover with no ceiling, platform fees bundled inside the retainer fee, and silence on third-party apps and custom code. Each one announces itself through a symptom long before anyone reopens the agreement to find out why, and naming the symptom is what makes the clause enforceable, because a clause only gets invoked if somebody recognises the pattern in time. When I audit an agency's retainer, I look for the symptom first and the missing clause second, since a month of tickets shows the symptom plainly while the gap in the document shows nothing at all.

What should a Webflow retainer do when Webflow changes its prices mid-term?

A Webflow retainer should name the platform costs it passes through, the date they are reviewed, and who holds the billing relationship with Webflow, because a platform price change lands mid-term whether the agreement anticipated it or not. The date that matters for agency work is specific: Webflow's pricing update states that "For existing sites in Freelancer or Agency Workspaces OR sites on legacy pricing, changes take effect on your next renewal or billable change on or after November 16, 2026" (Webflow blog). On the projects I lead, platform fees are invoiced separately at cost and the retainer names the Site plan renewal month as a standing review trigger, so the conversation happens before the invoice rather than after it.

Three details belong in the clause itself, and all three are cheap to write before the first invoice and expensive to argue about afterwards.

• Who the subscriber is. Name whether the Site plan sits on the client's card or yours, because that decides who sees the renewal notice at all.
• The review trigger. Name the renewal month, not a vague annual review, so a price change gets looked at on a date both parties can diary.
• The billing basis. Name whether the plan is billed yearly or monthly, because the two are not the same number and the gap compounds across a client portfolio. Current rates per plan live in the Webflow pricing breakdown; the retainer only needs to say which basis it is passing through.

Webflow's wider 2026 plan and pricing changes, including the dates that applied to everyone else, are covered in is Webflow worth it in 2026, so a retainer only needs the agency-Workspace consequence. If a client site sits in a Freelancer or Agency Workspace, put the November 2026 date in the agreement now.

When is a Webflow retainer the wrong arrangement?

A retainer is the wrong arrangement when the work is neither recurring nor urgent, because the client then pays for availability they never draw on and starts resenting the line item. Two other cases come up often on agency work: a client whose real need is a single build with a warranty period, and a client whose monthly asks are consistently larger than one block, which is a staffing problem dressed as a support problem. The rule I apply before proposing a retainer is to look at three months of actual requests first, and propose a block only if the pattern is steady; otherwise an hourly arrangement with a published rate is more honest and usually cheaper for the client. For agencies deciding whether recurring Webflow work should sit with a partner or a hire, the capacity maths in scaling Webflow delivery is the better starting point. If the last three months show fewer requests than half a block, do not sell a retainer.

How do you get a Webflow retainer reviewed before you send it?

Bring your current retainer template or draft to a short call and we will go through it clause by clause against the six above: hours and minimum unit, rollover ceiling, the two SLA clocks, the scope test, the named exclusions, and the platform pass-through with its review date. You will leave with a marked-up list of the clauses that are missing or ambiguous, and the specific wording I use in their place for Webflow work. Book a 15-minute retainer review.