SAP S/4HANA
SAP S/4HANA is where a large organisation keeps the truth about its own operations — what was ordered, what was delivered, what was invoiced, what is still owed and what is sitting in a warehouse. Connecting an assistant to it means customers and staff stop asking people to look things up in it.
SAP S/4HANA is where a large organisation keeps the truth about its own operations — what was ordered, what was delivered, what was invoiced, what is still owed and what is sitting in a warehouse. Connecting an assistant to it means customers and staff stop asking people to look things up in it.
What SAP S/4HANA holds, and why that matters here
S/4HANA is the operational core of many large Saudi enterprises: manufacturing, distribution, utilities, large retail groups and much of the public sector supply chain. It is the record of what physically and financially happened, which makes it the single most valuable thing an assistant can be pointed at — and the one most carefully guarded.
The reason it generates so much contact is that the information inside it is exactly what people ask about, and almost nobody outside the business has direct access to it. Every "where is my order" and "has that invoice been paid" is a question whose answer already exists in S/4HANA and is currently being retrieved by a person on the asker's behalf.
- Sales and delivery — orders, line items, delivery notes, shipment status, backorders.
- Finance — invoices, payment status, credit position, open items, dunning state.
- Materials — stock on hand, stock by location, availability dates, reservations.
- Procurement — purchase requisitions and orders, goods receipts, supplier confirmations.
- Master data — customers, vendors, materials, pricing conditions and terms.
Questions this connection lets Elbi answer
Where is my order?
Order status, the delivery note it sits on, and the expected date — answered from the live record rather than an estimate, and phrased as a sentence rather than a status code.
Is this in stock?
Availability by item and by location, including whether the quantity asked for can actually be met and when the next inbound arrives if it cannot.
Has our invoice been paid?
Open items and payment state for a given account, so finance teams stop fielding the same call at month end.
What is our credit position?
Available credit and blocked-order state, which is the real reason many orders stall and the thing customers are rarely told without asking.
When will the purchase order arrive?
Goods receipt status and supplier confirmation dates for internal users chasing procurement.
What did we agree on price?
The pricing condition that applies to this customer for this material, rather than list price — the single most common cause of disputed invoices.
How the connection works in practice
- You decide what is readableBefore anything is connected, you define the scope: which records, which fields, which operations. The assistant is given a narrow, named view of SAP S/4HANA rather than general access, and that view is agreed in writing during deployment.
- A question arrives in natural languageA customer or an employee asks something ordinary — "where is my order", "am I covered for this", "what did I spend last month". No syntax, no menu, no reference number required if the person is already identified.
- The assistant works out what is being askedThe question is matched to an intent and the details it needs. If something essential is missing, it asks for that one thing rather than presenting a form.
- It reads only what it is allowed to readThe lookup runs inside the permission scope you defined, and inside the permissions of the person asking. Someone who cannot see a record in SAP S/4HANA cannot see it through Elbi either — the assistant does not become a way around your own access rules.
- The answer is written back in plain languageA record is not an answer. The result is turned into a sentence in the language the question was asked in, with the parts that matter surfaced and the internal codes left out.
- Anything it cannot do goes to a personReads are safe to automate. Anything that changes money, entitlement or a legal position can be routed to a human for confirmation — you decide which side of that line each action sits.
Scope, control and what stays yours
| Direction of access | Read by default. Any write-back — creating a ticket, updating a record, logging a lead — is enabled deliberately, per action, and can be held behind human confirmation. |
|---|---|
| Who can see what | The assistant answers within the permissions of the person asking. Identity is established through your own sign-in, not invented by the assistant. |
| Credentials | The connection uses credentials you issue and can revoke, scoped to the narrow view agreed at deployment. Revoking access is something you do on your side, without our involvement. |
| Where data goes | Retrieved records are used to answer the question in front of the assistant and are not retained afterwards beyond your configured conversation retention. |
| Audit | Every lookup can be recorded — what was asked, what was retrieved, which agent, which conversation — so the connection is reviewable rather than opaque. |
| If it is unavailable | If SAP S/4HANA cannot be reached, the assistant says so plainly and offers a person. It does not guess at a value it could not retrieve, and it does not present a cached figure as though it were live. |
What this replaces
The pattern in most organisations is the same. A customer asks a question. A call-centre agent cannot see S/4HANA, so they raise an internal request. Someone in customer service or finance who does have access looks it up, replies, and the agent relays the answer. The round trip is measured in hours or days, for a fact that was available in milliseconds.
Connecting the assistant collapses that. The lookup happens while the customer is still in the conversation. The internal request is never created. The person who would have done the lookup keeps their afternoon, and the customer stops phoning to chase the chase.
The second thing it removes is the screenshot habit. Where staff cannot get answers quickly, they build private workarounds — exported spreadsheets, screenshots in chat groups, personal notes of who to ask. Those copies are stale the moment they are made and are a genuine data protection problem. An assistant that answers reliably removes the reason they exist.
How different sectors use it
Manufacturing
Production order status, material availability, and delivery commitments — asked by sales staff who need an answer while the customer is on the line.
Distribution
Stock by location and lead times, which is the entire conversation in wholesale and the reason quotes go stale.
Public sector supply
Purchase order and goods receipt status for suppliers chasing payment, which is high-volume, low-value contact that nobody wants to staff.
Utilities
Connection and works order status, where the customer wants a date and the record has one.
Getting the value out of it
A connection is only as useful as the questions it is pointed at. The pattern that works is to start from the contact you already receive rather than from what the system can technically expose. Pull a month of chat transcripts and call notes, count the questions, and connect for the top five. That is almost always where the volume is, and it is usually duller than anyone expects — status, eligibility, balance, hours, documents.
The second thing that decides success is scope discipline. It is tempting to connect broadly and let the assistant work out what is relevant. It works far better to expose a small, well-named set of operations and expand once you have seen a month of real questions against them. A narrow connection is easier to reason about, easier to audit, and far easier to explain to whoever signs off on it.
The third is knowing what not to automate. Reads are safe. Anything that moves money, changes an entitlement or creates a commitment should either stay with a person or pass through one. The assistant is at its best when it removes the lookup and leaves the judgement.
What connecting it actually involves
- Agree the questions firstNot the fields, the questions. A month of real transcripts, counted, gives a ranked list of what people actually ask. That list decides the scope; the scope decides the connection. Starting from what SAP S/4HANA can technically expose produces a broad connection answering questions nobody asked.
- Define the readable viewYour team decides which records and fields the assistant may see, and which it must never see. This is written down, signed off, and is the document you will hand to whoever audits the deployment later.
- Issue scoped credentialsYou create the credentials, on your side, scoped to that view. They are yours: you can rotate or revoke them without involving us, and doing so takes effect immediately.
- Map your instanceCustom fields, renamed objects, local terminology and the particular way your organisation uses the system are mapped during deployment. Nobody has a stock configuration and the work assumes you do not either.
- Rehearse the unhappy pathsMissing record, ambiguous match, system unavailable, customer asking about someone else's account. These are tested deliberately before launch, because they are what determines whether people trust the assistant, and they are what most pilots skip.
- Launch narrow, widen on evidenceGo live on the top few questions, watch a month of real traffic, then widen. Every deployment that widened first and measured later has produced the same result: an assistant nobody trusts and a project that quietly stops.
Governing a connection you will have to defend
A connected assistant is a data-processing decision before it is a technology one. Under the Saudi Personal Data Protection Law, the questions that matter are the ordinary ones: what personal data is being processed, on what lawful basis, for how long it is kept, who can see it, and what happens when someone asks for it to be deleted. A lookup against SAP S/4HANA touches most of those at once.
The practical answer is scope and evidence. Scope means the assistant reads a narrow, named view rather than holding broad access, so the question "what could it see?" has a short and checkable answer. Evidence means every lookup can be recorded — the question, the retrieval, the agent, the conversation — so a review after the fact is reading a log rather than reconstructing a story.
The part most organisations underestimate is consent. If a customer is going to have their record read during a conversation, that has to be something they agreed to, in language they understood, in the language they speak. Retrofitting consent after launch is far more painful than designing the flow around it, and it is the single most common reason a pilot stalls at legal review rather than at the technical stage.
What organisations typically see
How this is done elsewhere, and where it goes wrong
The mainstream pattern across the industry is now well established: a conversational layer in front of systems of record, retrieving rather than remembering, escalating rather than improvising. Where deployments fail, they fail in recognisable ways.
The most common failure is connecting everything at once. A broad connection is harder to reason about, harder to permission correctly, and produces an assistant that occasionally surfaces something it should not — which is the single fastest way to lose internal trust and have the project shut down. Narrow beginnings survive; broad ones get switched off.
The second is treating the assistant as a reporting tool. Systems of record are optimised for transactions, not analysis, and an assistant asked to compute across large volumes will be slow and occasionally wrong. Point it at facts about a specific record and it is excellent; point it at "summarise our quarter" and it is the wrong instrument.
The third is forgetting the unhappy path. Systems go down, records are missing, a customer asks about an order that does not exist. What the assistant does in those moments defines how it is perceived far more than what it does when everything works — which is why saying "I could not reach that system" is a feature, not an admission.
Common questions
No structural change. The connection reads through the interfaces your instance already exposes, scoped to the specific operations agreed at deployment. Custom fields and renamed objects are mapped during that work rather than assumed away.
The approach is the same and the questions people ask are identical. What differs is which interfaces are available on your release, which is established during deployment.
It sees only what the scope allows. Internal cost and margin fields are normally excluded outright, so the question cannot arise even if a customer asks cleverly.
No. The connection runs between your assistant and your system, using credentials you issue and control. What the assistant may read is the narrow scope you defined, and you can revoke it at any time without going through us.
Most deployments are. Custom fields, renamed objects and bespoke workflows are normal, and the connection is mapped to your instance during deployment rather than assuming a stock configuration.
It can, where you enable it. The default is read-only because that is the safe starting point. Write actions are turned on individually and can require a person to confirm before they commit.
Connect it to your own systems
A working assistant against your own records, in both languages.