AMS and support careers in SAP

Written by an SAP Finance & Treasury practitioner working with SAP since 2008 · how the guides are written · Updated 1 October 2026

SAP AMS is the contracted work of keeping a live SAP system running once the project that built it has closed: fixing what breaks in production, delivering small changes and removing the causes of repeat failures. An SAP support consultant does that work from a ticket queue, against response and resolution targets agreed with the business.

What is SAP AMS?

SAP AMS — application management services — is the arrangement under which a team takes responsibility for a running SAP landscape for a fixed term, usually several years, under a contract that defines scope, hours, priorities and service levels. The team may be an external provider (a global integrator, a specialist support house, an offshore or nearshore delivery centre) or an internal competence centre inside the company that owns the system; the layers of the SAP ecosystem sets the two side by side. The scope is the application layer: the configuration, custom code, interfaces and reports in each SAP area. Infrastructure and the database often sit in a separate contract — on RISE with SAP the hyperscaler and SAP run the technical layer, and the AMS partner still owns everything above it. Many people simply call the whole thing production support.

Contracts are typically built in tiers. First line receives the report, checks it against known errors and handles routine requests such as password resets and simple authorisation gaps. Second line analyses inside one area — finance, logistics, HR. Third line holds the specialists who change configuration and code, and the Basis team moves those changes through the landscape. A service manager owns the contract above the tiers and reports on it monthly.

What does an SAP support consultant do all day?

Works the queue, in priority order, and keeps the system out of trouble between tickets. A morning usually starts with the overnight picture: which background jobs failed in SM37, which short dumps appeared in ST22, which IDocs are sitting in error in WE02 and which interface queues have stuck. Monitoring is increasingly done from SAP Cloud ALM, or still from SAP Solution Manager on older landscapes, but the transactions behind it are the same. Then the tickets: reproduce the problem in a test client, read the application log in SLG1 or the failed authorisation check in SU53, find the cause, agree the fix, document it.

The rest of the week fills with small change: a new output form, an adjusted pricing condition, a new company code's settings, a report the controllers want by close. Each one is a project in miniature — a short specification, a build, a test with the requester, a transport — and the discipline is the same as on an implementation, just faster. The calendar shapes the load. Mid-month is quiet; month-end close, payroll runs and year-end are not, and a good support consultant knows which jobs and interfaces matter on which day before the business rings.

Which kinds of ticket reach an AMS queue?

Four, and the contract treats each differently. Most support tooling follows the ITIL vocabulary, so the same names appear whether the ticket tool is ServiceNow, Jira or SAP's own.

The four ticket types an AMS contract separates
Ticket type	What it is	What sets its turnaround
Incident	Something that worked yesterday is broken or degraded today: a posting error, a failed job, a stuck interface	The priority it is given, which decides the response and resolution clock
Service request	A routine ask with a known procedure: a role for a new user, a period opened, a master record unlocked	The catalogue entry for that request and whether an approver has signed
Minor enhancement or change request	New or changed behaviour: a field added to a form, a new report, a configuration change for a new site	Estimation, the client's approval of the effort, and the next release window into production
Problem	The underlying cause behind repeated incidents, investigated separately from the incidents themselves	How costly the repeats are; there is rarely a clock, only a review that keeps asking

How do incident priorities and SLAs work?

Every incident is given a priority from business impact and urgency, and the SLA — the service level agreement in the contract — attaches two clocks to that priority: time to respond and time to resolve or provide a workaround. Most contracts use four levels. A P1 means a critical process is stopped for many users, such as no goods leaving the warehouse or no payment run; a P4 is a cosmetic fault or a question. Response targets for a P1 are measured in minutes and the work continues around the clock; lower priorities run on business hours and their targets stretch to days. The exact figures are negotiated per contract, so treat any number you hear as one client's, not the market's.

Two consequences follow for the person in the seat. The priority, not your plan, decides the order of your day. And the clocks pause only in states the contract defines, typically when the ticket waits on the reporter, so updating a ticket's status honestly matters as much as fixing it. Service managers report SLA attainment monthly, and a team that misses P1 targets hears about it at the next review.

What happens when a P1 incident comes in?

Raised and confirmed. A key user or the monitoring reports it; first line checks the impact and confirms the priority with the business, because a P1 that is really a P3 costs the night for nothing.
Bridge opened. An incident manager opens a call, pulls in second and third line for the affected area plus Basis, and starts a written timeline.
Contained. The first goal is a workaround, not the root cause: a job restarted, a queue released, a blocking entry corrected, a manual step agreed so trucks can leave.
Fixed and moved. If a configuration or code change is needed, it is built, tested in the quality system and imported to production under the emergency change process, with an approver named.
Confirmed and closed. The business confirms the process runs; the ticket is resolved, and the clock stops.
Handed to problem management. A problem ticket records the root cause, the permanent fix and whether monitoring would have caught it earlier; the post-incident review feeds the next month's service report.

Is SAP support a good place to start?

Yes, for most newcomers it is the most dependable first seat in SAP, because supervised ticket work can be given to a beginner while a client design workshop cannot. Support teams recruit graduates, former key users and people from other IT support roles, and the ramp is visible: read closed tickets, shadow a resolution, take the simple ones, then the awkward ones. You see the system with years of real data, custom code and exceptions, which consultants who only implement rarely see, and you learn the habit every later role rewards: reproduce, isolate, prove, then change one thing.

The trade-offs are real. Some tickets are the same ticket, every month. Rotas, on-call weeks and blocked leave around close come with the job. Success is measured in response and resolution targets rather than a deliverable you can show, so keep your own record of what you fixed and changed. And a first-line seat with no path to second or third line teaches the ticket tool rather than SAP — ask how people move up before you accept. For the other doors in, see getting SAP experience before a first project.

How do you move from AMS to projects?

By turning ticket knowledge into design knowledge and saying so. Volunteer for the minor enhancements, which are small projects; ask to join a rollout or upgrade your own provider runs; and be the support person on a cutover and hypercare handover. On a CV, describe the areas, kinds of change and incidents you owned rather than ticket counts — that is how support years are read. The usual landing seat is functional consultant in the area you supported.