When your eCommerce store experiences a problem, the quality of your support agreement becomes immediately important.
A checkout error may prevent customers from buying. An integration failure may stop orders reaching your ERP. Incorrect stock information may lead to overselling, cancellations and additional work for your customer service team.
At that point, your business needs to know who is responsible, how quickly they will respond and what happens next.
Yet many eCommerce support agreements leave these details unclear. They may specify a monthly allocation of hours without explaining what those hours cover, how urgent incidents are handled or who takes ownership when several systems are involved.
For businesses running Shopify Plus or Adobe Commerce, a useful support agreement should define how the complete commerce environment will be maintained and supported. It should also establish how your partner will help improve it over time.
Here is what to review before committing.
1. A Clear Definition of What Is Supported
The first question is straightforward: what exactly does the agreement cover?
An eCommerce operation may include the storefront, custom code, applications, hosting, middleware and connections to other business systems. Your support partner may be responsible for some of these components, while other providers manage the rest.
The agreement should identify the supported environment and define the boundaries of responsibility.
Depending on your business, this could include:
- Storefront themes and customer-facing functionality.
- Custom applications, modules and extensions.
- Checkout configurations and payment integrations.
- ERP, PIM, warehouse and point of sale integrations.
- Middleware and scheduled data transfers.
- Hosting and infrastructure, where applicable.
- Search, merchandising and other third-party services.
- Development, testing and production environments.
Avoid relying on a broad phrase such as “website support”.
For example, your agency might support a Shopify theme but exclude the custom application that sends orders to your ERP. That distinction matters when customers can complete checkout but your warehouse never receives their orders.
Ask: “Can you list the systems and components covered by this agreement, including any integration boundaries?”
2. Support Hours That Match Your Trading Requirements
Your store may accept orders around the clock, but your support agreement may only provide assistance during business hours.
That can be appropriate for some businesses. Others need a way to escalate a critical incident during evenings, weekends or major promotional periods.
Confirm:
- Standard support hours and the applicable time zone.
- Whether public holidays are covered.
- How critical incidents are handled outside standard hours.
- Whether after-hours assistance attracts additional charges.
- Whether peak-period coverage requires advance booking.
- Which communication channels are monitored.
Distinguish between a system being monitored and a person being available to respond. An automated alert does not, by itself, establish an after-hours support commitment.
Ask: “If checkout stops working on a Saturday evening, how do we reach someone, and what support is included?”
3. Incident Priorities and Response Commitments
A broken checkout should receive different treatment from a minor layout issue.
Your agreement should explain how incidents are classified and what response commitment applies to each priority.
A practical framework might distinguish between:
| Priority | Example | What to clarify |
|---|---|---|
| Critical | Customers cannot place orders across the store. | Escalation route, coverage hours and initial response commitment. |
| High | A key integration is failing or a significant customer group cannot order. | Business impact criteria and investigation priority. |
| Standard | A feature has a workaround or affects a limited number of users. | Queue position and expected communication. |
| Low | A minor visual issue or non-urgent request. | How it enters the planned work queue. |
The precise definitions should reflect your operation. A trade account login failure may be critical for a B2B business even if the public storefront remains accessible.
Also distinguish between response, restoration and resolution.
A response means someone has acknowledged the incident and started the agreed process. Restoration means the affected service is working again, potentially through a temporary measure. Resolution addresses the underlying problem.
A fast response commitment does not guarantee a permanent fix within the same timeframe.
Ask: “What does your SLA commit to, and how will you keep us informed until service is restored?”
4. Ownership When Multiple Systems Are Involved
Some of the most disruptive eCommerce incidents sit between systems.
An order might fail because of a storefront change, a middleware error, an expired credential or an ERP rejection. Establishing the cause can require several providers to work together.
Your agreement should identify who coordinates that investigation.
The support partner may not control every connected system, but your business still needs a clear point of contact to:
- Assess the impact.
- Gather useful evidence.
- Engage the relevant providers.
- Track actions and dependencies.
- Communicate progress.
- Confirm that the affected process works again.
Without this arrangement, your internal team can become responsible for passing messages between suppliers while orders remain stuck.
Ask: “When an incident crosses the commerce platform, middleware and ERP, who coordinates it through to restoration?”
For a practical incident workflow, see how to diagnose and recover from eCommerce ERP integration failures, including transaction tracing, safe replay and reconciliation responsibilities.
5. Proactive Monitoring and Its Limits
Support is more valuable when problems are detected before customers or staff report them.
However, “proactive monitoring” needs a clear definition.
Depending on the environment, monitoring may cover website availability, application errors, integration failures, scheduled processes, infrastructure health or unusual transaction patterns.
Your agreement should explain:
- What is monitored.
- How frequently checks occur.
- Which conditions trigger an alert.
- Who receives and reviews alerts.
- When investigation begins.
- What action is included.
A website can be available while orders fail to reach the warehouse. Availability monitoring alone will not necessarily detect that problem.
Monitoring should therefore reflect the operational journeys your business depends on, with appropriate attention to privacy and data access.
Ask: “Which failures can your monitoring detect, and what happens after an alert is raised?”
6. Maintenance and Security Responsibilities
An eCommerce store needs maintenance even when no new features are being developed.
The agreement should establish who reviews updates, assesses their relevance, tests changes and applies them.
For Adobe Commerce, responsibilities may include platform patches, extensions, custom modules and infrastructure components, depending on the hosting arrangement.
For Shopify Plus, Shopify manages the underlying platform, while your business and its partners still need to manage areas such as themes, applications, custom code, integrations and account access.
Clarify whether the agreement includes:
- Reviewing relevant security notices.
- Planning and applying supported updates.
- Checking third-party compatibility.
- Testing critical journeys after changes.
- Reviewing access permissions.
- Maintaining technical documentation.
- Managing obsolete or unsupported components.
Also confirm whether substantial version upgrades are included or quoted separately. Routine maintenance and a major upgrade can involve very different amounts of work.
Ask: “Which maintenance activities are included, and which updates require a separate project?”
7. Backup, Recovery and Release Arrangements
Your business should understand how it will recover from a failed release, accidental deletion or other significant incident.
Backup requirements depend on the platform and architecture. Different tools may be needed to protect code, configuration, catalogue information and other business data.
The agreement should identify:
- What is backed up and by whom.
- How long backups are retained.
- Whether restoration procedures are tested.
- What can and cannot be recovered.
- Who authorises a restoration.
- How recovery work is charged.
Release arrangements matter too. Establish how changes are approved, tested and deployed, and what happens if a deployment causes a problem.
Where appropriate, define recovery objectives: how much data loss the business could tolerate and how quickly a service needs to be restored. These should be assessed against the actual recovery capability and cost.
Ask: “If a release fails or important data is lost, what is the recovery process, and what are its limitations?”
8. How Monthly Hours and Additional Charges Work
A monthly support allocation can be useful, but only when its commercial rules are clear.
Confirm what consumes the allocation. Investigation, meetings, testing, deployment, documentation and coordination with other providers may all require time.
Your agreement should explain:
- The included hours or services.
- Which activities are chargeable.
- Whether unused hours expire or roll over.
- How work is estimated and approved.
- What happens when the allocation is exhausted.
- Rates for additional and after-hours work.
- Whether urgent incidents can proceed without prior approval.
- Any minimum billing increments.
Discuss how errors introduced by the support partner are handled commercially. You should understand when corrective work is included and when investigation or remediation becomes additional paid work.
Ask: “Can you show us how a typical month is charged, including what happens during a major incident?”
9. A Process for Planned Improvements
Keeping the store operational is one part of the relationship. Improving it requires a separate process for selecting and delivering work.
Confirm how your partner will help manage the backlog and balance urgent issues, maintenance and enhancements.
A useful arrangement should establish:
- Who can submit requests.
- How requirements are clarified.
- Who sets priorities.
- How estimates are approved.
- How acceptance criteria are agreed.
- Who tests and signs off completed work.
- How releases are scheduled.
This prevents a support allocation from becoming a collection of disconnected tasks.
Priorities should reflect your business objectives, whether that means reducing manual order entry, improving trade customer adoption or making checkout easier to complete.
Ask: “How will you help us choose the most valuable work within our available budget?”
10. Reporting That Explains Performance
An invoice and a timesheet show expenditure. Your business also needs to understand what that expenditure achieved.
Reporting should be proportionate to the agreement, but it may include:
- Work completed and budget used.
- Incident volumes and severity.
- Performance against response commitments.
- Recurring problems and their causes.
- Maintenance completed or outstanding.
- Integration reliability.
- Upcoming risks and recommended actions.
- Progress against agreed improvement priorities.
Repeated incidents deserve particular attention. If the same failure consumes support hours every month, your partner should help assess whether a lasting fix is justified.
Commercial measures can also be useful where they relate to the work being delivered. Changes in revenue or conversion should be interpreted alongside factors such as traffic, promotions, pricing and stock availability.
Ask: “What will your reporting help us decide?”
11. Documentation, Access and Exit Terms
A good support relationship should make your environment easier to understand and manage over time.
Confirm that documentation will be maintained and that your business retains appropriate access to its accounts and assets.
The agreement should also address what happens when the relationship ends.
Review:
- Contract duration and notice periods.
- Renewal arrangements.
- Ownership and usage rights for custom code.
- Access to repositories and documentation.
- Transfer of accounts and applicable licences.
- Handover assistance and associated charges.
- Removal of agency access.
- Treatment of unfinished work.
Clear exit arrangements reduce uncertainty for both parties and make a future handover easier to plan.
Ask: “If we change partners later, what will you provide, and what will the handover cost?”
Compare Agreements Against the Same Requirements
Two support proposals can have similar monthly prices while offering very different coverage.
One may include monitoring, maintenance and incident coordination. Another may provide a block of development hours with additional charges for those services.
Before comparing costs, give prospective partners the same information about your platform, integrations, trading hours and operational priorities.
Then check that each proposal clearly answers:
- What is covered?
- When is support available?
- How are urgent incidents handled?
- Who owns investigation across systems?
- What maintenance is included?
- How are hours and additional costs managed?
- How are improvements prioritised?
- What reporting and documentation will you receive?
- How does the agreement end?
The right agreement is one your team can understand and use confidently. It should make responsibilities clear before a problem occurs and establish a practical basis for keeping your commerce operation reliable.
Reviewing Your eCommerce Support Arrangements?
OSE works with established retailers, wholesalers and manufacturers across Shopify Plus, Adobe Commerce and connected business systems.
If your existing agreement leaves gaps around integrations, maintenance, incident ownership or ongoing development, reviewing those arrangements can help you define what your business needs from its next support partner.
Talk to OSE about your eCommerce environment, current support challenges and priorities for a more effective support partnership.