Ongoing Ecommerce Support

Support means different things at different agencies. Some treat it as break and fix only. Others bundle it into a maintenance plan that mostly runs plugin updates.

The work we do under support usually falls into five groups.

Things that broke. Theme conflicts after an app update, checkout issues, integrations that stopped syncing, tracking that quietly went missing, layouts breaking on a browser update.

Things that need changing. New sections and page templates, navigation and collection changes, product and catalogue work, content updates, pricing and promotion setup.

Campaign and seasonal work. Landing pages, sale mechanics, launch preparation and the load of work that arrives around Black Friday, Christmas and end of financial year.

Platform and app maintenance. Theme updates, app reviews, deprecations, security, plan changes, and keeping the store current as Shopify and BigCommerce release changes.

Improvement work. Speed and Core Web Vitals, product page and checkout refinements, search and filtering, analytics review, and the incremental changes that come out of looking at how customers actually use the store.

The fifth group is where most stores under support are underserved, and it is usually the one that pays for itself.

This is the most common way support work starts, and the part most agencies handle badly.

Inheriting an unfamiliar store carries real risk. The theme may be heavily customised with no documentation. Code may have been written by three different people across four years. There may be apps installed that nobody can account for, custom work that breaks if touched, or integrations held together by a script running somewhere nobody has access to.

So we do not start by taking tickets.

We start with an assessment: reviewing the theme and any custom code, mapping the apps and integrations actually in use, checking what is documented and what is not, confirming access to every system the store depends on, and identifying the things most likely to break.

That produces a short, honest picture of what you are working with, including anything we think is a genuine risk. Sometimes it surfaces work that should be done before anything else. Occasionally it surfaces that the store needs rebuilding rather than maintaining, and we would rather say that early than bill hours against a foundation that is not going to hold.

After that, ongoing support runs normally.

Maintenance keeps a store working. It does not make it better.

Where a support relationship runs for more than a few months, we would rather it produced measurable improvement than a log of completed tickets. That usually means keeping a running view of what is worth doing next: reviewing analytics and search behaviour, watching where customers drop out, tracking speed, and maintaining a prioritised list of improvements alongside the reactive work.

The reactive work still comes first when something is broken. But if every hour goes to firefighting, the store is a year older and no better, and that is a slow and expensive outcome that is easy to miss because nothing ever visibly went wrong.

Sometimes the honest answer is that a store does not need support.

If the theme is fundamentally unmaintainable, if the platform no longer fits how the business operates, or if the number of things going wrong reflects a structural problem rather than a set of unrelated bugs, then ongoing support becomes an expensive way to postpone a decision.

In those cases, an ecommerce website design or development project usually costs less over two years than continuous patching. If your requirements have shifted towards wholesale or trade ordering, that may point at B2B ecommerce instead.

We will tell you which situation we think you are in. It is a short conversation, and it is better had before the hours are spent.