Lesson 2 of 6
A prompt pattern for SAP work
10 min
Listen to this lesson
Anthropic, OpenAI and Google each publish prompt-engineering guides for their models. They differ in detail, but they agree on the core: be clear and specific, give context and the reason behind instructions, show examples, separate instructions from data, and say exactly what output you want. Anthropic adds a useful test: show your prompt to a colleague who knows nothing about the task, and if they'd be confused, the model will be too. This lesson turns that common ground into a six-part pattern for SAP work.
The six parts
Separate instructions from data
When a prompt mixes instructions with pasted material (an IDoc, a transport list, a workshop note), the model can confuse the two. All three providers suggest marking sections clearly. Anthropic recommends XML-style tags such as <instructions>, <context> and <document>; OpenAI's guide uses Markdown headers and XML tags; Google suggests consistent prefixes such as "Input:" and "Output:". Any consistent scheme works. Pick one for your team and use it everywhere.
Order matters for long inputs. Anthropic's guide recommends putting long documents near the top of the prompt and the question at the end, which it says improved response quality by up to 30 percent in its tests with complex, multi-document inputs.
| Weak prompt | Why it fails | Stronger version |
|---|---|---|
| How do I post a goods issue? | No release, no process, no format; the model guesses (often ECC) | Role + release + process: "For SAP S/4HANA Cloud Private Edition 2025, list the steps to post goods issue for an outbound delivery. Use only apps and transactions you are sure exist in that release; mark anything uncertain." |
| Write test cases for order to cash | Too broad; output length and structure vary every time | Give the process description, the data and a table format with one example row |
| Fix this error: [paste] | No context on what the system is or what "fix" means | Ask for a classification and likely causes, with the exact message quoted back, and no invented settings |
Three common prompts and how to strengthen them.
System and user messages
Most enterprise tools and APIs separate a system (or developer) message from the user message. OpenAI's guide describes developer messages as the place for the application's rules and user messages for the inputs; Anthropic recommends setting the role in the system prompt. In a chat interface you usually only see the user box, but many enterprise workspaces let you save "instructions" or a "project" prompt that acts like a system message. Put the stable parts there (role, constraints, output format) and paste only the changing input each time. That's how a team template stays consistent.
Give reasons, not just rules
Anthropic's guide makes a point that surprises people: explaining why an instruction matters often works better than shouting it. "Use only transactions named in the context, because the reader will execute these steps in a regulated quality system" outperforms "NEVER invent transactions". The model generalizes from the reason.
Iterate like a tester
Prompting is iterative, and the providers say so plainly. Anthropic's guide starts with "define success criteria and ways to test them" before you tune a prompt. OpenAI recommends evaluation suites and pinning production apps to specific model versions so behavior doesn't drift silently. Google lists iteration strategies: rephrase, switch to an analogous task, reorder content. For an SAP team, that means keeping a small set of inputs with known good outputs and re-running them whenever you change the prompt or the model.
The same pattern, adapted for Joule
Joule already knows your system, your release and your authorizations, so the context part of a Joule prompt is shorter: you don't paste data, you name it. What still makes the difference is being specific about the business object, the outcome and who should handle it. The table shows how the six parts translate.
| Part | In a general-purpose LLM | In Joule |
|---|---|---|
| Role | Set it yourself ("You are an SAP test analyst") | Comes from your user and business role; route to an assistant with an @mention, for example @Accounts Receivable Assistant |
| Context | Paste the release, process and data | Name the object: customer 17100001, invoice 90001877, company code 1710 |
| Task | One clear instruction | One outcome per request: "Show the overdue items for customer 17100001 and summarize the dunning history" |
| Constraints | Written into the prompt | Mostly enforced by authorizations and agent confirmations; still say what you don't want changed |
| Output format | Specify a table, list or length | Ask for a short summary or a list; open the source app for the full record |
| Verification | Check against SAP Help and the system | Read the Source and AI Reasoning section and confirm the objects it used |
The six-part pattern in a general-purpose LLM and in Joule. Joule supplies context from the system; you supply precision.
What would you do?
Maria asks a model: "Explain pricing in SAP." The answer is long, generic and mentions condition types Contoso doesn't use. What is the best next prompt?
- Six parts: role, task, context, constraints, examples, output format.
- Separate instructions from pasted data with tags or headers; put long documents first and the question last.
- Explain why an instruction matters; models generalize from reasons.
- Treat prompts like test scripts: success criteria, known inputs, one change at a time, saved templates.
Check your understanding · not graded
Lesson check
1. Which six parts make up the prompt pattern in this course?
2. Why separate instructions from pasted data with tags or headers?
3. For a long input such as a transport list, where does Anthropic's guide suggest placing the question?
4. How many examples does Anthropic's guide suggest for best results?