Ongoing support starts with a defined system boundary and clear ownership. Monitoring, incident handling, changes and usage reviews are organised around the services and responsibilities agreed for your environment.
Discuss managed operationsMay be scoped: monitoring named systems, incident coordination, approved configuration changes, usage review and operating records.
Scope separately: new features, model training, repairs to customer-managed systems, data recovery and third-party defects. Service hours and response targets are contractual.
Detect → assess → authorize → verify → review
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.
Illustrative example · not customer data
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.
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.
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.
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.
Bring the system list, current operating responsibilities and the support arrangements your team needs.
