Most Adobe Commerce support retainers are scoped too narrowly to deliver the operational value the retailer needs, or too broadly to be operationally sustainable for the agency. The result is retainer arrangements that produce friction on both sides – the retailer feeling that they are not getting the responsiveness they need, the agency feeling that the retainer is being used as a slush fund for unscoped work. The right scope conversation, done deliberately, produces retainers that work for both parties.
This article describes what should actually be in scope for an Adobe Commerce support retainer, what should be out of scope, what the common failure modes look like, and how to structure the retainer for operational sustainability. The framing is based on retainers we have run and retainers we have inherited from other agencies, where the post-mortem usually surfaces specific scope ambiguities that produced the friction.
What Should Be In Scope
The core of an Adobe Commerce support retainer should be production incident response. The retailer’s production storefront has operational issues – performance regressions, integration failures, payment processing issues, order workflow problems – that need expert response. The retainer should commit to specific response times (typically 15 minutes for critical incidents, 1 hour for high-severity, 4 hours for moderate), specific resolution timelines (typically 2 hours for critical incident triage), and specific on-call availability (typically 24/7 for critical, business hours for moderate).
The second in-scope category is security patching and version maintenance. Adobe releases security patches on a quarterly cadence, with emergency patches for critical vulnerabilities released between cycles. The retainer should commit to applying security patches within a documented window (typically 30 days for routine patches, 7 days for critical patches, 24 hours for emergency patches affecting active exploitation), with QA validation before production deployment.
The third in-scope category is small enhancement work that fits within a defined hours budget. The retainer typically includes a number of hours per month for small enhancements – configuration changes, content updates, minor feature additions, bug fixes that surface from ongoing operation. The hours budget should be sized to fit typical demand without becoming a slush fund for project work.
The fourth in-scope category is performance monitoring and optimization. The retainer should include ongoing CWV monitoring with monthly review, performance regression detection with proactive remediation, and quarterly performance audits with documented findings and recommended interventions. The scope should specify the tools, the review cadence, and the deliverables.
The fifth in-scope category is documentation maintenance. The retainer should include updates to operational runbooks, integration documentation, deployment procedures, and incident response playbooks as the storefront evolves. The documentation update cadence should be specified – typically updated alongside the work that changes the underlying systems, with a quarterly review to catch documentation drift.
What Should Be Out of Scope
The clarity about what is out of scope matters as much as the clarity about what is in scope. Project work – new feature development, major integrations, replatform projects, redesigns – should be out of retainer scope and handled as separate project engagements with appropriate planning, estimation, and pricing.
The boundary between “small enhancement” and “project work” should be defined explicitly. The typical pattern is that work estimated below a threshold (typically 8 to 16 hours) is in scope as a small enhancement; work above the threshold requires a project scope conversation. The threshold prevents the retainer from absorbing project work without proper planning.
Architectural changes should be out of retainer scope because they require deliberate design work that does not fit the retainer cadence. The retainer should support the existing architecture; the agency should propose architectural changes through project scoping that includes design discovery, implementation planning, and explicit go/no-go decisions.
Third-party vendor coordination beyond the agency’s direct work should be explicitly handled. The retainer typically includes coordination with integration partners for issues that touch the agency’s scope. The retainer typically excludes vendor management for relationships that the retailer owns directly. The boundary should be specified to prevent ambiguity during incidents.
What the Common Failure Modes Look Like
The most common failure mode is retainer scope creep. The retailer begins using the retainer for work that should be project-scoped. The agency accepts the work to maintain the relationship. The retainer’s hours budget gets consumed by project-flavored work, which leaves no capacity for the operational responsibilities the retainer was supposed to cover. When an operational incident occurs, the agency is overcommitted and the response is slower than the retainer promised. Trust erodes.
The fix is enforcing the scope boundary from both sides. The retailer should refrain from using the retainer for project work; the agency should refuse to absorb project work into retainer scope. The discipline requires explicit conversation at the start of any work item: “Is this in scope for the retainer? If not, let’s scope it as a project with appropriate planning.”
The second common failure mode is retainer underutilization. The retainer commits the retailer to a monthly spend regardless of consumption. In slow months, the unused capacity is lost. Over time, the retailer accumulates a sense that they are paying for something they are not receiving, and the relationship becomes contentious during budget reviews.
The fix is structuring the retainer with consumption flexibility. Some retainer arrangements offer roll-forward provisions where unused hours in one month carry into the next, up to a documented maximum (typically two months of accumulation). Other arrangements offer a smaller base retainer with explicit T&M billing for additional capacity. The structure should fit the retailer’s actual consumption pattern rather than forcing them into a fixed commitment that does not match reality.
The third common failure mode is response time deterioration. The retainer commits to specific response times but the agency’s resourcing erodes over time. The on-call coverage becomes less reliable. The senior engineers who handled incidents in year one are reassigned to other clients. The response capability is technically present but practically degraded.
The fix is monitoring response time performance against the SLA and addressing degradation directly. The agency should be reporting SLA performance monthly. The retailer should be reviewing the reports and escalating when performance trends down. The escalation conversation should result in resourcing changes that restore performance, not in justifications for the degradation.
The fourth common failure mode is the retainer becoming an excuse to defer proactive work. The retainer covers operations; everything else gets deferred to “when we have time.” Proactive performance optimization, architectural improvements, technical debt reduction, and capability building all get pushed off because the retainer doesn’t include them and project work is competing for budget. Over time, the storefront accumulates debt that compounds into operational fragility.
The fix is explicit proactive work scope within the retainer or alongside it. The retainer can include a documented allocation for proactive work (typically 25-35% of the monthly hours). Alternatively, the retainer can be paired with a quarterly project allocation specifically for proactive improvements. The structure prevents the storefront from accumulating debt while still serving its reactive operational needs.
What the SLA Structure Should Look Like
The SLA structure should specify response time, resolution time, and availability separately for each severity level. The structure should also specify the channels through which incidents can be reported (typically a ticketing system with email backup for critical incidents that arrive through other channels).
| Severity | Response Time | Resolution Target | Availability | Examples |
|---|---|---|---|---|
| Sev 1: Critical | 15 minutes | Triage within 2 hours, mitigation within 4 hours | 24/7 | Site down, checkout broken, payment processing failure |
| Sev 2: High | 1 hour | Triage within 4 hours, mitigation within 8 hours | Business hours, 24/7 escalation | Major performance regression, integration partial outage |
| Sev 3: Moderate | 4 hours | Triage within 1 business day, mitigation within 3 business days | Business hours | Specific feature broken, minor performance issue |
| Sev 4: Low | 1 business day | Triage within 3 business days, mitigation within sprint | Business hours | Cosmetic issue, edge case, enhancement request |
| Security patch | N/A | Routine: 30 days; Critical: 7 days; Emergency: 24 hours | Per cadence | Adobe security release |
The escalation path should be specified explicitly. Each severity level should have a documented escalation contact at the agency, a documented backup contact if the primary is unavailable, and a documented executive escalation path if the standard contacts are unresponsive. The escalation path should be tested periodically – running a planned escalation drill quarterly catches issues with the path before a real incident exposes them.
What Reporting Should Look Like
The retainer should produce documented reporting on a monthly cadence. The reports should include incident summary (count by severity, response time performance, resolution time performance), hours consumption (against budgeted hours by category – incident response, security patching, small enhancements, monitoring, documentation), security patch status (patches applied, patches deferred with reasoning, patches pending), and performance summary (CWV metrics, traffic patterns, any regressions noted).
The reporting should be reviewed in a monthly business review with both technical and commercial stakeholders. The review should be substantive – covering what happened, what is trending, what needs attention – rather than a status check. The retainer that produces substantive monthly reviews builds the partnership; the retainer that produces perfunctory reports erodes it.
The quarterly business review should be deeper, covering strategic context – what is changing in the storefront’s competitive environment, what improvements should be considered, what risks are accumulating, what investments should be planned. The QBR is the natural occasion to surface project scope conversations that the monthly cadence doesn’t accommodate.
Pricing Structure That Aligns Incentives
The retainer pricing structure should align incentives between the agency and the retailer. The structure that works is a base retainer covering the committed scope, with explicit T&M billing for work that exceeds the committed scope. The structure prevents the agency from being penalized for honest scope conversations (because additional work is billed rather than absorbed) and prevents the retailer from being charged for capacity they do not consume (because the base retainer is sized to actual operational needs).
A common pattern is a base retainer of forty to eighty hours per month, with hourly rates for additional work, and a quarterly business review to recalibrate the base level based on actual consumption. The pattern allows the relationship to evolve as the storefront’s operational needs change, rather than locking both parties into a fixed structure that may no longer fit.
Bemeir’s Adobe Commerce support retainer engagements typically use this structure deliberately because the alternative – fixed retainers without flexibility – tends to produce friction during the engagement’s evolution. The structure has produced more sustained long-term relationships than rigid retainer structures would have, with both sides retaining the flexibility to adjust as circumstances change.
For deeper reference on Adobe Commerce operational practice, the Adobe Commerce DevDocs provide platform reference, the Adobe Commerce security patches page provides the official security release cadence, and Magento Open Source community resources provide ecosystem context. Bemeir’s Hyvä migration practice supports the broader engagements that often follow from operational retainer conversations, where the support relationship surfaces the case for performance-driven projects.
