Request a demo
Explore Arukus

ARUKUS / SUPPORT & MAINTENANCE

Keep the application moving after go-live.

A useful support arrangement makes the next response clear: how to report a problem, how it is assessed, who owns the action and how the fix reaches the people affected.

Clear service ownership. Practical communication. Controlled change.

Discuss your requirements
EXPLORE THE WORKING MODEL

A service cycle with a clear next owner.

Select a checkpoint to explore the work, information and responsibility involved.

Capture

Record the affected task, business impact and safe reproduction details.

Illustrative operating model. Project-specific scope and responsibilities are agreed during discovery.
START WITH THE OPERATING NEED

Different needs. Clear service routes.

Keep incidents, user questions and planned improvements visible without treating them as the same request.

Adoption

Help people complete the task

User guidance and task-based onboarding help teams understand the configured workflow, including returned records and escalation.

Incident support

Restore useful operation

Assess a reported failure in its business context, identify the responsible team and communicate the next action.

Enhancements

Improve the application deliberately

Review new reports, policy changes and interfaces for effort, acceptance and release impact before they enter the plan.

A PRACTICAL WORKING SEQUENCE

From a reported issue to a reviewed resolution.

The specific channels and response targets belong in your service agreement. This model explains the work around them.

AT THIS STAGE

Report with context

Provide the affected workflow, time, expected result, actual behaviour and business impact. Use anonymised evidence where possible; never send passwords.

Evidence to carry forwardA traceable service record with enough context for assessment.

People to involveRequester and designated customer contact.

MAKE THE REVIEW USEFUL

What belongs in the service agreement?

Use these questions to make the support boundary clear before the first incident.

THE OPERATING QUESTION

Coverage & escalation

Which hours, channels and severity levels apply, and who can escalate?

Evidence / measureService window, severity definitions, response targets and named escalation route.

Responsible reviewer

Customer sponsor and service lead.

Read the result in context

Response, workaround and final resolution are different commitments.

THE WORK BEHIND THE MODEL

From the diagram to daily decisions.

Continuing support should help people keep working and help the organisation learn from recurring difficulties. It needs a shared record of the issue, its impact and the action expected from each team.

01

Onboarding and confident use

Handover covers the configured workflow, the people responsible and the route for questions. Role-based walkthroughs can be arranged for administrators, reviewers and field users. Refresher guidance should focus on the task people find difficult rather than repeating a tour of every screen.

02

Report safely and usefully

A good report explains what happened and what work is blocked. Include a reference, a time and safe reproduction steps. Screenshots should remove unrelated personal data. Credentials and sensitive production extracts need an agreed secure handling route rather than an ordinary email or web form.

03

Distinguish response from resolution

An acknowledgement confirms receipt. Assessment establishes ownership and priority. A workaround may allow work to continue while a correction is investigated. Final resolution requires verification. The applicable service schedule defines the expected timings and coverage; this page does not establish universal service levels.

04

Maintain more than the visible screen

An agreed maintenance scope may include defect correction, compatibility changes, dependency reviews and release coordination. Database operations, hosting, backups and external providers need explicit owners. Document how teams coordinate when an incident crosses those boundaries.

05

Make releases understandable

Release communication should describe the change, the affected workflow, the intended release window and any user action. Testing and recovery responsibilities are agreed before a change reaches the live environment. Operating notes and training material should reflect approved process changes.

06

Review the service as a working relationship

Review aged issues, repeated questions, incident causes and upcoming changes with the named owners. Use that discussion to prioritise maintenance and enhancements. AMC, project support, stabilisation and additional development are described in the relevant agreement, including renewal and change terms.

Questions before you begin

How is an urgent incident prioritised?

Priority depends on the agreed severity definitions and business impact. The service schedule establishes coverage, escalation and response targets.

Can you support an application developed by another team?

Managed support can be assessed after reviewing the code, documentation, access, technology dependencies and current operating responsibilities.

Are new features included in AMC?

The agreement defines what is included. Enhancements are assessed for scope, effort and acceptance before approval.

How do users hear about changes?

Release communication and role-based instructions are agreed for the engagement, including the contact responsible for informing affected teams.

YOUR NEXT WORKING SESSION

Bring the process. Let’s examine the difficult part.

A useful discussion starts with one real task, the people responsible and an example that did not follow the expected route.

Discuss your requirements