What should a Shopify maintenance retainer cover?

Start with the workload you actually need covered

Review recent requests and upcoming work over a period that represents your operation. Group tasks by the system involved, frequency, urgency, business effect, and person who approves them. Include seasonal campaigns and known update work so a quiet month does not become the entire buying assumption.

Separate three needs: keeping existing behavior working, making bounded improvements, and delivering a project with its own discovery and acceptance. Examples might be diagnosing a broken product template, adjusting an agreed campaign module, and rebuilding the navigation. Ask each supplier to classify those same examples as included, excluded, or separately estimated.

A retainer can suit recurring work and a need for continuing context or reserved availability. A defined project can suit a finite outcome. Ad hoc help can suit occasional tasks when waiting for availability is acceptable. Compare actual proposals and operating needs; no universal monthly-hours threshold makes one model cheapest.

Identify who can change each system

Shopify includes commerce hosting and a TLS/SSL certificate with its hosted plans, as described in its pricing FAQ. Ask a supplier to name the separate service behind any hosting or certificate charge. An external application, integration host, or headless frontend can have different operating costs and responsibilities.

Theme support depends on who made the theme. Distinguish a theme-maker support request from paid customization, compatibility work, and code commissioned from your developer. Ask who investigates an issue spanning those boundaries and who keeps the merchant informed.

Shopify’s app guidance assigns unsupported-app updates to the app’s developer and states that Shopify cannot update a third-party app for you. A support provider can own investigation and vendor coordination without controlling the vendor’s fix. State the available fallback and the person allowed to approve it rather than promising control that the provider does not have.

Use one row per task and dependency

This is a procurement template, not a declaration that every supplier performs these tasks. Fill the support contact, included work, exclusion, evidence needed, and fallback for each row. Add an accountable coordinator when several vendors are involved. “Not our app” should not leave the merchant guessing who owns the next step.

For a custom integration, name the code repository, host, API dependency, alert recipient, and access owner without placing credentials in the workbook. Ask whether version compatibility, logs, deployment, and incident investigation are part of maintenance or separately priced. Include continuity when the original developer is unavailable.

Convert headline hours into planned delivery capacity

For an hours-based offer, list everything charged to the allowance: meetings, reporting, discovery, estimates, testing, reviews, release coordination, incident handling, and direct implementation. Ask about minimum billing increments, rounding, multiple people attending the same meeting, and whether project management is inside or outside the bank.

Use this planning identity: planned delivery allowance = nominal bank − charged overhead − agreed incident reserve. It allocates the bank before work is promised; it is not a productivity measure. Testing that is included inside delivery still consumes time. Do not compare a development-only estimate with an allowance that also has to cover review and release.

For a capacity-based or fixed-outcome offer, ask which requests can run concurrently, how the queue works, what sizes qualify, and how acceptance is defined. “Unlimited requests” is not a definition of throughput. Convert the terms into the same task examples and planning period used for the other offers, leaving unknowns visible.

Separate acknowledgment, work start, and resolution

Record coverage days, hours, time zone, holidays, request channel, and the condition that starts each clock. Translate the window into your team’s working hours and include daylight-saving changes where applicable. A supplier’s “same day” is ambiguous until both parties know which day and which cutoff.

• Acknowledgment: someone confirms receipt and identifies a next step.
• Triage or work start: someone begins investigating under the agreed priority.
• Workaround: a temporary, approved way to reduce the immediate effect.
• Resolution: the agreed behavior is restored and verified.

Ask whether the promise measures business hours or elapsed hours, what happens outside coverage, and how vendor delays are reported. Define incident severity using observed consequences. An inability to purchase needs different routing from a small spacing request. A low-severity label should not hide a serious operational effect.

For monitoring, name the actual checks, frequency, notification route, recipient, and actions after an alert. Ask which failures the checks cannot see. An alerting service needs an incident owner; it should not be described as proof that orders can never be lost.

Agree how incidents displace planned work

Give one merchant contact authority to reprioritize the queue and one provider contact responsibility for explaining the effect. When an incident uses reserved or additional capacity, record the work paused, remaining allowance, next checkpoint, and any cost approval needed. Avoid continuing the original delivery promise after its capacity has been consumed elsewhere.

Set the overage rule before an incident: who may authorize it, the rate or charging basis, any cap, and whether the provider stops or escalates when the bank is exhausted. Confirm whether after-hours work is available at all and under what separate terms. Do not infer emergency coverage from a priority-support label.

Ask what happens when the provider is unavailable, when an external vendor blocks progress, and when the incident outlasts the period. The answer should identify ownership and communication even when a resolution time cannot responsibly be promised.

Define acceptance and release authority for small work too

For each request, agree on the intended result, affected surfaces, expected states, and acceptance owner. The developer should describe the change and evidence. The merchant should confirm the business behavior and approved content. State who can publish, which changes require explicit approval, and how recovery is authorized.

A brief change record can include the request ID, candidate/version, source changes, test evidence, decision, release time, and recovery reference. Match the depth to the consequence. A text edit and an integration that writes order data need different review, but both need a recognizable owner.

For a customized theme update, agree the preservation scope and compatibility work separately. Shopify’s update documentation shows that the route depends on source and customization. A monthly allowance does not establish that a particular version upgrade is trivial or included. Ask the supplier to classify the actual update before scheduling it.

Resolve rollover, extra charges, and exit before comparing value

Record whether unused capacity expires or rolls over, the maximum balance, use order, validity period, and treatment on cancellation. Ask whether a rolled balance changes reserved availability or simply adds work to the same queue. Put a worked example into the proposed terms so both sides interpret the rule the same way.

Separate the service fee from app subscriptions, usage charges, paid tools, external hosting, and approved overage. Shopify notes that some third-party app charges are billed outside its invoice. Reconcile those vendor terms instead of assuming a maintenance payment includes them.

Write down billing currency and period, taxes as specified in the offer, notice and pause terms, unfinished work, refunds or credits if offered, and the exit handover. Request source and access continuity, open incidents, dependency contacts, current configuration references, and accepted/unaccepted work. Resolve unclear contract language with the relevant adviser rather than relying on a sales summary.

Ask for a report that closes the operating loop

The report should show the opening allowance, work and overhead charged, incident use, accepted outputs, remaining or expiring balance, blocked work, and next owner. For each completed task, include the acceptance reference. For a vendor-blocked issue, include the next follow-up and any merchant decision needed.

Compare the report with the original plan. Repeatedly unused capacity may mean the allowance or intake process needs changing. Repeatedly displaced improvements may mean more incident reserve, a separate remediation project, or a revised delivery promise. Do not equate hours consumed with business value: a correctly resolved dependency can matter more than a long list of minor edits.

Send the same responsibility and capacity table to each supplier and ask them to mark every cell with a term or “needs agreement.” Once the unknowns are closed, choose the arrangement that matches your workload and continuity needs. If the work is finite or infrequent, keep the project and ad hoc alternatives in the comparison.