A support retainer works when a ticket says what changed in the world, not when it says “make it pop.” The split that keeps the month sane is simple. A content change edits copy, an image, or a menu label through fields the site already has. A deploy changes templates, dependencies, redirects, or anything you’d want in version control and able to roll back. Put both in one ticket with one due date and a phone-number edit waits behind a header rewrite, or the header rewrite goes out on a Friday because the phone number was urgent.
The retainer should name a monthly ceiling in hours and a class of work that is always in bounds: small copy edits, broken-link checks, plugin updates with a changelog you actually read, and form tests after those updates. Out of bounds, unless a separate estimate is accepted: new page templates, a checkout, a migration. Also out: anything needing a staging pass longer than the ticket itself. Write that down once and you prevent the argument later, when “quick” has already used up the month.
What does a support retainer ticket look like?
A content ticket fits in four lines: the page URL, the sentence that’s wrong, the sentence that should replace it. Add whether the change is safe to publish with no layout risk. If the new text is twice as long as the old, say so. A hero line that wraps to six lines on a phone is no longer a copy edit. It’s a layout change that needs a look at the breakpoint. That is a deploy-class check even if no file is new.
A deploy ticket names the behavior, the pages it touches, and how you’ll know it worked. “Update the header” isn’t a ticket. “On service pages, show the phone number in the header on screens under 768 pixels, without covering the first heading” is one. It can be estimated, staged, and checked. The first version can only be argued about.
Plugin and platform updates sit in the middle and should be called what they are. A security update with a clean changelog and a staging click-through is routine retainer work. An update that removes an API your form uses is a small project, even if the plugin screen says “update now.” The retainer can schedule it. It shouldn’t pretend the click is free because the button was red. For a closer look at the monitoring side, see what “watching the site” must include.
What gets reported at the end of the month?
The monthly note is a list, not a mood: content edits shipped, with URLs. Then list updates applied, with versions; tickets declined or moved to an estimate, with one sentence why; hours left. That list is what makes a retainer renewable. A paragraph about partnership doesn’t tell the client whether the contact page still mentions last year’s city.
Urgent still has to pick a class. A wrong price on a live page is a content emergency: change the number, confirm the cache cleared, send the URL. A wrong price because the template pulls from a dead field is a defect: fix the source, deploy, then confirm. Both can happen the same day. But they shouldn’t share one vague ticket titled “pricing,” because the rollback story differs. Copy can be reverted in the editor. A template revert is a release.
What if the support retainer keeps filling with deploy work?
Then resize the agreement or pull a project out of it. Don’t quietly skip the content queue to make room. Tell the client what happened and offer a choice: a larger retainer, or a scoped project with its own estimate and staging pass. Our staging checklist shows what that review looks like when a client has to click through it.
The website support page describes support as a defined service, pricing shows how engagements are framed. The how it works page covers the steps before the first ticket arrives.