How do edits work after launch, and how am I billed

After launch, edits are billed by model, not by vibes. Copy and images that fit fields you already have are self-serve — you publish them, the studio is not on the clock. Work that needs a designer or engineer is a capped ticket, a retainer draw against a written SLA, or a new sprint if it changes the product. Warranty is a short, named window to fix bugs versus the signed spec. It is not free new copy, free new pages, or free taste rounds. If that split is not on paper before the first Slack ping, you will fight the invoice.

This spoke sits under Websites That Feel Like Films. The pillar is the grade. This is how a change request is classified and billed. Keep-alive work — hosting, patches, uptime, backups — is a different contract. Do not smuggle a sequel into a bug ticket.

The short answer

• Four models, four invoices. Self-serve CMS, ticket hours, retainer, new sprint. One line that says “edits” for all four is how buyers get burned.
• Warranty is defects, not desire. If it never matched the spec, it is a bug. If you changed your mind, it is billed.
• Self-serve is free studio labor only at the field layer. Locked copy, images, dates, CMS items. Not new sections, not new collections, not a fold rewrite.
• The SLA is the product you are buying after launch. Channel, named requesters, ack time, turnaround by class, cap, overage path. A handshake is not an SLA.
• Sprint when the product changes. New page type, new motion, new merch module, new conversion path. Tickets are for the film that already shipped.

What counts as an edit after launch?

An edit is a change to a launched system. It is not automatically included, and it is not automatically billed. Classification comes first. Money follows the class.

AIGA’s Standard Form of Agreement for Design Services treats client additions as change orders: the designer describes extra time and money, the client signs, the change order is invoiced separately. The Graphic Artists Guild’s website design and maintenance order form is blunter still: maintenance may cover errors versus spec; it “shall not include the development of enhancements to the originally contracted project.” That is the spine. Enhancements are a second product.

Class	What it is	Who does it	How it bills
Warranty defect	Launched behavior that does not match the signed spec	Studio, inside a named window	Included. Clock it anyway so the window does not become infinite.
Self-serve CMS	Copy, images, dates, collection items in existing fields	Your named editor	Platform seats, not studio hours — if the field exists.
Ticket	Small change that needs a designer or engineer, still inside shipped recipes	Studio, against a cap	Hours or a prepaid block. Change order if it exceeds the cap.
Retainer draw	Ticket-class work against prepaid capacity and a written SLA	Studio, on a cadence	Monthly (or term) fee. Unused capacity is not a feature factory unless the SOW says so.
New sprint	New recipe, new motion, new IA, new conversion path, new integration	Studio, scoped	Fixed fee or milestones. Not a “large ticket.”
Commerce admin	Price, inventory, variants, discounts	Whoever owns the cart admin	Shopify (or equivalent) labor, not a website ticket — see the merch split below.

If you cannot point at a row, stop. Classify before anyone opens the CMS.

Checklist before you call a message “an edit”:

• The URL is live in production, not a staging wish
• You can name the field, component, or page that should change
• You can say whether the launched spec already included this behavior
• You know who is allowed to request it
• You know which invoice class it is before work starts

Tour dates on an artist site are CMS edits. A new homepage recipe is a sprint. A button that never submitted is a defect. “Can we make the hero feel more expensive” is taste. Taste is not a bug.

Self-serve CMS, ticket hours, retainer, or a new sprint — which invoice is this?

Pick the model from the job, not from which word sounds friendlier. “Retainer” is not a personality. “Hourly” is not a moral failure. “Sprint” is not a punishment. Each one is a different object.

Model	You are buying	It fits when	It fails when
Self-serve CMS	Editor access + locked fields + a one-page guide	Weekly copy, dates, stills, posts, merch links	The homepage is a freeform page builder
Ticket hours	Capped, classified change requests	A few designer touches a month, irregular	Slack becomes an open tab and nobody caps it
Retainer	Prepaid capacity + SLA + a named cadence	You know you will keep shipping on the site	You bought it to “have someone” and then invent work
New sprint	Scoped product change with a start and an end	The request changes recipes, motion, IA, or integrations	You nickel-and-dime a rebuild through tickets

Spurlock Studios publishes Website Studio as optional after a build — Maintain, Grow, and Lead on /websites. As of September 2026, the live list is $3,000 / $7,500 / $15,000 per month on monthly billing, with term discounts on the same page. Those are this studio’s SKUs. They are not “the market.” I will not invent an industry hourly and pretend it is physics. Ask that studio for that rate card. Label any hour bands in this post as planning.

Procedure to choose in one sitting:

1. List last quarter’s real change requests. If you have none, you do not have a data problem — you have a guess.
2. Sort each request into the table above. Be cruel about “sprint.”
3. Count how many needed a designer versus a field.
4. If almost everything was a field, buy training and seats. Do not buy a retainer to press Publish for you.
5. If you needed a designer every week, price a retainer or a block. If you needed a new recipe twice, you needed sprints and you billed tickets instead.

The Website Direction Sprint on the same offer page is a pre-build product: $1,500, five business days, credit toward a build started within 90 days. It is not your post-launch edit SLA. Do not use “sprint” for both objects in the same email without naming which one you mean.

How does self-serve CMS billing actually work?

Self-serve means the studio already built the field, the role, and the guardrail. You type. You publish. You are not buying hours. You are buying a system that survives Tuesday night.

Webflow’s content editor role is explicit: editors update copy, media, and CMS items; they cannot change design, component structure, page slugs, custom code, or collection schema. Webflow’s Designer role is the other door — layout, classes, new collections. Hand a client Designer because “it’s easier” and you have not given them self-serve. You have given them a loaded gun aimed at the type system.

Framer’s member roles make the same split: Content Editors manage CMS, localization, and on-page editing; Editors can touch design. Viewers are free; edit rights are billed seats. Read the Framer pricing page the week you budget — seat prices move.

On a custom Astro (or similar) shell, self-serve is often content collections in a repo, or a headless CMS with locked schemas. If the only editor is the developer, do not fake a “client CMS” nobody will open.

Surface	Self-serve	Not self-serve
Headline in an existing field	Yes	Rewriting the fold composition
Project still, required ratio	Yes, if the field rejects a bad crop	Freeform hero with no ratio lock
Blog / news item in a collection	Yes	A new collection type
Tour date row	Yes	A new tour widget with video
CTA label and href	Yes	A third button style
Alt text	Yes, and it should be required	“We’ll do alt later”
New page from an existing recipe	Sometimes, if duplicate is a first-class action	A seventh recipe “because it would be cool”

Merch is the split people miss. Price, inventory, variants, and discounts belong in Shopify admin product edits, not in a website ticket. The artist site is the brand surface; the cart is the cart. That architecture is Shopify or the site for merch. Changing a deep link, a Buy Button, or a still on the brand site is a website edit. Changing the SKU price is Shopify. Do not pay a designer to type into the wrong admin.

Self-serve publish procedure:

1. Confirm the field exists. If you need a new field, that is a ticket to the person who owns the schema.
2. Use the editor role, not Designer / full canvas.
3. Swap the copy or still. Keep the crop, the alt, and the CTA style.
4. Preview. If the CMS has no preview, you do not have self-serve — you have production roulette.
5. A named person publishes. “Whoever saw the Slack” is not a name.
6. If the change needs a new section, stop. That is not this model.

Checklist that the CMS is actually self-serve:

• Named editor can log in without the studio
• Homepage cannot gain a random section
• Image fields enforce ratio or reject the upload
• Primary and secondary CTA styles only
• Alt text is required
• A one-page editing guide exists, and someone opened it after training

Unused CMS is dead weight. Training that nobody repeats is a costume. Self-serve that can break the grade is not cheaper. It is deferred sprint work with extra steps.

How do ticket hours get requested, capped, and billed?

A ticket is a classified change that needs studio hands and still fits the shipped film. It is not an open Slack tab. It is not “quick.” Quick is how caps die.

AIGA’s change-order language is the operating move: describe the extra time and money, get an authorized signature, invoice the change order separately. You can do that in a shared tracker. You cannot do that in a voice note.

Ticket class (planning)	Examples	Planning time band	Usually bills as
A — locked field, studio-operated	You refuse to log into the CMS; we change a date	Fraction of an hour to ~1 hour	Smallest unit on that studio’s card
B — inside a shipped recipe	Swap a still that needs compression, crop, alt	~0.5–2 hours	Ticket
C — layout inside an existing section	Reorder blocks, fix a wrap, adjust a spacing token	~1–4 hours	Ticket, watch the cap
D — new instance of an existing recipe	One more case study page from the template	Hours that should be quoted, not guessed	Ticket or small fixed fee
E — new recipe / motion / path	New fold, new collection, new integration	Not a ticket	Sprint. Stop.

Those hour bands are planning, not a rate card and not a market survey. Apply that studio’s published hourly or block price. I will not invent $X/hour as “what agencies charge.”

Ticket procedure:

1. Request lands in the named channel (tracker, form, or email). Slack is allowed only if the thread is copied into that channel the same day.
2. Studio classifies A–E in writing. E is a sprint quote, not a polite delay.
3. Estimate goes back: time band, cap impact, staging vs production.
4. Named requester approves in writing. No approval, no work — except warranty defects that block the primary action.
5. Work happens on staging. Production publish is a named step.
6. Invoice (or block decrement) cites the ticket id. Leftover feelings do not roll into next month as “we still owe you a feature.”

Cap rules that keep tickets from becoming a shadow retainer:

• Monthly hour or ticket cap is a number, not “reasonable”
• Unused tickets do not automatically become new pages
• Overage needs a written yes before the extra hour starts
• Rush / after-hours is a multiplier the SOW names, or it does not exist
• Third-party product tickets (Shopify theme, ads pixels, ESP) are marked as such — different admin, different clock

Failure mode I will not romanticize: a client pings “tiny change” fourteen times. Each one is twenty minutes plus context reload plus a production check. That is not fourteen tiny changes. That is a retainer you refused to name, billed as surprise overtime. Put a cap on it or stop offering tickets.

How does a retainer bill edits without becoming a hostage?

A retainer is prepaid capacity plus an SLA. It is not a hostage fee for keeping the site online. Ownership means you could fire the studio and the site would still build. If ending the retainer turns the site off, you did not buy care. You bought a lock.

What the monthly fee is for has to be a list, not a mood. Spurlock Studios’ published Website Studio ladder (verify on /websites the week you budget):

This studio’s SKU (Sep 2026 list)	Edit-shaped promise on the offer page	Not this SKU
Maintain · $3,000/mo monthly	Content updates, small page fixes, health checks, hosting/dependency hygiene, a call every two weeks	A new campaign site every week
Grow · $7,500/mo monthly	Landing pages, experiments, campaigns, conversion reporting, plus Maintain	An unbounded product roadmap
Lead · $15,000/mo monthly	Embedded cadence: continuous launches, CRO, creative, analytics	A second company, staffed by one invoice line

Term discounts (25% off at three months; annual stacks two months free on this studio’s page) change the cash, not the object. Other studios will quote other numbers. Treat every dollar figure here as this studio’s published list, planning until you re-read the page.

Retainer must name	Healthy version	Hostage version
Capacity	Hours or ticket classes per month	“We’ll handle it”
Unused time	Expires, banks a small named amount, or converts by written rule	Guilt inventory you argue about in month six
New recipes	Quoted as sprints even during a retainer	Swallowed until the studio is underwater
Who publishes	Named roles	Whoever has the password this week
Exit	You own accounts; retainer is optional	DNS sits in a personal login

Retainer operating cadence (planning — rewrite the days to match the SOW):

1. Requests close at a weekly cutoff in the named timezone (this studio defaults to America/New_York).
2. Classification happens on a named day. E-class items get a sprint quote, not a smile.
3. Work ships to staging in a batch, not as fourteen production hotfixes.
4. You review on a named window. Silence is not a secret third round.
5. Production publish is scheduled. Emergency is defined (site down, form dead, checkout broken) — a headline preference is not an emergency.
6. Monthly report lists tickets, classes, cap used, cap left, and sprint quotes opened.

Checklist before you sign a retainer for edits:

• The build already launched. You are not prepaying to finish the original scope.
• Accounts are yours (domain, host, CMS, analytics, Search Console).
• The SLA page is attached, not “we’ll send it later.”
• Sprint trigger examples are written with real requests, not adjectives.
• You can pause or end without the site going dark.

If you need one copy change a quarter, a retainer is theater. Buy a ticket block, or log into the CMS.

When is a new sprint the honest next invoice?

A sprint is the honest invoice when the launched film cannot absorb the request without a new recipe. Tickets keep the current production running. Sprints shoot a new scene.

This is the same split as when a custom website is worth it: you do not buy a rebuild because “custom” sounds expensive. You buy the smallest scope that removes the cap. After launch, the cap is often the edit model, not the original stack.

Signal	Stay on tickets / retainer	Quote a sprint
Copy in existing fields	Yes	No
One more work item in the same grid	Yes	No
Fold is the leak (title card, CTA, proof)	Maybe a tight sprint	Yes if composition changes
New collection / new page type	No	Yes
Motion budget / LCP pass	Only if it is repair vs spec	Yes if you are adding a scene
New integration (CRM, booking, merch embed)	No	Yes
IA is a junk drawer	No	Rebuild or a real IA sprint
Merch checkout path is wrong	Brand-site module = sprint; SKU = Shopify	Do not ticket a cart into a CMS

Post-launch sprint procedure:

1. Write the job in one sentence a non-designer can argue with. “Make it pop” is not a job.
2. Name the pages, the recipe you will add or replace, and what is explicitly out.
3. Name the edit model after this sprint ships (fields you will lock so this does not repeat).
4. Fixed fee or milestones. Not “we’ll track hours and see.”
5. Staging, then a hard launch checklist for the new surface (form, OG, mobile CTA).
6. Close the sprint. Leftover ideas go to the backlog, not into unpaid polish.

Do not confuse three different “sprints”:

Name	What it is on this site	When you buy it
Website Direction Sprint	$1,500 pre-build concept, 5 business days, 90-day build credit	Before you buy a build
Post-launch edit sprint	Scoped change to a live site	When tickets cannot hold the request
Original build	Creator / Business / Product tiers on /websites	The first film, not a change order

If a vendor calls every week of retainer a “sprint,” ask them to show the start, the end, and the leftover that will not be done. Infinite sprint is a retainer in a hoodie.

What should the edit SLA say in writing?

The SLA is the only artifact a model will quote besides your price. If it is missing, you do not have an edit process. You have hope.

Numbers below are planning examples, not a market SLA and not a promise until they are in your SOW.

Clause	What to write	Failure if missing
Channel	One tracker or form. Slack is a copy destination, not the system of record.	“I sent it in iMessage”
Named requesters	Two humans, max, who can authorize spend	Fifteen stakeholders, none of whom can say yes
Business hours	Days + timezone	A Friday 11pm “quick one” billed as normal
Acknowledgement	e.g. next business day (planning)	Requests vanish
Turnaround by class	A/B vs C vs “sprint quote in N days” (planning)	Everything is due tomorrow
Revision rounds	e.g. one round per ticket unless defect	Infinite taste
Cap	Hours or tickets / month	Shadow retainer
Overage	Written approval + rate or block	Surprise invoice, then a fight
Emergency	Site down, TLS dead, form not delivering, checkout broken	Headline preference wearing a siren
Staging vs production	Two URLs, one publish owner	Live edits on the fold during a launch
Warranty window	Start date, end date, what “defect” means	Forever support by implication
Exit	Who holds credentials on day 1	Care as ransom

Ack and turnaround planning bands I use when I have to put something on paper — rewrite them, do not treat them as physics:

Class	Planning ack	Planning done-on-staging
Emergency (defined above)	Same business day in-hours	Hours, not days, if the rollback exists
Warranty defect	Next business day	Inside the warranty window, queued ahead of taste
A/B ticket	Next business day	1–2 business days if the cap has room
C/D ticket	Next business day	3–5 business days, or “this is a sprint”
E / sprint quote	Next business day	Quote in a named handful of business days, then a separate schedule

Procedure to install the SLA in a week:

1. Paste the clause table into the SOW. Fill every cell. Blank cells are fights.
2. Create the tracker. One inbox. Disable the unofficial ones or they will win.
3. Train the two named requesters, not the whole company.
4. Run a dry-ticket: a fake date change, classified, staged, published.
5. Write down how long it actually took. If it cannot survive a dry run, it will not survive a real drop.
6. Put the warranty end date on a calendar with the client’s name on the invite.

Timezone default for this studio is America/New_York. If your team is not, write yours. Unnamed timezones turn “next day” into an argument.

Warranty, bugs, and taste — who pays?

Warranty is workmanship versus spec. It is not a personality. It is not “we’ll take care of you.” It is a clock.

The Guild form fills in a Warranty Period as dates, then caps unpaid support hours inside that period, then sells maintenance after it. Contractable and similar practice notes often show short windows (sometimes 14–30 days, sometimes ~90). Those are examples in the wild, not a law. Name your days. I will not invent a universal “30-day industry standard.”

Pays as warranty	Pays as a ticket / retainer / sprint	Pays as “you did this”
Form never delivered on the launched path	New form fields you asked for after launch	Client (or a plugin) broke the embed
CTA missed the spec breakpoint	New CTA style	Someone published a third button from Designer
Crop that shipped wrong vs the art direction	New photography direction	Editor uploaded a 200px still into a cinema slot
Spec said tap-to-call; the number was not a tel: link	Adding a second phone number and a chat widget	You changed the number in a PDF and not in the CMS
Motion left elements at opacity: 0 with reduced motion on	A new pinned scene	A third-party chat script tanked INP after you added it

Taste is the expensive confusion. “Can we try it in serif” after you signed the type system is a sprint or a hard no. It is not a defect. “The headline feels off” with no spec miss is a revision round you either already bought or you did not.

Warranty intake procedure:

1. Reproduce on production with a URL, device, and browser. Screenshots without URLs are folklore.
2. Diff against the signed spec / accepted staging. If it never shipped, it is not a warranty miss — it is unfinished scope, which is a different fight.
3. Check whether a client edit, a plugin, or a host change landed after launch.
4. If it is a defect inside the window, fix on staging, then production. Do not “while we’re in there” a taste pass.
5. If it is outside the window, classify A–E and bill that class.
6. Log the incident. A warranty with no log is how windows become folklore.

Checklist for the warranty paragraph itself:

• Start = hard-launch date (DNS cutover), not “when we felt done”
• End = a calendar date
• Defect = mismatch to spec, reproducible
• Exclusions = new features, approved-design changes, client edits, third-party outages, content updates
• Client-caused breakage is T&M or a ticket, named as such

Bravery is not a warranty strategy. Write the window.

What should the invoice actually show?

If the invoice cannot explain the class, the client cannot audit it, and you cannot defend it. Mystery time is how good work gets a reputation for nickel-and-diming — or for unpaid labor.

Line	Why it exists	What “good” looks like
Request id	Traceability	Same id in the tracker
Classification	Warranty / CMS assist / ticket class / retainer draw / sprint	One label, not three
Spec reference	Proves warranty vs taste	“SOW §3.2 form delivery” or “out of spec — new page type”
Time or block used	The number	Hours to a named increment, or 1 ticket
Cap remaining	Stops surprise	“3.5h of 6h left this month”
Rate or SKU	Money	That studio’s card, or “covered by Maintain”
Staging URL	Proof	Not “trust me, I did it”
Production URL + timestamp	Done means live	Timezone named
What was refused	Scope hygiene	“Asked for a new fold; quoted sprint SS-014”

Invoice hygiene procedure:

1. No work without a request id, except defined emergencies — and those get an id the same day.
2. Classification is visible to the client before the clock becomes money.
3. Warranty lines show $0 and still show time. Invisible warranty trains people to call everything a bug.
4. Sprint deposits follow the build’s payment pattern, not a ticket remainder.
5. Third-party pass-throughs (plugin, extra CMS seat, Shopify app) are separate lines. Do not bury a seat tax inside “edits.”
6. The monthly retainer invoice lists draws against capacity. A retainer invoice that only says “care” is how you hide a sprint.

Planning — not a market rate: if a studio sells blocks, sell them as blocks (e.g. a 5-hour pack) with an expiry. Open-ended hours with no expiry is a retainer you were afraid to price.

Checklist the client should demand:

• Every billed hour maps to a request
• Warranty is visible and $0
• Seats and apps are not labeled as design labor
• Sprint quotes are their own documents
• You can reconstruct last month from the invoice without a call

If they cannot reconstruct last month, the SLA is theater.

What usually fails first when the handshake was “we’ll handle it”?

The first failure is classification, not craft. The site still looks expensive. The process is folklore. Then a date is wrong in public.

Concrete failure: an artist launches. Training happened. Nobody named a requester. A manager DMs a new tour date. The studio is in another build. Two weeks later a city is stale. A fan plans around the wrong night. The manager calls it a website failure. The studio calls it an unbilled Slack message. Both are right. The missing artifact is the SLA.

Second failure: Designer-level access handed out as “self-serve.” Someone duplicates a homepage section, breaks the type ramp, and publishes. Now you have a sprint disguised as a content edit, plus a fight about who pays to restore the grade.

Third failure: tickets with no cap. Month three is a rebuild of the offer page billed as fourteen “quick” changes. The invoice looks predatory. The hours were real. The model was wrong. It should have been a sprint on week one.

Fourth failure: retainer as unfinished build. Original scope still leaks. Monthly fee becomes free completion. The studio drowns. The client thinks they bought unlimited. Nobody is lying. The SOW never said “launch means accepted spec.”

Symptom	Actual miss	Fix
Stale tour date / stale price	No named editor, or merch price edited on the brand CMS	CMS for dates; Shopify for SKUs; named publisher
Surprise invoice	No classification before work	Change order, even if it is one paragraph
“They never do anything” retainer	No weekly cutoff, no report	Cadence or cancel
Broken fold after “a copy tweak”	Editor had canvas access	Role demotion; restore from last good deploy
Forever warranty	No end date	Write the date; bill after it
Conversion still dead	Edits are taste, not the path	Stop ticketing. Sprint the fold or the ask.

Recovery procedure after the first fight:

1. Freeze unofficial channels. One inbox.
2. Restore last good production if the grade is broken. Do not “fix forward” on a smashed type system.
3. Write the classification table into an addendum. Sign it.
4. Re-train on the editor role. Revoke Designer.
5. Quote the actual product change as a sprint, separate from the apology.
6. Put warranty end and cap remaining on a shared calendar.

I have shipped hundreds of production sites. The ones that stay film-grade after premiere are boring about this table. The ones that rot had a warm handshake and a CMS nobody owned.

How do slow or unpaid edits leak conversion?

Conversion dies when the live path is wrong — not when the invoice is late. A cinematic fold with a “Coming soon” CTA, a dead form, or last month’s drop is a trailer for a film that already left theaters.

I will not invent a percentage lift for “faster tickets.” I will tell you what to walk with one thumb.

Live miss	Conversion leak	Edit class that should have caught it
Tour date wrong	Fan trust, then a public correction	Self-serve CMS, same day if you have a publisher
Merch price wrong on site vs cart	Abandoned checkout, support load	Shopify admin, not a Webflow field
Primary CTA still campaign-expired	Taps go to a 404 or a closed form	Ticket or retainer with a campaign off-ramp
Form to /dev/null	Zero leads; traffic looks “fine”	Warranty if it never worked; emergency if it breaks later
Proof stills from a dead offer	Skeptics bounce	Ticket inside the recipe, or a sprint if the proof model is wrong
Phone number as text, not tel:	Missed calls on job-site phones	Warranty if spec required it; ticket if you added SMS later

Phone procedure (do this monthly even if nobody requested an “edit”):

1. Land on production, not staging.
2. Say the offer out loud from the first screen.
3. Complete the primary action on cellular.
4. Check the one thing that changes weekly (dates, inventory, booking slot, price).
5. File a ticket only if a human cannot fix it in the CMS / cart admin.

If step 4 is always a designer, your self-serve model is fake. If step 3 fails, stop buying taste tickets. You have a path problem. Path problems are sprints — or they are the original fold job you never locked. See the pillar for the title card. This post will not restyle your hero in a 45-minute ticket and call it conversion work.

Campaign off-ramp checklist (the unpaid-edit leak I see on otherwise good sites):

• Every campaign CTA has a kill date
• After kill, the field reverts to the default ask
• Landing pages 301 or 410 on purpose, not by neglect
• OG image is not last season’s drop
• Merch sold-out state lives in Shopify, not as a Photoshop banner on the artist site

Slow SLA on a stale date is a conversion incident. Slow SLA on a serif experiment is a preference. Bill them differently or you will prioritize the wrong fire.

What should you ask a designer before you sign?

Ask for the edit model in writing before you accept launch. After launch, you are asking as a customer of a second product.

Question	A real answer sounds like	A dodge sounds like
What is self-serve the Tuesday after launch?	Named role, named fields, one-page guide, preview	“The CMS is really intuitive”
What is warranty?	Dates, defect definition, exclusions	“We take care of our clients”
How do I request a paid edit?	URL to a form or tracker	“Just text me”
What is the cap?	A number and an overage path	“Reasonable use”
When do you refuse a ticket?	Examples of sprint triggers	“We can do anything monthly”
Who owns accounts?	You, listed	“We handle hosting” with no login
How are merch / shop edits split?	Cart admin vs brand CMS	“We’ll update products in Webflow”
What do I see on the invoice?	Classification, ids, cap remaining	A single line, “web services”

Procedure for the signature meeting:

1. Walk the classification table with a red pen. Fill every row with an example from your business (tour date, HVAC special, drop price, booking close).
2. Demand the SLA clause table, even if the numbers are still planning bands you will negotiate.
3. Log into the editor role on staging before you accept launch. If you cannot publish a safe copy change, launch is not done.
4. Revoke extra Designer seats the same day.
5. Write the warranty end date into the calendar.
6. If they will not classify, do not buy post-launch hours from them. You will pay twice: once in cash, once in fights.

If you are still deciding whether the site should be custom so that self-serve cannot trash the fold, that is the threshold test in when a custom website is worth it. Paying five figures for a page builder and then buying tickets to undo editor chaos is how you rent a costume twice.

How do you pick a model in one meeting?

Bring last quarter’s requests, or admit you are guessing. Guessing is allowed. Pretending a guess is a measurement is not.

Decision list:

1. Zero designer touches, weekly field edits. Self-serve only. Pay seats. Pay training. Do not pay a retainer to be a very expensive Publish button.
2. A handful of designer touches, irregular. Ticket block with a cap. Review after 90 days. If you blow the cap twice, you do not have a ticket problem.
3. Weekly designer shipping, same recipes. Retainer. SLA. Report. Sprint quotes for new recipes still exist.
4. The fold, the IA, or the stack is the request. Sprint or rebuild. Tickets will launder a rebuild into a bad marriage.
5. Merch / cart is the request. Shopify admin first. Brand-site module only if the embed, still, or deep link is wrong.

One-page chooser:

If this is true	Buy	Do not buy
You will not log into anything	A ticket block, and raise the price — you are buying operator time	“Self-serve” you will never use
You will log in weekly	Seats + locked fields	A designer on a pager
You will ship pages monthly	Grow-class retainer or a cadence of sprints	Hourly with no cap
You need a new film	A scoped sprint	Fourteen tickets named after scenes
You need the site to stay up, not to change	Keep-alive care (different contract)	Edit hours mixed into uptime

Close the meeting with artifacts, not adjectives:

• Classification table initialed
• SLA clauses filled (even if some cells say “n/a — self-serve only”)
• Warranty dates on a calendar
• Named requesters and named publisher
• Editor role confirmed; canvas access revoked for non-designers
• First dry-ticket scheduled
• Merch vs brand-site admin named if commerce exists

If you walk out with “we’ll stay flexible,” you bought the failure mode. Flexibility without a class is how billed work becomes a grievance.

FAQ

How do edits work after launch, and how am I billed?

You are billed by class: self-serve CMS at the field layer, capped ticket hours for small studio work, a retainer for prepaid capacity with an SLA, or a new sprint when the product changes. Warranty covers reproducible defects versus the signed spec for a named window. New copy, new pages, and taste are not warranty. If the class is not written down before work starts, the invoice will feel like a surprise even when the hours were real.

How do I measure whether the post-launch edit SLA is working?

Measure it like an operations contract, not like a vibe. Track request-to-ack time, class accuracy (how often an “A” became an “E”), cap used versus cap bought, production incidents caused by editor-canvas mistakes, and whether the primary conversion path still completes on a phone after changes. If stale dates and dead CTAs linger past the stated turnaround, the SLA is failing even if everyone is “busy.” If you have no tracker, you are not measuring — you are remembering.

What usually fails first when teams try this?

Classification fails first: unofficial channels, unnamed requesters, and Designer access handed out as self-serve. The first public miss is often a stale date, a wrong price, or a fold someone “just tweaked.” The first financial miss is either a surprise invoice or a studio eating sprint work as tickets. Fix the inbox, the role, and the class table before you buy more hours.

How long does this take to show results?

The SLA should be testable in a week: dry-ticket, staging, publish, restore path. Warranty is a calendar window, not a feeling — often weeks, not a year, when people actually write dates (planning, not a law). Retainer value shows up over a month of cadence; a sprint shows up when that scoped surface is live. If someone promises “you’ll feel it immediately” with no dry run, they are selling mood.

What should I skip if I only have a week?

Skip the retainer, the motion pass, and the new page type. In a week you can name two requesters, lock editor vs designer roles, write warranty dates, stand up one request channel, run one dry-ticket, and split merch admin from brand CMS if you sell goods. That is the operating kernel. Capacity products come after the kernel exists, or you will pay monthly for folklore.

When is this not worth doing yet?

If the site has not launched, you do not need an edit SLA — you need to finish the build and accept a spec. If you cannot name a publisher and you refuse to log in, self-serve is a lie; buy tickets or delay launch until someone owns Publish. If the real problem is a rotten IA or a template that cannot lock fields, quote a sprint or a rebuild. An SLA on a costume just invoices the unraveling.

CTA

If launch is done and the next argument will be about a “quick change,” stop arguing. Classify the request, then buy the matching invoice.

Explore /websites or book a Website sprint at /contact?intent=websites-sprint.