Discovery & Mitfahrt mit dem Mitarbeiter
Begleitung im Feld mit regionalen Managern, Kartierung der Offline-Abdeckung, Prüfung der DSGVO- + CCPA-Aufstellung für Kundendatensätze, Anforderungen an rollenbasierten Zugriff je Gebiet.
Fallstudie · AgTech · Interne Tools
Farm — Offline-first-Außendienst-App für die Landwirtschaft
Wie wir Farm ausgeliefert haben — eine native interne iOS- und Android-App für einen Distributor landwirtschaftlicher Güter, dessen Außendienstleiter ihre Tage in Kellern, Lagern und Höfen ohne Netzabdeckung in den USA und der Europäischen Union verbringen. Aufgebaut auf einem Offline-first-SQLite-Speicher, einem Laravel + React-Back-Office und einer Plan-vs.-Ist-Reporting-Schicht, die einer DSGVO- und CCPA-Prüfung standhält — und seit drei Jahren durchgehend im Produktiveinsatz ist.
Die Aufgabenstellung — ein Außendienst-Werkzeug, das ohne Signal funktioniert
Das Farm-Produktteam kam mit einem konkreten operativen Schmerzpunkt. Seine regionalen Vertriebsleiter betreuten landwirtschaftliche Gebiete in den USA und der Europäischen Union, und der tägliche Workflow ähnelte in nichts der Annahme, die jede CRM-Mobile-App von der Stange trifft. Ein Mitarbeiter fuhr neunzig Minuten zu einem Kundenstandort, verlor in einer Scheune oder einem Düngemittel-Lagerkeller das Mobilfunksignal, besprach fünfundvierzig Minuten lang Preise, vereinbarte ein Geschäft und musste es dann erfassen — häufig noch immer ohne Netzabdeckung. Bestehende Werkzeuge verloren den Report entweder stillschweigend oder verlangten vom Mitarbeiter, daran zu denken, ihn vom Auto aus erneut einzureichen. Wir haben den Workflow von Grund auf als native interne iOS- und Android-App neu aufgebaut: ein Offline-first-SQLite-Spiegelbild des Produktkatalogs, ein Deal-Reporting, das lokal in eine Warteschlange gestellt und deterministisch abgeglichen wird, sowie ein regionales Plan-vs.-Ist-Dashboard, das der Senior-Manager zu Beginn jeder Woche öffnet. Das Ergebnis ist ein internes Vertriebswerkzeug, das in den USA und der EU unter DSGVO- und CCPA / CPRA-Anforderungen von Tag eins an ausgeliefert wird, im Portfolio der Mobile App-Entwicklung der YuSMP Group liegt und nun seit drei Jahren unbeaufsichtigt in Produktion läuft.
Projekt-Highlights
Native iOS- & Android-Clients
Offline-first-SQLite-Katalog
Konfliktfreie Deal-Synchronisation
Plan-vs.-Ist-Reporting
Regionale Dashboards in React
Laravel-Admin-Back-Office
Rollenbasierter Zugriff
3 Jahre in Produktion · USA & EU
In Zahlen
Eine Momentaufnahme dessen, was die Farm-Umsetzung über iOS, Android und ein Laravel + React-Back-Office im ersten Produktionszyklus und den darauf folgenden drei Betriebsjahren geliefert hat.
2native Plattformen — iOS in Swift und Android in Kotlin, vollständig getrennte, je OS optimierte Codebasen
3 Jahredurchgehender Produktiveinsatz in US- und EU-Außendienstgebieten mit stabiler Telemetrie
100%der offline erfassten Geschäfte werden bei der nächsten erfolgreichen Synchronisation deterministisch abgeglichen — ohne Duplikate
9 Mon.anfänglicher Umsetzungszeitraum von der Discovery bis zum ersten Produktions-Rollout in beiden Stores
4zentrale Produktkategorien — Düngemittel, Saatgut, chemische Mittel und Geräte — im strukturierten Katalog
14–20 Wo.typischer Lieferzeitraum für eine vergleichbare interne Außendienst-App in beiden Stores
Warum natives iOS und Android statt einer Cross-Platform-Hülle
Die Plattform-Entscheidung dominierte jede andere architektonische Weichenstellung. Wir haben uns für natives Swift auf iOS und Kotlin auf Android statt einer einzigen Cross-Platform-Hülle entschieden, weil die Abwägungen in einem dreijährigen Produktionsfenster sauber zum nativen Weg passen. Native Clients gaben uns erstklassigen Zugriff auf den plattformnativen Core-Data- und SQLite-Stack auf iOS und Room über SQLite auf Android — das Fundament jeder belastbaren Offline-first-Mobile-Architektur. Die Semantik der Hintergrund-Synchronisation unterscheidet sich zwischen iOS BGTaskScheduler und Android WorkManager genug, dass das Verpacken beider in eine einzige Abstraktion uns die Vorhersehbarkeit gekostet hätte, die das Operations-Team für unbeaufsichtigte Mitarbeiter benötigte.
Cross-Platform-Hüllen — React Native, Flutter, der Xamarin-Ausläufer — wurden bewertet und ausgeschlossen. Ihre Abstraktionen über Hintergrundarbeit und plattformnatives SQLite hatten die falsche Form für einen Mitarbeiter-Workflow, der Stunden offline verbringt. Nativ vorzugehen bedeutete, dass der gesamte Stack — Oberfläche, lokaler Speicher, Sync-Engine, Push-Benachrichtigungszustellung — je Plattform verantwortet und durchgängig gegen die Entwicklerdokumentationen von Apple und Google belegbar ist.
| Dimension | Natives Swift / Kotlin (Farm) | React Native | Flutter |
|---|---|---|---|
| Offline-SQLite-Zugriff | Erstklassig — Core Data und Room | Überbrückt — WatermelonDB oder Drittanbieter | Überbrückt — sqflite oder Drift |
| Hintergrund-Synchronisation | BGTaskScheduler / WorkManager direkt | Verpackt — variable Zuverlässigkeit | Verpackt — variable Zuverlässigkeit |
| Akkuprofil bei langen Offline-Sitzungen | Je Plattform abstimmbar | Schwerer — Kosten der JS-Bridge | Leichter als RN, dennoch abstrahiert |
| Wartungskosten über drei Jahre | Zwei stabile Codebasen auf OS-Hersteller-APIs | Aufwand durch Framework-Upgrades | Aufwand durch Framework-Upgrades |
| Native Barrierefreiheit | VoiceOver / TalkBack erstklassig | Akzeptabel — teilweise Lücken | Akzeptabel — teilweise Lücken |
| Zuverlässigkeit von Push-Benachrichtigungen | APNs / FCM direkt | Überbrückt — Notifee / RNFB | Überbrückt — firebase_messaging |
| Tastatur-/Locale-Verhalten je OS | OS-nativ | Verpackt — Randfälle | Verpackt — Randfälle |
Plattform-Referenzen: Apple BGTaskScheduler-Dokumentation, Android WorkManager-Referenz.
iOS-Umsetzung — Swift, Core Data und der Deal-Reporting-Ablauf
Der iOS-Client ist in Swift mit SwiftUI für die Oberflächenschicht und Core Data über SQLite für den lokalen Speicher aufgebaut. Die gesamte Deal-Reporting-Oberfläche reduziert sich auf einen einzigen Zustandsautomaten — Entwurf, in Warteschlange, synchronisierend, abgeglichen — und der Mitarbeiter sieht im Nutzerablauf nie einen Netzwerkfehler, weil der Report bereits lokal persistiert wurde, bevor der Bildschirm seine Ausblend-Animation beendet. Die Kundensuche läuft gegen den Speicher auf dem Gerät ohne Netzwerk-Roundtrip, der Katalog wird in eine Lazy-Liste seitenweise geladen, und die Preise werden aus der lokal zwischengespeicherten Preislisten-Version aufgelöst, die bei der letzten erfolgreichen Synchronisation des Mitarbeiters maßgeblich war.
Beim Abgleichspfad verlieren die meisten internen Vertriebs-Apps an Korrektheit — und genau hier haben wir überproportionalen Engineering-Aufwand betrieben. Der Ablauf ist: den Report mit einem monotonen Client-Zeitstempel und einem UUID-Idempotenz-Schlüssel in Core Data schreiben, ihn in BGTaskScheduler in eine Warteschlange stellen, bei jedem Konnektivitätswechsel eine Synchronisation versuchen und den Server den kanonischen Berechtigungsdatensatz zurückgeben lassen. Duplikate sind unmöglich, weil der Idempotenz-Schlüssel die primäre Korrelation ist, und ein in einem Keller in Schweden abgeschlossener und zwei Stunden später im Zug wieder geöffneter Verkauf gleicht sauber ab. Die durchgängige iOS-Oberfläche wird im Rahmen unserer Leistung iOS- und Android-Engineering erbracht.
Android-Umsetzung — Kotlin, Room und die Sync-Engine
Der Android-Client ist in Kotlin mit Jetpack Compose für die Oberfläche und einer Room-Schicht über SQLite für den lokalen Speicher geschrieben. WorkManager übernimmt den Zeitplan der Hintergrund-Synchronisation mit Backoff-Semantik, die den Doze-Modus sowie die Akku-Optimierer von Samsung, Xiaomi, OnePlus und Pixel respektiert — ohne einen Vordergrunddienst würde die Sync-Engine innerhalb von Minuten leise in einem aggressiven OEM-Container sterben und damit den impliziten Vertrag brechen, dass ein Offline-Report letztlich im Dashboard des Managers erscheint. Eine minimale persistente Benachrichtigung hält die langlaufende Synchronisation über die Gerätefamilien Android 10 bis Android 14 hinweg am Leben.
In der Sync-Engine verdient der Android-Client sein Geld. Das Delta auf dem Gerät wird bei jedem Konnektivitätswechsel an eine Laravel-API geschickt, der Server gibt die maßgebliche Preisliste und Kundenliste zurück, und die Konfliktauflösung ist deterministisch — der Server gewinnt bei Preisen und Kundendatensätzen, der Client gewinnt bei Notizen aus dem Feld und vom Mitarbeiter angehängten Metadaten. Nach einer Übergabe von WLAN auf LTE setzt die Engine das letzte Sync-Token automatisch fort, und die Katalogaktualisierung ist inkrementell statt ein vollständiges Neuladen — ein Mitarbeiter mit einem 250-MB-Lokalspeicher lädt den Katalog nicht jeden Montag erneut herunter. Dasselbe Engineering-Team führt iOS und Android im Gleichschritt als Teil unserer Leistung Mobile App-Entwicklung.
Back-Office, Plan vs. Ist und Audit-bereite Aufstellung
Das Farm-Back-Office liegt auf einer Laravel-API mit einem React-Admin und hält nur die Daten, die es muss — Kundenliste, Produktkatalog, Preisliste, vierteljährliche Verkaufsquoten und den aus dem Feld einströmenden Deal-Report-Strom. Es gibt keine Standortverfolgung je Mitarbeiter, keine Tastenanschlag-Erfassung bei Untätigkeit und keine Metadaten-Leitung zu einem Drittanbieter für Observability. Zähler, die das regionale Plan-vs.-Ist-Dashboard antreiben, werden serverseitig aggregiert und als anonyme numerische Reihen ausgeliefert; kundenbezogene Identifier verlassen die Kundentabelle nicht.
Die Abrechnungsidentität der eigenen Kunden des Distributors — der Höfe und landwirtschaftlichen Genossenschaften, die das Produkt kaufen — wird im selben Laravel-Speicher gehalten, aber über ein rollenbasiertes Berechtigungsmodell zugriffsbeschränkt, sodass ein Außendienstmitarbeiter nur die Kunden seines Gebiets sieht. Infrastructure-as-Code-Richtlinien setzen die Zugriffs-Invarianten durch — jeder Pull Request, der den Lesebereich eines Mitarbeiters erweitern oder ein Standort-Log je Mitarbeiter einführen würde, scheitert in der CI. Die Aufstellung ist darauf ausgelegt, den Verpflichtungen der DSGVO für Nutzer in der Europäischen Union und den Verpflichtungen von CCPA / CPRA für Nutzer in Kalifornien und den übrigen USA zu entsprechen — und eine künftige unabhängige Bereitschaftsprüfung zu einer Dokumentationsübung statt zu einer architektonischen Nachrüstung zu machen.
Compliance-Aufstellung: DSGVO-konform · ISO-27001-bereit · SOC 2 Type II in Vorbereitung · HIPAA-fähig · CCPA-berücksichtigt.
Liefermethodik
Eine fünfphasige Umsetzung, die Farm von Gebietsforschungs-Interviews bis zur Produktion über iOS, Android und ein Laravel + React-Back-Office brachte.
Katalog- & Sync-Modell
Schema des Produktkatalogs, strukturierte Preise, Entwurf des Sync-Tokens, Idempotenz-Schlüssel-Vertrag für Deal-Reports, Laravel-API-Grundgerüst, React-Admin-Gerüst.
Plattform-Umsetzungen
Swift / SwiftUI-iOS-Client auf Core Data + BGTaskScheduler; Kotlin / Jetpack Compose-Android-Client auf Room + WorkManager; Zustandsautomat für das Deal-Reporting.
Audit-bereite Härtung
Infrastructure-as-Code-Richtlinien, die Regressionen beim Zugriffsbereich blockieren, QA der rollenbasierten Berechtigungen, Crash-Telemetrie-Pipeline, Prüfung des dreijährigen Betriebsrahmens.
Launch & Telemetrie
Einreichung zur internen Verteilung über App Store + Google Play in US- und EU-Storefronts, Rollout der regionalen Dashboards, Plan-vs.-Ist-Umstellung für Senior-Manager.
Plan vs. Ist, Quotenzuweisung und die Manager-Ansicht
Die Reporting-Schicht von Farm wurde so gebaut, dass Feld-Reporting und Manager-Analytik nachweislich übereinstimmen, denn die Plan-vs.-Ist-Schleife bricht in dem Moment auseinander, in dem ein Manager und ein Mitarbeiter in derselben Woche unterschiedliche Zahlen für denselben Kunden sehen. Die vierteljährliche Quote wird von einem Senior-Manager im React-Admin festgelegt und bei der nächsten Synchronisation in den lokalen Speicher jedes Mitarbeiters geschoben. Der Mitarbeiter sieht seinen eigenen Fortschritt in der Mobile-App — eine einzelne Sparkline gegen den Plan, aufgeschlüsselt nach Produktkategorie — und der Senior-Manager sieht das regionale Aggregat im Back-Office mit Drilldown zu Aufschlüsselungen je Mitarbeiter und je Kunde. Die serverseitige Aggregation läuft gegen einen einzigen maßgeblichen Deal-Report-Strom, den die Mobile-Clients über den Idempotenz-Schlüssel-Pfad speisen, sodass die Manager-Ansicht und die Mitarbeiter-Ansicht stets auf dieselbe Quelle der Wahrheit abgleichen. Storno-Bearbeitungsverhalten, spät eintreffende Offline-Reports und vom Mitarbeiter angehängte Notizen aus dem Feld lesen alle aus demselben Datensatz, sodass sich ein einzelnes Geschäft sauber über Neuinstallationen, Gerätewechsel und das spätere Web-Portal hinweg auflöst. Das gesamte Subsystem wurde mit Blick auf Erweiterbarkeit gebaut: Eine Multi-Währungs-Stufe, eine Provisions-Engine je Gebiet oder eine B2B-Partner-Mitarbeiter-Erweiterung hinzuzufügen ist eine Konfigurationsänderung am Back-Office, kein Code-Release.
Launch in den USA und der Europäischen Union
Farm ging im Apple App Store und bei Google Play (interne Verteilung) mit in den USA und der Europäischen Union aktiven Storefronts an den Start. Der englischsprachige Build bedient Außendienstmitarbeiter in Kalifornien, New York, Texas, Florida und Washington in den USA sowie in den Niederlanden, Deutschland, Frankreich, Irland und Schweden in der EU — ohne separate Codebasis je Region. Einwilligungsabläufe sind auf der Back-Office-Ebene regionsbewusst: Mitarbeiterkonten in der EU und im EWR erhalten einen DSGVO-konformen granularen Einwilligungsdialog für jede optionale Produkt-Telemetrie, und Konten in Kalifornien erhalten im selben Anmeldeablauf eine CCPA-konforme „Do Not Sell or Share My Personal Information"-Offenlegung. Die Datenverarbeitungspraktiken sind auf die DSGVO für europäische Nutzer und auf das Flickwerk der US-Datenschutzgesetze der Bundesstaaten abgestimmt — CCPA / CPRA (Kalifornien), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) und Oregon CPA. Da die Architektur Tracking-Daten je Mitarbeiter minimiert, reduziert sich regionale Compliance auf ehrliche Offenlegung statt auf eine Datentrennung je Rechtsraum.
Die Laravel-API wurde parallel über EU- und US-Regionen ausgerollt — Niederlande, Deutschland, Frankreich, Schweden und Irland für die EU-Abdeckung; US East und US West für Nordamerika — wobei die zustandslosen Worker jeder Region identisch bereitgestellt wurden. Der Aggregations-Service, der das regionale Plan-vs.-Ist-Dashboard antreibt, betreibt zustandslose Worker, die für künftige Daten-Residenz-Verpflichtungen unabhängig an EU- oder US-Regionen gebunden werden können. Sowohl die App-Store- als auch die Google-Play-Verteilung wurden für die interne Enterprise-Anmeldung kalibriert, und die In-App-Datenschutzoffenlegung dokumentiert genau die obige Architektur, mit direktem Verweis auf die DSGVO-Verpflichtungen und die kalifornischen CCPA-Verpflichtungen. Das Engineering-Team hinter der Umsetzung arbeitet in der MEZ und folgt einem MEZ-Arbeitstag mit Überlappung mit der US-Ostküste (9–13 Uhr ET) für Stand-ups, die Choreografie der Store-Prüfung und die Incident-Reaktion — die Zeitzone, die einem US-Produktteam und einem EU-Engineering-Team täglich vier Stunden Live-Überschneidung beschert.
Tech-Stack und Roadmap
Swift
SwiftUI
Core Data
BGTaskScheduler
Kotlin
Jetpack Compose
Room
WorkManager
SQLite
Laravel
PHP 8
React
PostgreSQL
Redis
APNs
Firebase Cloud Messaging
Docker
Terraform
Prometheus
Die aktive Roadmap für individuelle Softwareentwicklung von Farm umfasst eine Provisions-Engine je Gebiet, eine Multi-Währungs-Preisliste für grenzüberschreitende Distributoren, einen verschleierten Offline-Share-Transport, sodass Mitarbeiter einen Deal-Report im Feld von einem Gerät auf ein anderes übergeben können, ohne den Umweg über den Server zu nehmen, sowie einen auf Tauri aufgebauten Desktop-Client, der die Geschäftslogik mit der Mobile-Codebasis teilt. Eine B2B-Partner-Mitarbeiter-Stufe mit eigener Kundenliste, Teamverwaltung und SSO ist für Mid-Market-Distributoren in den USA und der EU geplant, wobei das Berechtigungs-Subsystem bereits für die Mehrplatz-Zuweisung strukturiert ist. Die Infrastrukturpläne umfassen weitere Cloud & DevOps-Automatisierung der regionalen Rollout-Pipeline, ein internes Continuous-Verification-Harness für den Korrektheitsvertrag der Offline-Synchronisation sowie eine künftige unabhängige Bereitschaftsprüfung, die in den Betriebsrhythmus eingebettet ist.
Eine Außendienst-App wie diese bauen — sprechen Sie mit uns
Wenn Sie eine interne Außendienst-Mobile-App, ein Offline-first-AgTech-Tool oder eine beliebige Mobile-App planen, bei der Mitarbeiter Stunden ohne Netzabdeckung verbringen und die Reporting-Schleife einer externen Prüfung für Zielgruppen in den USA und der EU standhalten muss, haben wir diesen Stack durchgängig ausgeliefert und können den Zeitplan der Umsetzung deutlich verkürzen. Das Live-Produkt wird vom Distributor intern betrieben unter yusmpgroup.ru/cases/farm (Fallstudienseite), und das Engineering-Team dahinter sitzt innerhalb der YuSMP Group. Wir arbeiten zum Festpreis bei gut abgegrenzten MVPs und mit dedizierten Entwicklerteams für die laufende Lieferung — mit einem MEZ-Arbeitstag und einem garantierten Zeitfenster der Überlappung mit der US-Ostküste (9–13 Uhr ET) für Stand-ups, Demos und Incident-Reaktion.
Häufig gestellte Fragen
Was kostet die Entwicklung einer internen Außendienst-Mobile-App für Distributoren?
Eine interne Außendienst-Mobile-App mit iOS- und Android-Clients, einem offline-fähigen Produktkatalog, Deal-Reporting und einem Laravel- oder Node-Back-Office kostet für ein MVP typischerweise 80.000–180.000 $. Ergänzt man regionale Plan-vs.-Ist-Dashboards, rollenbasierte Berechtigungen, konfliktfreie Offline-Synchronisation, Push-Erinnerungen und Integrationen in einen bestehenden ERP- oder 1C-artigen Buchhaltungs-Stack, ergibt sich für ein voll ausgestattetes Rollout ein Rahmen von 220.000–450.000 $. Der wichtigste Kostentreiber ist die Korrektheitsarbeit der Offline-Synchronisation sowie die Preislogik je Region.
Warum ein nativer iOS- und Android-Build statt eines Cross-Platform-Frameworks?
Außendienstmitarbeiter in landwirtschaftlichen Gebieten arbeiten stundenlang offline, in Kellern, Lagern und Feldern ohne Signal. Native Swift- und Kotlin-Clients erlauben uns, den Akkuverbrauch während langer Sync-Sitzungen zu steuern, plattformnative SQLite-Speicher sauber zu integrieren und Tastatur- und Barrierefreiheitsverhalten je OS auszuliefern, das React Native und Flutter weiterhin in Kompromisse verpacken. Mit Blick auf ein dreijähriges Betriebsfenster fielen die Wartungskosten zweier nativer Codebasen geringer aus als die kumulierten Kosten, Cross-Platform-Abstraktionen zu umgehen.
Wie baut man eine echte Offline-first-Mobile-Vertriebs-App?
Eine belastbare Offline-first-Aufstellung ist eine Architekturentscheidung, kein Feature-Schalter. Der vollständige Produktkatalog, die Preistabellen und die Kundenliste werden beim ersten Login in einen lokalen SQLite-Speicher gespiegelt und bei jeder erfolgreichen Synchronisation inkrementell aktualisiert. Offline geschriebene Deal-Reports werden mit monotonen lokalen Zeitstempeln in eine Warteschlange gestellt und auf dem Server mithilfe von Idempotenz-Schlüsseln abgeglichen, sodass ein Mitarbeiter, der in einem Keller einen Verkauf abschließt und die App zwei Stunden später im Zug wieder öffnet, eine Transaktion nie dupliziert oder verliert. Die Konfliktauflösung ist deterministisch — der Server gewinnt beim Preis, der Client gewinnt bei Notizen aus dem Feld.
Was leistet die Farm-App für Außendienstleiter in der Landwirtschaft?
Farm ist das interne Werkzeug, das ein regionaler Vertriebsleiter zu einem Hofbesuch mitnimmt. Es zeigt einen strukturierten Katalog aus Düngemitteln, Saatgut, chemischen Mitteln und Geräten mit aktuellen Preisen; ermöglicht dem Mitarbeiter, in Sekunden einen Deal-Report für einen bekannten Kunden zu erfassen; verfolgt Plan vs. Ist gegen die vierteljährlichen Verkaufsziele des Mitarbeiters; und zeigt ein Dashboard auf Manager-Seite, das die Zahlen nach Produktkategorie und Region aufschlüsselt. Push-Erinnerungen stupsen nicht erfasste Reports an, und ein Back-Office-Admin in React verwaltet Katalogaktualisierungen, Preisänderungen und die Quotenzuweisung.
Wie lange dauert die Bereitstellung einer internen Außendienst-App auf iOS und Android?
Ein fokussiertes MVP mit nativen iOS- und Android-Clients, einem Offline-first-Katalog, Deal-Reporting und einem Laravel-Admin dauert typischerweise 14–20 Wochen. Ergänzt man das regionale Dashboard auf Manager-Seite, die Plan-vs.-Ist-Analytik, rollenbasierte Berechtigungen für Senior-Manager und Außendienstmitarbeiter sowie die konfliktfreie Sync-Schicht, kommen 6–10 Wochen hinzu. Die Härtung der App für drei Jahre unbeaufsichtigten Produktivbetrieb — Crash-Telemetrie, Push-Zuverlässigkeit, Sync-Replay-Logs — wird häufig unterschätzt und sollte mit 4–6 Wochen dedizierter Arbeit eingeplant werden.
Verwandte Fallstudien
Weitere Mobile- & Interne-Tools-Projekte
Field Ops · Mobile
CheckList
Mobile Field-Audit-App für Inspektoren — offline-fähige Formulare, Mehrfach-Fotoaufnahme, Manager-Dashboard.
Fallstudie ansehen → Retail Ops · MobileSuperStep
Interne Schulungs- und Performance-App für eine Einzelhandelskette — Wissensdatenbank, Performance-Tracker, Back-Office.
Fallstudie ansehen → Autoteile · B2BZipIt
B2B-Autoteile-Marktplatz mit Lieferanten-CRM, strukturiertem Katalog und Bestell-Workflow in den USA & der EU.
Fallstudie ansehen →