Twój system firmowy dostępny dla klientów także w aplikacji
Masz już system, w którym znajdują się dane klientów, ich sprawy lub usługi? Możemy zaplanować aplikację na iOS i Androida jako kolejne miejsce korzystania z tych funkcji. Zaczynamy od jednego zadania klienta, sprawdzamy dostępne API i ustalamy, skąd pochodzą dane. Dzięki temu projekt nie zaczyna się od budowy drugiej, niezależnej wersji całego systemu.
Firmy, z którymi pracowaliśmy nad produktami cyfrowymi
Klienci uwielbiają z nami pracować
Jak połączyć aplikację klienta z działającym zapleczem
Zadanie, które klient wykona na telefonie
Wybieramy konkretną czynność: sprawdzenie informacji, przesłanie zgłoszenia lub inne działanie uzgodnione dla Twojego procesu. Aplikacja ma upraszczać tę ścieżkę, a nie kopiować wszystkie ekrany systemu.
Ocena dostępnego API
Sprawdzamy, jakie dane system potrafi udostępnić i jakie operacje dopuszcza. Dokumentacja, środowisko testowe i sposób uwierzytelniania wpływają na zakres prac równie mocno jak wygląd aplikacji.
Konto i dostęp do własnych danych
Ustalamy relację między użytkownikiem aplikacji a klientem w systemie. Projektujemy zasady dostępu tak, aby interfejs pokazywał wyłącznie uzgodnione informacje i działania właściwe dla danego konta.
Jedno źródło informacji
Określamy, który system przechowuje dane źródłowe, co aplikacja jedynie odczytuje, a co może zmienić. Uwzględniamy opóźnienia, niepełne dane i ponowienie operacji, zamiast zakładać, że każda wymiana zawsze się powiedzie.
Mobilna ścieżka klienta
Dobieramy ekrany i komunikaty do obsługi na telefonie. Przy funkcjach wymagających szybkiego powrotu możemy rozważyć powiadomienia; nie zastępują one jednak poprawnego zapisu i odczytu informacji z systemu.
Wdrożenie i ciągłość procesu
Planujemy testy na uzgodnionych danych, odpowiedzialność za aplikację i API oraz sposób wprowadzania kolejnych zmian. Zakres pracy offline, dodatkowych kanałów i nowych modułów ustalamy odrębnie.
Jak aplikacja współpracuje z zapleczem w JutroDrop
React Native połączony z backendem Laravel
W JutroDrop aplikacja mobilna na iOS i Androida współpracuje z backendem w Laravelu i webowym panelem administracyjnym. API obsługuje komunikację aplikacji z zapleczem, a administratorzy zarządzają treściami produktu. Ten projekt pokazuje połączenie interfejsu mobilnego z systemem danych. Dotyczy własnego zaplecza produktu; integrację z zewnętrznym CRM lub ERP trzeba ocenić na podstawie możliwości danego systemu.
Jaki system chcesz udostępnić swoim klientom na telefonie?
Podaj nazwę systemu, informację o dostępności API i najważniejszą czynność klienta. Opisz, skąd pochodzą dane oraz kto je aktualizuje. Tyle wystarczy, aby rozpocząć rozmowę o integracji.
Pytania o aplikację połączoną z systemem firmy
Przed budową ustalamy rolę telefonu w procesie klienta, źródło danych i możliwości istniejącego zaplecza.
Chcesz omówić mobilny dostęp do swojego systemu? Porozmawiajmy o zakresie.
Portal otwiera się w przeglądarce i może wystarczyć, gdy klient zagląda do niego sporadycznie. Osobną aplikację uzasadnia konkretny scenariusz mobilny, częste użycie lub potrzebne funkcje telefonu. Porównaj ten zakres z ofertą panelu klienta dostępnego w przeglądarce.
Nie zawsze. Najpierw sprawdzamy, czy obecny system udostępnia potrzebne dane i operacje, oraz ustalamy jego rolę w procesie. Jeśli zaplecze wymaga rozbudowy, osobno określamy zakres integracji systemu CRM przez API.
Trzeba ocenić dostępne sposoby wymiany danych i możliwość rozbudowy zaplecza. Czasem potrzebna będzie współpraca z dostawcą systemu albo zmiana wybranego procesu. Nie zakładamy, że każde narzędzie da się połączyć w takim samym zakresie.
Zależy to od architektury logowania i sposobu identyfikowania klienta w systemie. Analiza obejmuje powiązanie kont, sesje i uprawnienia do danych. Dopiero wtedy można określić, czy zachowamy obecne konto i jakie zmiany będą potrzebne.
Aplikacja nie poprawi automatycznie danych źródłowych. W przykładowym procesie pracownik aktualizuje status sprawy w systemie, a aplikacja odczytuje go dla klienta; nowe zgłoszenie trafia do ustalonej obsługi. Projektujemy częstotliwość odczytu oraz komunikat przy błędzie API lub braku aktualnych informacji.
Praca offline jest osobnym wymaganiem, które trzeba uzasadnić scenariuszem użycia. Obejmuje zapis lokalny, synchronizację i rozwiązywanie konfliktów po odzyskaniu połączenia. Zakres odczytu danych bez sieci może być inny niż możliwość wykonywania operacji.
Przydadzą się dokumentacja API, opis procesu klienta, role i informacje o środowisku testowym. W pierwszej rozmowie wystarczy wskazać system i zadanie, które ma być dostępne na telefonie. Jeżeli potrzebujesz także całego nowego produktu, zobacz zakres tworzenia aplikacji mobilnych.
Klienci uwielbiają z nami pracować