The release is live. The support responsibility is still being assembled.
Illustrative scenario. The situation and arithmetic below explain a delivery pattern. They are not a reported interview or a client result.
The release checklist is complete, but the support queue contains a failed stock update, a preview that no longer matches production and an order that needs reconciling between services before the account team can answer the client.
The launch was a milestone.
Separating the storefront from the publishing platform can give different teams room to work, especially when the client needs several interfaces to share content and commerce records without forcing every change through one release process.
The decision had a basis.
When a customer cannot complete an order, the delivery lead needs to restore the journey before convening a discussion about which supplier owns the failure, and the agency is often the team with enough context to begin.
The immediate response makes sense.
In this illustrative ledger, two engineers each spend three hours a week investigating the same class of incident; over four weeks, that is 24 engineering hours before account coordination, testing or the next planned release enters the calculation.
Those hours need an allocation.
A supplier can change an interface, a promotion can increase demand and a client can add a market after launch; each can create support work even when the original implementation met the requirements agreed at the time.
Change belongs in the model.
If incident handling, monitoring and reconciliation have no agreed owner or allowance, each new failure returns to the people who can reconstruct how the services fit together, regardless of what the maintenance agreement actually covers.
The agency has inherited an operating responsibility that the project never priced.