SAP AMS contract models: ticket-based, capacity or fully managed

Three models, three risk profiles

Application Management Services contracts nearly always fall into one of three shapes. The difference is not the work but who carries the volume risk.

• Ticket-based: you pay per incident or per resolved ticket. The provider carries volume risk and prices it in.
• Capacity-based: you buy a fixed number of consultant days per month and decide how to use them. You carry the volume risk and get full flexibility.
• Fully managed: the provider owns the service outcome against agreed SLAs, including staffing, tooling and continuous improvement.

When each model fits

Ticket-based works for stable landscapes with predictable, low incident volumes and little change activity. It becomes expensive as soon as small enhancements are constantly needed, because every request turns into a commercial discussion.

Capacity-based fits organisations that still have internal SAP knowledge and want to steer priorities themselves. It is the most transparent model and the easiest to scale up or down at renewal.

Fully managed fits landscapes where the business wants an outcome, not a resource pool — typically after a transformation, when internal knowledge has thinned out and the service level matters more than day-by-day control.

What to write into the contract

• Service hours, response and resolution targets per priority class
• What counts as an incident versus a change request, with examples
• Named roles: service manager, module leads, escalation path
• Knowledge transfer at start and at exit, with documentation obligations
• Reporting: monthly volumes, SLA attainment, backlog and recurring root causes

The cost comparison people forget

Comparing AMS offers by day rate alone hides the real differences: coverage window, whether small changes are included, how quickly the provider can add capacity for a project peak, and what happens to knowledge when the contract ends. A cheaper contract that excludes enhancements often ends up costing more once the change requests start.

Combining AMS with project work

Splitting run and change between two suppliers creates a permanent blame boundary. Where the same partner covers AMS and project delivery, the people who will support a change are the ones who reviewed its design — which is usually visible in the incident volume six months after go-live.

Frequently asked questions

Which AMS model is cheapest?

It depends on change volume. Ticket-based is cheapest for very stable landscapes; capacity-based usually wins as soon as regular enhancements are needed.

What belongs in an SAP AMS SLA?

Service hours, response and resolution targets per priority class, a clear incident-versus-change definition, named roles, an escalation path and monthly reporting.

Should AMS and project work sit with the same partner?

It removes the run-versus-change blame boundary and means the people supporting a change reviewed its design. Separate suppliers can work, but need a very clear interface agreement.