Skip to main content
Talk to an expert
ServiceSupport · Current operating model

Stable commerce platforms are maintained that way.
We run them as operational platforms, not websites.

Support is platform stewardship: continuity, controlled change, performance, governance and the long view. The engineers who know the platform on a Tuesday afternoon are the same ones you'll speak to on a Sunday night. The work is calm on purpose.
Contents · 9 sections
  1. 01Stable commerce platforms are maintained.
  2. 02Support is broader than tickets.
  3. 03Performance problems compound quietly.
  4. 04Controlled change reduces operational risk.
  5. 05Commerce ecosystems do not stand still.
  6. 06Technical debt grows during support too.
  7. 07Confidence comes from predictability.
  8. 08A long-running B2B retailer, eight years steady.
  9. 09Common questions.
01 · Stewardship

Stable commerce platforms are maintained that way.

Stability is operational. It comes from monitoring, dependency management, patching cadence, infrastructure oversight and a release rhythm that doesn't slip. Most outages have earlier warning signs. Stewardship is the discipline of acting on them before they become customer-visible.
We run support as a continuous operational practice. The same engineers across quarters, documented runbooks, quarterly platform reviews against a written health baseline. Nothing about it is heroic.
Roughly seventy per cent of what we resolve is caught before customers see it. That number is the point of the work.
8 yrs
Average tenure
Per support engagement
~70%
Caught pre-customer
Of issues resolved, typical
2-wk
Release cadence
Sustained, not aspirational
P1<1%
P1 share of volume
On steady-state platforms
02 · Scope

Support is broader than tickets.

Tickets are the smallest part of a healthy support engagement. Most of the work is roadmap alignment, release planning, integration oversight, observability, and the quiet improvements that keep the platform fit to trade against next year's plan, not last year's.
We sit with merchandising, customer service, finance and operations, not only IT. The platform is an operational system, and the people running the day are the ones who notice first when it stops behaving the way it should.
03 · Performance

Performance problems compound quietly.

Checkout slows by a hundred milliseconds a quarter. Search relevance drifts as the catalogue grows. An integration starts retrying twice as often. None of it lights up a dashboard on the day it happens. The commercial signal arrives months later, in conversion, basket and customer service load.
We track performance against a written baseline, per page, per integration, per release. The work is unglamorous: budgets, observability, query review, third-party hygiene. It's also the difference between a platform that ages well and one that doesn't.
04 · Change

Controlled change reduces operational risk.

We don't move fast. We move predictably. Releases follow a written cadence, ride behind feature flags, are rehearsed against staging built from production data, and carry a documented rollback before they ship. The point isn't speed. The point is that the trading day is never a surprise.
wk 1
Plan & QA
wk 2
Stage & rehearse
mid-wk
Release behind flag
24-72h
Ramp & observe
wk after
Review & baseline
Sprint start────────── typical 2-week release rhythm ──────────Baseline updated
Trading periods get a quieter shape. Change windows narrow, observability widens, on-call moves closer. Peak isn't a separate plan; it's the same discipline, tightened.
05 · Evolution

Commerce ecosystems do not stand still.

ERPs upgrade. PIMs replatform. Marketplaces open. Customer expectations shift. Internal teams reorganise. The commerce platform has to absorb all of it without losing the trading day. Support is the discipline that makes that absorption uneventful.
We treat the platform's surroundings as part of the platform. Integration owners are mapped, vendor roadmaps are tracked. Where AI earns its place, it sits inside operational workflows, anomaly detection, observability, support efficiency, with governance and human review. We don't run experiments on the trading platform.
06 · Debt

Technical debt grows during support too.

Every release adds a small amount of friction unless somebody is actively paying it down. Bespoke logic without owners. Integrations without contracts. Modules customised past upgrade. None of it is dramatic. All of it makes the next change more expensive.
A fixed share of every sprint goes to maintainability: documentation, refactoring at the hot path, removing what's no longer earning its complexity. Good support protects future flexibility. The cheapest roadmap is the one we don't have to apologise for in two years.
07 · Confidence

Confidence comes from predictability.

The outcome of good support isn't a low ticket count. It's that the organisation trusts the platform again. Releases land on the date they were planned for. Performance behaves the way the baseline says it will. Owners are clear, decisions are written down, and there are fewer surprises in the trading week than there were six months ago.
That trust is the commercial asset. It's what makes the next investment decision a quick one.
08 · Proof
09 · Questions we get asked

Common questions.

Which platforms does iWeb support?

Adobe Commerce, Magento Open Source, Akeneo PIM and the ERP, OMS and search systems integrated alongside them. Support covers the whole operational stack, not only the storefront.

What is included in managed support?

Incident response, security patching, platform upgrades, performance work, change requests and integration monitoring. Each engagement has named senior engineers and a written runbook for the client's specific estate.

Can iWeb take over support from another agency?

Yes. iWeb runs a short transition where the codebase, infrastructure, integrations and tickets are documented before going live on the rota. The first month is deliberately conservative on change.

How does iWeb handle ERP and integration incidents?

Integration is treated as a first-class part of the platform: monitoring, retries, dead-letter queues and a written runbook for the on-call team. Incidents are tracked across storefront, middleware and ERP rather than blamed on one side.

Do you handle Adobe Commerce security patches?

Yes. Adobe Commerce security patches are scheduled into the support cycle, regression tested in staging and applied through the normal release process. Critical patches are accelerated when warranted.

Who is iWeb managed support for?

Operators running Adobe Commerce, Magento or Akeneo PIM as the core of their commerce stack, usually with ERP integration and B2B or trade complexity in the mix.

How is support priced?

Usually a monthly retainer with banked hours for change requests, sized to the estate. Incident response is in scope for every retainer; large change programmes are scoped separately.

What SLAs does iWeb commit to?

Response targets are written into each support agreement and tied to severity. Critical incidents get a named on-call engineer; lower-severity work runs through the normal cadence.

Does support cover Akeneo PIM and ERP middleware as well as the storefront?

Yes. Support covers the operational stack, not only the storefront. PIM, ERP middleware and search are monitored and supported as first-class components.

What happens when an incident crosses storefront, middleware and ERP?

A single on-call lead owns the incident end to end and coordinates across the boundary, instead of blaming one side. The runbook names who acts on which surface and the timeline is reconciled afterwards.

Next step

Run the platform like an operational system. Quietly, predictably, for the long run.

Send the brief. You'll get a written response from a senior expert, the shape of the support engagement, what we'd review in the first 30 days, and the operating model we'd stand behind for year one and year three.
Talk to an expertor read how we run support →