An offline-first field sales mobile app on S/4HANA, built by one senior team
June 2026
A consumer-goods manufacturer's field sales team takes orders, returns, and credits inside retail stores across the Baltics — where mobile coverage drops out as often as it works.
S5 Consulting designed and built an offline-first field sales web application for the team — running in the browser with full offline support, delivered by a single senior specialist, and connected directly to S/4HANA without a middleware layer.
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 designed an offline-first field sales web application for the team — built to run in the browser, with full offline support through local caching, and connected natively to S/4HANA without a middleware layer. Shaped around how the sales rep actually works inside a store, not how a project meeting imagines it. Delivered by a single senior specialist owning UX, Fiori, and SAP back-end, using Neptune Open and SAP Editions as the technology footprint.
A single senior specialist owned the engagement end-to-end — UX design, Fiori development, and SAP back-end development in one person. That collapsed the usual coordination overhead of multi-vendor mobile projects and let the team move at the pace of the customer's real questions, not 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 architectural decision was to run the application in the browser with full offline capability — local caching of pricing, inventory, and customer data — and connect it directly to S/4HANA without a middleware layer. Neptune enabled the embedded front-end and back-end pattern, but the important point is operational: nothing extra to monitor, patch, harden, or let drift out of sync.
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 — one senior owner, no offshore handoff
The whole engagement — UX, Fiori, back-end — sat with one senior S5 specialist, the way every S5 engagement runs. That kept architectural decisions consistent, removed the multi-vendor coordination tax, and gave the customer a single named face to call. It also kept the team small enough to stay agile through rollout.
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.
