Agree how the environment will be supported after delivery.

Identify the systems and the people responsible.

List the applications, cloud resources, model connections and dependencies included in the service. Confirm the customer’s account owners, technical contacts and approval roles. Review the available configuration and handover documentation, together with known issues. Access permissions should match the operating tasks and remain subject to the customer’s authorisation and review.

Choose signals that lead to an action.

Agree what will be monitored and what each signal means for the business. This may include service health, request errors, resource usage and available billing information. Identify who receives an alert, how it is assessed and when another team or supplier needs to be involved. Monitoring coverage and response arrangements are confirmed together; visibility alone does not define who resolves an incident.

Keep incidents and changes traceable.

Record the reported problem, relevant observations, actions taken and current owner. Define the communication and escalation path for issues involving customer systems or third-party services. For planned changes, confirm the reason, approver, validation method and recovery approach before execution. Keep configuration and runbook records aligned with the accepted change.

• Customer responsibilities: approve access and changes, provide business context and coordinate the systems the customer operates.
• Corebyte responsibilities: perform the support tasks and maintain the records specified in the agreed service scope.
• Supplier responsibilities: handle provider-controlled resources and service issues through the applicable supplier channels.

Review usage and performance with their context.

Use the records available for the agreed systems to discuss capacity, request behaviour and costs. Explain gaps in the data and the assumptions behind any recommendation. A review can produce actions for resource adjustment or further investigation. New optimisation, model evaluation or fine-tuning work needs a separate capability and scope discussion before it is included in the service.

Define the service arrangements and review them.

Agree service hours, response objectives, incident categories, escalation contacts and review frequency in the service agreement. Useful records can include incident histories, approved changes, usage summaries and open actions. Review whether the system list and responsibilities still match the environment as it evolves. If support is transferred or ends, agree how documentation, outstanding issues and authorised access will be handed over.