SAP Application Management Staffing with a Named Team Instead of a Ticket Price
A contract SAP support pod on our W-2, functional and Basis and ABAP together. Bought as capacity under a statement of work, not per ticket per tier.
SAP application management services keep a live SAP estate running after go-live. KORE1 staffs them as a named onshore contract pod of functional, Basis and ABAP people under a capacity statement of work, so you buy hours against your own backlog instead of tickets against a tier.
Last updated: October 9, 2026
- This page
- Ongoing support for a system that is already live, staffed as a standing pod you name and direct, and why the unit of purchase matters more than the rate.
- Covered elsewhere
- Seats added to a build or a conversion program are SAP staff augmentation. The two models compared side by side is augmentation versus managed services. The 2027 maintenance clock and the move itself is S/4HANA consultant staffing. One role, one desk, is Basis, ABAP or FICO.
Most SAP application management is sold the same way. A tier structure, a severity table, a response target per severity, and a price per ticket or a monthly fee banded by volume. You have seen the table. It is a clean thing to put in a contract. Easy to compare, too. Everybody signs it.
Then the estate turns out not to generate work in tickets. Not mostly, anyway.
Our SAP practice staffs this differently, because the shape of the demand asks for something different. You get the same three or four people every month, through contract staffing, onshore, on our payroll, sitting inside your IT group under your manager. Not a service desk. Not a help line. Not a vendor with its own ticketing tool and its own definition of done. Your applications manager still runs the queue. Nobody else sets your priorities. That distinction is the entire product.
A Ticket Price Buys the Wrong Unit
A ticket is an event. Something broke, somebody noticed, somebody raised it. Pricing support per event works beautifully when the work is genuinely event-shaped, which is why it works for laptops and for password resets and for printers. It works there well.
An SAP estate is not event-shaped. Ask an applications manager what their team spent last quarter on, and the answer is a mix of about four things, and only one of them ever becomes a ticket. There are the incidents, which do. Those are fine. There are change requests, which do not break anything and therefore wait. There is the standing work that keeps the system legal and current, the tax tables and the legal change packages and the patch cycles, which nobody raises because nobody notices them until they are late. And there is the work with a date on it, which on an ECC estate right now means getting ready to leave. That one never arrives as a ticket. Not once.
Price the first category and you have priced maybe a quarter of the demand. Roughly a quarter. The other three get handled as projects, at a separate rate, under a separate signature, on a separate schedule. Which is how a support contract that looked cheap in February becomes three change orders by August. Every year. Same story.
Capacity does not have that failure mode. You buy a number of hours a month from people who know your estate, and your own backlog decides what those hours do. Boring to sell. Much easier to budget. Ask your controller.
Nobody Reports an SAP Problem in the Right Language
A user does not raise “a lock contention issue” or “a defect in a Z-program.” They raise “the invoice will not post.” That is the whole report. Somebody at intake then has to guess which of three disciplines owns it, before anyone has looked. Here is one quarter of an ECC estate’s demand, sorted by where the desk sent it against where the problem actually was.
| Sent toActually was | Functional | Basis | ABAP | Sent |
|---|---|---|---|---|
| Functional | 44 first assignment correct | 14 sent to Functional, actually Basis | 19 sent to Functional, actually ABAP | 77 |
| Basis | 5 sent to Basis, actually Functional | 21 first assignment correct | 4 sent to Basis, actually ABAP | 30 |
| ABAP | 3 sent to ABAP, actually Functional | 2 sent to ABAP, actually Basis | 8 first assignment correct | 13 |
| Actually was | 52 | 37 | 31 | 120 |
Reading the figure
- Unmarked is the diagonal. The desk guessed right and one person did the work once. 73 of 120 items.
- Marked means the first assignment was wrong, so the item was diagnosed twice. 47 items, 39.2 percent of the quarter.
- The one orange rule marks the largest single mistake, 19 items sent to functional that belonged to ABAP.
- Bar length inside each cell is the item count against the largest cell, so the numbers and the bars carry the same information and neither depends on colour.
Read the diagonal first. 73 of 120 items went to the right discipline on the first try, which is not a scandal. It is roughly what a competent tier-one desk achieves on a system this complicated, and anybody promising better is describing a system they have not seen yet. Ask them for the export.
The interesting number is the one next to it. 47 items were worked by somebody, diagnosed, written up, and handed to somebody else, who then diagnosed them again from the beginning. The second diagnosis is the whole cost of this, and it is invisible on an SLA report, because the clock that matters to the contract started when the ticket was raised and stopped when it was resolved. Nothing in between is measured. Not one minute of it.
Look at the first row and the first column together. Intake sent 77 items to a functional consultant. 52 actually belonged there. That gap of 25 is not incompetence, it is the predictable result of users describing symptoms in business language, and a desk routing on the words it was given. The single largest cell in the whole table is the one where a functional consultant picked up a posting failure that was really a custom-code defect. 19 items in a quarter, about one a week. Every week.
At three and a half hours of duplicated diagnosis per handover, a conservative figure for intake plus investigation plus the write-up nobody reads, that is 164 hours a quarter. Call it 658 hours a year, or about a third of one full-time person, spent entirely on finding out who owns things. You are paying for that today. Nobody itemises it. It is in the rate.
A pod does not fix this by being cleverer at triage. It fixes it by not triaging. Three disciplines sit in the same standup, so a posting failure gets looked at by the person who can read the Z-code and the person who can read the lock table in the same ten minutes, and the handover never happens because there is nobody to hand it to. That is the mechanism. The rest is detail.
Illustrative quarter for a mid-market ECC estate, not a client file. The totals, the diagonal rate, the worst cell and the re-diagnosis hours are all derived from the same table rather than written alongside it, so the figures in this prose cannot disagree with the cells above.
What Each Chair Actually Covers
| Discipline | What this person owns on a live estate | Typical load | What goes wrong without them |
|---|---|---|---|
| Functional | Configuration and process across the modules you actually run. FICO plus whichever of MM, SD, PP or HCM your business leans on, and the person who can say whether something is a defect or the way it was configured in 2011. | Usually the largest share, and the first point of contact. | Every question becomes an escalation, because nobody in-house can distinguish a bug from a decision. |
| Basis | The platform underneath. Transports, authorisations, performance and locking, the patch and legal-change cycle, backups and the things that keep the system supportable at all. | Steady and unglamorous, with spikes at patch and year-end. | Patches slip, the transport path drifts between systems, and performance problems get misread as application defects for months. |
| ABAP | Your custom code. The Z-programs, the user exits, the interfaces, the reports somebody wrote for a controller who left in 2016 and which finance still closes on. | Lumpy. Quiet weeks, then a week that is nothing else. | Defects in custom code get diagnosed as configuration problems, repeatedly, by people who cannot open the code to check. |
Bigger estates add a fourth chair, usually integration or a second functional specialism. Searches for one named role rather than a standing pod live on their own desks, and the ERP recruiting team handles those. If you are adding people to a build or a conversion rather than to a running system, that is SAP staff augmentation and it is priced differently.
2027
end of mainstream maintenance for SAP Business Suite 7 core applications, ECC among them
2 points
premium on the maintenance basis for the optional extended phase that runs to the end of 2030
$105,850
median annual wage for computer systems analysts, May 2025
92%
of KORE1 placements are still in the role at twelve months
Maintenance dates and the extended-phase premium from SAP’s own maintenance strategy page, which also states that customers who do not opt in “will receive customer specific maintenance.” Wage from the BLS Occupational Outlook Handbook, which projects 8 percent growth from 2025 to 2035 and about 32,900 openings a year against roughly 544,400 jobs in 2025. The ABAP chair benchmarks against software developers instead, at a $135,980 median. Retention figure from Why KORE1.
A Five-Year Contract for a System With a Published End Date
SAP has been clear about the calendar for years, and the wording on its own maintenance page is worth quoting rather than paraphrasing. Mainstream maintenance for Business Suite 7 core applications, which includes SAP ERP 6.0, runs “until end of 2027.” After that there is “optional extended maintenance until end of 2030,” available “for three years from beginning of 2028,” carrying “a premium of two percent points on the maintenance basis.” Decline it and you move to customer-specific maintenance. Different thing. Similar name.
One detail gets lost in the summaries. Mainstream maintenance covers the latest three enhancement packages, so what your own estate is entitled to depends on the EHP level it is actually sitting on, and older levels left mainstream earlier. Check yours before you plan anything. People do not. Then they plan.
Hold that calendar next to a managed-services agreement with a three or five year term. The back half of that term lands in a period when your support need has changed shape completely, because by then the valuable work is not keeping ECC comfortable, it is the assessment and the cleanup and the custom-code inventory that make leaving possible. A contract priced on incident volume will do none of that. It will not be cheaper for doing less, either.
So we would rather sell you nine months. Then nine more, if we were any good. That is the whole pitch.
How We Stand Up an SAP Support Pod
- Read one quarter of your actual queueNot the SLA report. The queue itself, exported, with who touched each item. That is where the matrix above comes from on a real estate, and it is the fastest way to find out whether you need three chairs or two. Half a day of somebody’s time, and it has talked clients out of a bigger pod more than once. Cost us the difference, too.
- Fix the modules before the headcountAn estate running FICO, MM and SD needs a different functional person than one leaning on HCM and PP. Naming the modules first is what stops you hiring a generalist who escalates everything, which is the most expensive seat there is. By a distance.
- Buy hours, not severitiesThe statement of work sets a monthly capacity and who directs it, and your backlog decides the rest. If you want the structure itself explained before you sign anything, our SOW staffing page covers how the pricing models differ and where an overrun lands in each one.
- Keep the pod the same peopleContinuity is most of the value and it is the first thing a pooled model gives away. Named individuals in the SOW, with a notice period and a named backup each, because somebody will eventually take a holiday and the estate does not care. It never does.
- Write down what gets documented as it goesNot a knowledge-transfer phase at the end. A standing expectation that the fix and the note about the fix land together, in your system, not in a vendor portal you lose access to. This is the clause people skip. Then regret, in the second year.
- Re-aim it as the estate changesSame three people, same monthly cost, different split. As the conversion gets closer the mix tilts away from incidents and toward assessment and cleanup, and the program team picks up the build. That re-aiming is the thing a ticket price structurally cannot do. Not without a change order.
The Argument for Onshore Is Narrower Than People Claim
Offshore SAP support works. It has worked for twenty years. The talent is genuinely strong. Anyone telling you otherwise is selling something. So the honest case for an onshore pod is not quality. It is narrower than that.
It is overlap. A functional consultant and an ABAP developer solving a posting failure together need to be awake at the same time as each other and as your controller, and the whole saving on the first assignment comes from that one condition. Put a ten-hour gap between the three of them and you have rebuilt the handover you were trying to remove, except now each hop costs a day instead of an hour. A day each way.
Which is why we place these onshore and say plainly that the reason is the clock, not the skill. For a high-volume tier-one desk, offshore is usually the right answer and we will say so. For a three-person pod whose value is that nobody hands anything off, it is not. Different job entirely.
A Pod, a Seat, a Program Team, or a Comparison
-
A pod
Run the estate
Three or four named people, ongoing, against your own backlog under your applications manager.
-
One seat
Fill a specific gap
A single discipline for a leave, a resignation or a known spike. Basis, ABAP or FICO.
-
A program
Staff the conversion
When the work is the move itself rather than keeping the current system running well.
-
A decision
Compare the models
If you have a managed-services proposal in hand and want the trade-offs laid out flat first.
Common Questions
What are SAP application management services?
SAP application management services are the ongoing work of keeping a live SAP estate running after go-live. That covers incidents, configuration changes, the patch and legal-change cycle, custom-code fixes and interface problems. Most providers sell it as a tiered service desk. We staff it as a named contract pod you direct yourself. Same people each month.
How is a support pod different from a managed service?
Who directs the work, and what you are buying. A managed service takes responsibility for an outcome and prices it per ticket or per tier, with its own process and its own tooling. A pod is capacity on your team, under your manager, in your systems, priced as hours under a statement of work. One is a vendor. The other is staff who happen to be on our payroll, and the full comparison runs through where each one actually wins.
How many people do we need to support an ECC estate?
Three is the usual floor. One functional, one Basis, one ABAP, because those are the three places an SAP problem can live. Below three you are relying on somebody to escalate outside the pod, which reintroduces the handover the pod exists to remove. Larger estates add a fourth chair, normally integration or a second functional specialism. Read a quarter of your real queue before you commit to a number. Half a day, and it settles the argument.
What does SAP application management cost?
Price it as monthly capacity, not as a fee per ticket. The BLS puts the median wage for computer systems analysts at $105,850 as of May 2025, which is a fair anchor for the functional and Basis chairs, while the ABAP seat prices nearer the $135,980 median for software developers. Add the employer burden we carry on our W-2, the seniority you asked for in each chair, and whether the pod is full time or a share of each person’s week. What moves the number most is not the rate, it is how many of your hours currently go on re-diagnosing work that was assigned to the wrong discipline first.
Our ECC support ends in 2027. Should we still staff this?
Yes, and the end date is an argument for capacity rather than against support. Mainstream maintenance for Business Suite 7 core applications runs to the end of 2027, with optional extended maintenance to the end of 2030 at a premium of two percentage points on the maintenance basis. Your estate still has to run, close and comply the whole way through. The estate still has to close. What changes is the mix of work, which is exactly what a pod can be re-aimed to follow and a multi-year ticket contract cannot.
Does the pod have to be onshore?
No. Offshore SAP support is genuinely good. The reason we place these onshore is time-zone overlap, not skill. The saving in the figure on this page comes entirely from three disciplines looking at the same problem in the same hour, and a ten-hour gap between them rebuilds the handover you were paying to remove. For a high-volume tier-one desk the calculation goes the other way. Offshore wins there.
Can we convert a pod member to our own payroll later?
Often, and it is a reasonable outcome rather than something we defend against. Working beside somebody for two quarters tells you more than any interview loop, and the conversion terms get agreed up front so nobody negotiates under pressure. It happens most quarters. Our direct hire desk handles it from there.
Send Us a Quarter of Your Queue
Tell us which modules you run, what your EHP level is, and roughly how many items a month come in. We will come back with a pod shape and an honest view on whether you need three chairs or two. Usually within a day. No deck.
Scope an SAP Support Pod →Or call 949-706-6990 and ask for the ERP desk.
