How do you make a business-critical SAP process faster, easier, and better for the people who use it every day?
June 2026
A consumer-goods manufacturer's field sales team takes orders, returns, and credits inside retail stores across the Baltics — and needed a way to do it faster, more accurately, and without depending on mobile coverage.
Business users don't care about architecture — they care about getting their work done. S5 helped the company simplify a business-critical process with a solution tightly integrated with SAP. The result: higher productivity, better efficiency, and a better experience for the people using it every day.
The need
The customer's old CRM was no longer fit for how their field sales team actually works. Sales reps spend their day inside retail stores — taking orders, handling returns, issuing credits on the fly, checking delivery history, looking up invoices, applying campaign pricing, and managing shelf-life pricing. All of it real-time, in front of the retailer.
In the Baltics, retail is structurally different from the Nordic wholesale model. The market is fragmented across smaller chains and independent stores, and vendor reps often do real commercial work inside the store alongside the retailer. The application had to fit that Baltic reality — not a Nordic assumption about field sales staying outside the store.
The geography made the requirement non-negotiable. Operations stretch across the Baltic countries, where mobile coverage in many of the relevant retail locations is unreliable at best. Offline could not be a fallback — it had to be the default. The application needed to work fully without a network connection, then sync cleanly the moment one returned. And the data underneath it — pricing, inventory, customer history — had to come straight from S/4HANA, not a stale copy.
Our solution
S5 built the sales team a field application shaped around the way reps actually work inside a store — quick to use, reliable when coverage drops, and tightly connected to SAP so the numbers in front of the retailer are always the real ones. It runs in the browser, works fully offline, and syncs to S/4HANA the moment the network comes back. Delivered end-to-end by a single senior specialist covering UX, Fiori, and SAP back-end, using Neptune Open and SAP Editions.
The engagement was senior-owned and Nordic-led, with S5 Labs in Wrocław providing build capacity behind it. UX design, Fiori development, and SAP back-end sat with the same team, which kept decisions coherent and let the project move at the pace of the customer's real questions rather than the slowest handoff.
Neptune was chosen as the low-code platform because it enabled rapid development without sacrificing the SAP-native connection — the same outcome would have taken significantly longer on a custom Fiori build. On a different job, we would choose differently and say so.
1. Scan — the field reality, not the requirements document
We started where the work happens: inside the retail store, with a sales rep on a tablet, no signal, and three customers waiting. The discovery focused on the actual sequence of in-store moments — not a wishlist of features. That framing made the offline-first requirement, the pricing complexity, and the speed-of-use bar unmistakable.
2. Simplify — UX designed for the moment, not the demo
The interface was built for a sales rep standing in front of a retailer with thirty seconds to act — not for a project sign-off meeting. Order capture, returns, credits, delivery history, and campaign pricing were grouped into the few flows the team genuinely uses. Everything else got removed. The result: a UX so direct that training collapsed to almost nothing.
3. Stack — native to S/4HANA, no integration layer to operate
The application runs in the browser, caches everything the rep needs locally — pricing, inventory, customer data — and talks to S/4HANA directly. That means no extra integration layer for IT to operate, monitor, or keep in sync. Less to run in the background, more time for the work that moves the business.
4. Ship — offline-first, sync-when-ready
The application caches the full working set locally — pricing, inventory, customer master, history — so the rep can capture orders, returns, and credits without a connection. The moment coverage comes back, the device syncs against S/4HANA in the background. The rep doesn't switch modes; the system handles it.
5. Steward — senior-owned, Nordic-led, S5 Labs behind it
The whole engagement — UX, Fiori, back-end — was held to one architecture under senior Nordic ownership, with S5 Labs in Wrocław providing build capacity behind it. That kept architectural decisions consistent, removed the multi-vendor coordination tax, and gave the customer a single named face to call, while staying agile enough to move at delivery speed.
Technologies:
Results
- Offline by default
The sales team executes every in-store operation — orders, returns, credits, pricing — with or without mobile coverage. Sync resumes automatically when the network returns.
- Minimal training to ramp up
The UX is built around the actual in-store moment. New reps move from issued device to productive use without a dedicated training programme.
- No integration layer to monitor
Nothing sits between the mobile application and the core to operate, harden, or let drift out of sync. The field workflow stays close to S/4HANA instead of becoming another integration estate.
- Single-team delivery
One senior specialist covered UX, Fiori, and SAP back-end. Decisions stayed coherent, the customer had a single named owner, and the project moved at the speed of real questions.
