Apps für iOS und Android bauen wir als Oberfläche für Automatisierungen: Daten, die vor Ort erfasst werden, Formulare, die ohne Empfang funktionieren, Aufgaben, die der Workflow zuweist, und Statusmeldungen, die Ihre Kunden sehen.
Foto, Zählerstand, Unterschrift und Standort werden vor Ort erfasst, statt abends aus dem Notizbuch abgetippt zu werden. Eine Meldung aus der App startet sofort den Workflow: Beschreibung, Eintrag im System, Benachrichtigung der zuständigen Person.
Im Keller, in der Halle und auf der Baustelle gibt es keinen Empfang. Die App speichert die Daten lokal und überträgt sie, sobald das Netz wieder da ist: ohne doppelte Einträge und ohne verlorene Meldungen, auch wenn jemand die App mittendrin geschlossen hat.
Was die Automatisierung zugewiesen hat, landet auf der Liste einer bestimmten Person: was, wo und bis wann. Wer eine Aufgabe in der App abschließt, schließt damit einen Schritt im Workflow ab und ändert nicht bloß eine Farbe in einer Tabelle.
Buchungen, Bestellungen, Kundenprogramm, Statusansicht des Vorgangs. Alles mit denselben Daten und demselben Kalender wie Website und Voice-Agent: eine Quelle, drei Kanäle.
Push-Nachrichten verschickt der Workflow, nicht ein Mensch: wenn ein Vorgang die Phase wechselt, wenn eine Frist näher rückt, wenn etwas hängen bleibt. Wir gestalten sie so, dass niemand lernt, Benachrichtigungen zu ignorieren.
Testversionen stellen wir schon während der Entwicklung über TestFlight und Firebase App Distribution bereit. Sie probieren die App auf Ihrem eigenen Smartphone aus, lange bevor sie veröffentlicht wird.
Eine mobile App ist die teuerste Oberfläche, die man über einen Workflow legen kann: zwei Plattformen, Entwicklerkonten, Prüfung in den Stores, Updates bei neuen Betriebssystemversionen. Sie lohnt sich, wenn der Prozess bereits läuft und klar ist, was genau im Außendienst passieren soll.
Brauchen Sie weder Kamera noch Offline-Betrieb, Push-Nachrichten oder ein Symbol auf dem Startbildschirm, entsteht dieselbe Funktion im Browser schneller und günstiger, und Änderungen müssen nicht durch die Stores. Das sagen wir im ersten Gespräch, nicht nach Vertragsunterzeichnung.
Eine Codebasis für beide Plattformen. Bei den meisten Business-Projekten ist das das beste Verhältnis von Kosten und Nutzen. Welches von beiden, hängt vom Umfang ab und davon, woran die App angebunden wird.
Nutzt die App die Hardware intensiv oder braucht sie maximale Flüssigkeit, ist eine native Entwicklung die ehrlichere Wahl. Das besprechen wir bei der Klärung des Umfangs, nicht erst nach den ersten Problemen.
Wir entwerfen die Schicht, über die die App mit den Workflows kommuniziert, und den Mechanismus, der Daten nach wiederhergestellter Verbindung nachsendet, ohne dass dabei Dubletten in Ihrem System entstehen.
Der Workflow, den die App mit Daten aus dem Außendienst versorgt und dessen Aufgaben sie anzeigt. Hier beginnt jedes unserer Projekte.
Mehr erfahrenDieselbe Oberfläche, nur im Browser: schneller und günstiger überall dort, wo weder Kamera noch Offline-Betrieb gebraucht werden.
Mehr erfahrenOft nicht. Brauchen Sie weder Kamera noch Offline-Betrieb, Push-Nachrichten oder ein Symbol auf dem Startbildschirm, entsteht dieselbe Funktion im Browser schneller und günstiger, und Änderungen müssen nicht durch die Stores. Das prüfen wir im ersten Gespräch und sagen es offen.
Wir kalkulieren individuell nach einem Gespräch über den Prozess. Die Spanne ist hier größer als bei allen anderen unserer Leistungen, weil der Umfang extrem unterschiedlich sein kann. Die Kalkulation mit Meilensteinen erhalten Sie vor Beginn der Arbeiten.
Das entscheiden wir danach, wo Ihre Nutzer tatsächlich sind. Mit React Native und Flutter entstehen beide Plattformen aus einer Codebasis, daher ist der Unterschied bei den Entwicklungskosten kleiner, als man meist annimmt. Tests und Veröffentlichung bleiben trotzdem doppelte Arbeit.
Wenn der Prozess es verlangt, ja. Die Daten werden lokal gespeichert und nachgesendet, sobald wieder Empfang besteht. Das ist ein eigener Teil des Projekts und ein eigener Teil der Tests, denn die meisten Fehler entstehen genau beim erneuten Senden.
Ja. Die App sollte über Ihre eigenen Konten (Apple Developer Program und Google Play Console) veröffentlicht werden, damit sie Ihr Eigentum bleibt. Wir legen die Konten gemeinsam mit Ihnen an oder prüfen die bestehenden bei der technischen Vorbereitung.
Die Prüfung selbst dauert meist zwischen einigen Dutzend Stunden und wenigen Tagen, manchmal gibt es Anmerkungen der Prüfer, die Korrekturen erfordern. Diesen Schritt übernehmen wir und reagieren auf die Anmerkungen. Mit einer abgelehnten App lassen wir Sie nicht allein.
Ja, und mehr als eine Webanwendung. iOS und Android erscheinen in neuen Versionen, die Stores ändern ihre Anforderungen, Bibliotheken werden aktualisiert. Eine App ohne Updates funktioniert mit der Zeit nicht mehr richtig. Die Betreuung vereinbaren wir bei der Übergabe.
Wählen Sie das Thema und einen Termin — wir melden uns genau zur vereinbarten Zeit. Ein Angebot erstellen wir erst, wenn wir den tatsächlichen Umfang kennen.