Shopify Retainer Scope Template (Maintenance & Support)

Retainers work when the scope is explicit.

The problem is that “support” is not a service category. It’s a bucket.

To a client, support might mean:

• content updates
• urgent bug fixes
• CRO experimentation
• new features
• performance work
• app changes
• data work

To an agency, those are different workstreams with different skills, risk, and lead times.

If you don’t define the rules of the retainer (what’s included, how requests are submitted, response times, rollover, and what becomes a new scope), you end up renegotiating every month—usually after you’ve already done the work.

Below is a copy/paste Shopify retainer scope you can use in Google Docs today.

If you want it to assemble automatically from package options (so inclusions/exclusions stay consistent across your team), RuleDox can generate a near-complete retainer scope draft inside Google Docs.

Assemble a retainer scope in Google Docs → https://ruledox.app/live-demo

---

• Shopify agencies offering ongoing maintenance, support, or growth retainers
• Teams that need consistent SLAs and boundaries (not “whatever comes in”)
• Agencies that want retainers to be delegable without quality drift

• Clients expecting unlimited work for a flat fee
• Teams without an agreed request intake workflow (email chaos = scope chaos)

---

These rules are also your core scope creep prevention mechanism on retainers.

1. Define the package (hours and/or included deliverables)
2. Define the request system (how work enters the queue)
3. Define SLAs (response vs resolution; business hours vs after-hours)
4. Define inclusions/exclusions (examples, not vague categories)
5. Define change triggers (what becomes a new project scope)

---

Client: [Client name]

Service: Shopify maintenance & support retainer

Start date: [date]

Term: [month-to-month / 3 months / 6 months]

Primary objective: [e.g., keep the site stable and ship a steady cadence of improvements]

Choose one primary model (or combine with care).

Option A — Hours-based retainer

• Included hours per month: [X]
• Included roles: [e.g., Shopify dev, QA, PM]
• Hour tracking and reporting: [how it’s reported]

Option B — Deliverables-based retainer

• Included deliverables per month/quarter: [explicit list]
• Included templates/areas: [PDP, collection, cart, content]

Option C — Hybrid

• Base hours: [X]
• Included deliverables: [Y]

Request channel: [ticketing system / email alias / shared board]

Every request must include:

• description of change
• affected URL(s) / template(s)
• expected outcome (“done means…”)
• priority level [P1/P2/P3]
• deadline (if any) and business impact

Requests without required info may be returned for clarification.

• Work is prioritized jointly in a [weekly/biweekly] planning call OR async in the board.
• The agency is responsible for sequencing to balance urgency and risk.
• The client nominates an approver for requirements and acceptance.

Important: define response vs resolution.

Business hours: [e.g., Mon–Fri, 9am–6pm SGT]

Response targets:

• P1 (site down / checkout broken): respond within [X] hours
• P2 (major degradation / key bug): respond within [X] hours
• P3 (minor bug / small change): respond within [X] business days

Resolution targets:

• Resolution depends on complexity and may require estimate/approval.

After-hours/on-call:

• [Included/Not included]
• If included: define coverage window + rates + what qualifies

The following work categories are included (subject to available hours/capacity):

6.1 Storefront/content updates

• updating copy/images on existing pages
• adding/editing content pages using existing templates

6.2 Bug fixes

• fixing theme bugs introduced by updates or regressions
• resolving layout issues on defined templates

6.3 Small Shopify theme enhancements

• small UI tweaks to existing components
• minor section changes within agreed complexity limits

6.4 App configuration support (named apps)

• configuration changes for: [App #1], [App #2]
• basic troubleshooting coordination with app vendors

6.5 QA & release management

• staging review
• basic regression testing on impacted flows

Unless explicitly listed as included, the following are excluded:

• net-new feature builds requiring discovery/design (new project scope)
• major redesigns or replatforming
• custom app development
• complex data migrations or automation
• SEO strategy, link building, content production (unless explicitly included)
• third-party vendor work (photography, copywriting)
• emergency work outside business hours unless on-call is included

A change request / new project scope is triggered by:

• new template creation or major layout overhaul
• new integrations/apps not listed in-scope
• changes requiring design beyond agreed revision limits
• requirements that expand beyond available retainer capacity
• multi-stakeholder discovery needed to define “done”

When triggered, the agency provides:

• written scope addendum
• hours/cost estimate
• timeline impact
• approval required before starting

Choose one to avoid disputes.

• No rollover: unused hours expire at month end.
• Limited rollover: up to [X] hours can roll over for [Y] days.
• Banking for planned initiatives: hours can be banked for a defined initiative approved in writing.

• Update cadence: [weekly async update / biweekly call]
• Monthly report includes:
  • work completed
  • hours used (if applicable)
  • backlog status
  • risks/notes

• Staging environment: [details]
• Deployment process: [theme publishing / CI]
• Access requirements:
  • Shopify admin access
  • access to app accounts/licenses
  • access to domain/DNS (if needed)

Work is accepted when:

• change matches the request definition of “done”
• no critical regressions in agreed flows
• client approver signs off in the request system

---

Fix: include examples and boundaries. “CRO work” can mean anything.

Fix: define both. Some issues need investigation and approval.

Fix: no board/tickets = no scope. Everything becomes urgent and undocumented.

Fix: pick a policy. Otherwise every month becomes a negotiation.

---

Retainers are predictable when package rules are predictable.

RuleDox can assemble your retainer scope from package inputs—so every client gets consistent:

• SLA wording
• inclusions/exclusions
• change request triggers
• reporting cadence

Assemble a retainer scope in Google Docs → https://ruledox.app/live-demo

---

• Ongoing website management scope: https://ruledox.app/content/shopify/shopify-ongoing-website-management-scope
• Store build scope: https://ruledox.app/content/shopify/shopify-store-build-scope-of-work
• Theme customization scope: https://ruledox.app/content/shopify/shopify-theme-customization-scope

---

Hours-based is simpler to administer; deliverables-based is easier for clients to buy. Many agencies use a hybrid: a base hour allocation with clear included categories and explicit change triggers.

It depends on the client’s business risk. If checkout downtime is existential, define a P1 path and on-call coverage. If not, keep SLAs within business hours to avoid hidden operational costs.

By writing the change trigger section like you mean it: new templates, major UX changes, net-new integrations, and undefined workstreams require a separate scope.