ARUKUS / MANAGED APPLICATION SUPPORT
Give the application a clear service owner.
Agree incident handling, maintenance and release responsibilities around the system your teams use.
Application support begins with an understanding of the business tasks the system serves. A technical symptom needs context: who is affected, which process has stopped and what evidence is available.
Establish the service baseline
Review the application, environments, operating instructions, access arrangements and outstanding issues. Confirm which systems and third parties remain outside the support scope.
Define incident and change routes
Agree severity, coverage, response targets and escalation in the support schedule. Keep defect correction separate from enhancements that alter the approved behaviour. Changes need acceptance and release ownership.
Review recurring work
Use incident themes and release experience to prioritise maintenance. Compatibility work, monitoring improvements and operational documentation can be scoped alongside the application. Coverage and infrastructure ownership are specific to the agreement.
Planning the engagement
What should we bring to the first discussion?
Bring a process example, current system information and the people who own the work. A returned record or failed handover helps establish the difficult cases.
How is the scope agreed?
The proposal identifies deliverables, assumptions, acceptance criteria and the responsibilities of each team. New requirements are assessed through an agreed change process.
What happens after release?
Handover, stabilisation and continuing support are specified in the engagement. Coverage and service targets are agreed rather than assumed.