Table of Contents
“Users hate SAP” is one of the most expensive conclusions an organization can reach. I have heard it used to justify a redesign, a new training program, and even a replacement-platform business case. Yet when you observe the work closely, the screen is often only where the pain becomes visible. The actual failure happened earlier: a supplier record was wrong, an approval owner was unclear, a policy created an impossible exception, or a manager asked an occasional user to make an expert-level decision. Blaming SAP alone is convenient because it gives leaders something concrete to fix. It is also how companies spend six figures improving the wrong thing.
A better experience with SAP does not begin with prettier screens or another satisfaction survey. It begins by treating SAP as what it is: the operating system where process decisions, data quality, controls, and handoffs collide. If users open a spreadsheet before they open SAP, message colleagues to confirm routine information, or delay a transaction because they fear making an irreversible mistake, the issue is not simply usability. It is a breakdown of confidence in the work itself.
SAP supports work with real consequences: releasing payments, ordering materials, closing financial periods, correcting payroll, allocating costs, and managing inventory. That means some complexity is legitimate. A finance controller should not be able to change a high-risk posting as casually as they change a calendar invite. The mistake is assuming that every difficult step is necessary because the business is complex.
In practice, most poor SAP experiences fall into one of two categories. Necessary complexity protects financial accuracy, compliance, or operational control. Accidental complexity is created by outdated configuration, poor master data, duplicate policies, unclear ownership, and processes that no longer reflect real work. The first must be explained and made manageable. The second should be removed aggressively.
Too many teams never separate the two. They ask users to rate ease of use, receive a low score, and declare that an interface refresh is needed. A score cannot tell you whether people are struggling to understand a field, waiting for a manager, reconciling conflicting data, or rebuilding the transaction in Excel because they do not trust the report. Those problems sit in different parts of the organization and require different investment decisions.
When researching experience with SAP, I use a four-part confidence model. People do not need every workflow to be effortless. They need enough confidence to act without repeatedly checking, escalating, or retreating to a workaround. Friction becomes damaging when one link in this chain breaks.
This model produces much better priorities than an overall ease-of-use metric. Low data confidence points to governance, integration, and ownership. Low process confidence points to clearer status, approvals, and service expectations. Low decision confidence calls for contextual guidance or policy simplification. Low recovery confidence requires better error states, permissions, reversals, and escalation paths.
In a procurement study I led, the sponsor expected us to recommend training because requisitioners repeatedly asked for help creating purchase orders. During task walkthroughs, the users navigated the screens competently. Their hesitation came at supplier selection. Duplicate vendor records, inconsistent naming conventions, and a fear of triggering a payment error made people stop and message procurement. The useful intervention was not a 45-minute training module. It was a clearer supplier-selection flow, visible record-quality signals, and a safe route for resolving uncertainty before submission.
The biggest research mistake is limiting the study to what happens inside the product. SAP experience is shaped by what users do before they log in and what they must do after a transaction is complete. A buyer may begin with an email request, search three systems for budget information, complete a requisition in SAP, then chase approval status in Teams. If research captures only the 12 minutes in SAP, it misses the 40-minute job.
Do not begin interviews with, “What do you think of SAP?” That question invites generic answers: old-fashioned, slow, confusing. Instead, ask a participant to show the most recent time they completed the task or became blocked. Ask what triggered it, what they expected, where they paused, what information was missing, who they contacted, and what they did instead. Real incidents reveal the difference between a dislike and a solvable operational problem.
I once observed shift supervisors at a manufacturer correcting inventory discrepancies during a 20-minute handover window. The official process required several checks across different screens and a reason code that did not match common shop-floor situations. Supervisors kept a paper log and entered corrections later, after the production line had moved on. That workaround was not a failure of adoption. It was a rational response to a workflow designed without the time constraints of the production floor. The strongest recommendation was a constrained set of context-specific reason codes, a faster exception route, and a handover view aligned to the shift sequence.
Every SAP environment encodes a version of how the company believes work happens. Over time, that model drifts. Acquisitions create new approval structures. Regional teams adopt different practices. Policies evolve while configurations remain frozen. The result is an experience gap between system logic and human logic.
Three mismatches deserve special attention. Role mismatch occurs when one person must make a decision that belongs to another function. Timing mismatch occurs when SAP asks for information before it exists or provides information after the decision window has closed. Exception mismatch occurs when the standard path works but ordinary real-world variation forces manual intervention.
Exception mismatch is where most experience programs underinvest. Teams celebrate that 85% of transactions are automated, then treat the remaining 15% as an edge case. But that minority often contains urgent orders, unusual suppliers, cross-border rules, returns, corrections, and high-value financial risk. It can consume more human attention than the automated majority. Improve the exceptions users dread before polishing the happy path that already works.
When someone says SAP is slow, determine whether the screen is slow, the process is slow, or the user’s confidence is slow. Only the first issue is solved by performance tuning.
Behavioral data is excellent at identifying where friction occurs. It is weak at explaining why. A sharp drop-off after an approval request could indicate confusing navigation, missing information, a policy conflict, concern about accountability, or a user who was interrupted and never returned. Treating all drop-off as a UX issue is a costly assumption.
This is where research-grade AI can add real value, provided researchers retain control. AI-moderated interviews can capture in-the-moment explanations while task details are fresh. AI-native qualitative analysis can compare themes across roles, regions, and workflows, surface contradictory evidence, and identify recurring language around uncertainty or workarounds. The researcher must still define the study logic, inspect evidence behind themes, and distinguish a valid pattern from a frequently repeated complaint.
Usercall is designed for this research model: AI-moderated interviews and research-grade qualitative analysis with deep researcher controls over questions, probes, segments, and synthesis. Teams can also use user intercepts at key product-analytic moments to ask why a user abandoned an approval, repeated a correction, or exited a workflow. That combination prevents the familiar mistake of treating a metric as its own explanation.
In one study, a team assumed that a fall in self-service completion reflected a navigation problem because users exited at the same step. Short contextual interviews showed a different cause: people did not have the required account assignment, and the information originated in an upstream request process. A redesigned page would have made the flow look better while leaving the actual blocker untouched.
A credible SAP experience roadmap should not be a backlog of cosmetic screen changes. It should state which decisions will be removed, which controls will be clarified, which exceptions will be redesigned, and which upstream issues must be fixed outside SAP.
The goal is not to make SAP resemble a consumer app. That is a shallow benchmark for complex enterprise work. The goal is to make the work legible, trustworthy, and recoverable. A strong experience with SAP means users can understand what is happening, make an appropriate decision, and complete routine work without a shadow spreadsheet or a private network of favors. That is the standard leaders should research, measure, and fund.
