Aplikacja mobilna czy panel w telefonie. Ekipa gubi zlecenie w piwnicy, nie w sklepie
Autor:
Paweł Matusiak
·
Panel w biurze działa w przeglądarce, technik ma telefon w kieszeni, a właściciel słyszy, że „trzeba zrobić aplikację”. Aplikacja ze sklepu to osobny kanał instalacji i poprawek, nie kolejny etap panelu. Ma sens, gdy ekipa zamyka zlecenie bez sieci albo potrzebuje sprzętu telefonu, którego przeglądarka nie daje pewnie. W pozostałych przypadkach strona, która mieści się w telefonie, prowadzi ten sam obieg taniej.
Panel w biurze otwiera się w przeglądarce. Technik ma telefon w kieszeni. Właściciel słyszy, że teraz trzeba zrobić aplikację, bo klient ma smartfon, a konkurencja pokazuje ikonę w sklepie.
Ta rozmowa zwykle pomija dzień pracy. Adres zmienia się w południe. Tabliczka silnika jest w ciemnym garażu podziemnym. Podpis ma złożyć administrator, który wyjdzie na pięć minut. Zasięg pada na pochylni. Zlecenie, które miało wrócić do biura wieczorem, wraca w kawałkach: zdjęcie w galerii, kartka w schowku, wiadomość w wątku.
Aplikacja mobilna nie jest kolejnym etapem rozwoju panelu firmowego. Jest osobnym kanałem instalacji, recenzji sklepu i poprawek. Ma uzasadnienie, gdy ekipa musi zamknąć wizytę przy dostępie offline, gdy przeglądarka nie daje pewnie aparatu, lokalizacji albo skanera, albo gdy kanał ze sklepu jest wymuszony. W pozostałych przypadkach responsywna aplikacja webowa — strona, która mieści się w telefonie i da się przypiąć do ekranu — prowadzi ten sam obieg taniej.
Ikona jest kosztem utrzymania. Firma dopłaca do sklepu, gdy karta zlecenia pada razem z siecią i gdy w biurze jest ktoś, kto utrzyma drugi program.
Co ekipa robi telefonem, zanim ktoś mówi o sklepie
W serwisie terenowym telefon nie służy do oglądania oferty. Służy do tego, żeby technik wiedział, dokąd jedzie, co ma zabrać z auta i co ma odhaczyć u klienta.
Rano lista adresów ląduje w komunikatorze. W południe wchodzi awaria i kolejność się sypie. Wieczorem w galerii siedzą zdjęcia tabliczek, w schowku kartka z numerem części, w notatce godziny dojazdu. Biuro rano składa z tego fakturę i protokół, który klient sieciowy chce w swoim wzorze.
Zator jest prosty. Zlecenie żyje w trzech miejscach naraz: w panelu biura, w wątku na telefonie i w głowie kierownika. Gdy adres się zmienia, część osób ma stary. Gdy zdjęcie tabliczki zostaje w prywatnej galerii, magazyn zamawia inną część. Gdy podpis jest na kartce, faktura stoi, aż ktoś tę kartkę odnajdzie.
Tu pomaga wspólna karta zlecenia otwierana na telefonie: adres, status, zdjęcie przypięte do wizyty, nie do czatu. Komunikator zostaje do awarii i do rozmowy, nie do listy adresów. Na tym etapie często wystarcza strona, która dobrze działa w przeglądarce. Aplikacja dla serwisu terenowego opisuje ten obieg od zgłoszenia do raportu z wizyty. Ikona w sklepie nic tu jeszcze nie dodaje.
Kierownik i tak będzie dzwonił, gdy brama zablokuje wjazd na halę. Panel w telefonie nie zastąpi rozmowy. Zastępuje zgadywanie, która wersja adresu jest prawdziwa i które zdjęcie należy do którego obiektu.
Przykład: serwis bram i protokół z garażu podziemnego
Wyobraźmy sobie serwis bram, rolet i napędów z kilkunastoma ekipami. Biuro ma panel: umowy serwisowe na osiedlach i halach, cennik przeglądów, faktury. Ekipy dostają dzień w komunikatorze. Kierownik wkleja adres, godzinę, czasem numer napędu.
Typowa sytuacja wygląda tak. Technik zjeżdża do garażu podziemnego. Zasięg znika na pochylni. Ma wypełnić protokół przeglądu: typ napędu, zdjęcie tabliczki, stan prowadnic, podpis administratora. Strona w przeglądarce kręci się i nie ładuje. Zapisuje na kartce, robi zdjęcia do galerii, wychodzi na parking i wrzuca pliki do wątku. Wieczorem w biurze ktoś zgaduje, które zdjęcie należy do której bramy, bo w jednym bloku są trzy wjazdy.
Skutek jest nudny i drogi. Magazyn zamawia inny siłownik. Ekipa jedzie drugi raz. Administrator twierdzi, że podpisu nie składał. Faktura za przegląd stoi, a umowa z wspólnotą i tak biegnie.
W tej historii pomogą dwie rzeczy. Po pierwsze karta zlecenia, w której zdjęcie i podpis siedzą przy wizycie. Po drugie kolejka offline: protokół zapisany w telefonie i wysłany, gdy wróci sieć. Czy ta kolejka ma żyć w przeglądarce, czy w aplikacji ze sklepu, zależy od tego, jak często garaż obcina zasięg — nie od tego, czy konkurencja ma ikonę.
Ten sam serwis ma jeszcze sezon. Jesienią wspólnoty chcą przeglądów przed zimą, latem sypią się awarie napędów na halach. Wtedy komunikator puchnie, a biuro składa protokoły z opóźnieniem. Im więcej ekip jedzie naraz, tym droższy jest brak jednej karty i jednej kolejki, niezależnie od tego, skąd ikona na ekranie pochodzi.
Offline, aparat i podpis. Gdzie strona w telefonie się wykłada
Przeglądarka w telefonie dobrze znosi listę zleceń, status i zwykły formularz, o ile jest sieć. Próg leży indziej. W garażu, w hali ze ścianami z blachy, w kotłowni, na terenie bez zasięgu karta ma dać się wypełnić i nie zginąć.
Dostęp offline znaczy coś konkretnego. Technik otwiera zlecenie na parkingu, zjeżdża w dół, wypełnia protokół, robi zdjęcie, zbiera podpis i wychodzi. Dopiero na górze telefon dosyła paczkę do biura. Jeśli strona wymaga żywego połączenia przy każdym polu, protokół wraca na kartkę. Wtedy panel w telefonie jest ozdobą, a praca toczy się obok.
Aparat ma oddać tabliczkę do karty, z datą, i nie zostawić jej w galerii. Przeglądarka na telefonie zdjęcie zrobi. Bywa kapryśna przy słabym świetle, przy serii ujęć, przy powrocie do formularza po zrobieniu zdjęcia. Aplikacja ze sklepu zwykle trzyma ten przebieg pewniej, bo korzysta z aparatu jak z narzędzia, a nie jak z dodatku do strony.
Podpis na ekranie zamyka wizytę. Kartka w schowku jej nie zamyka. Skaner kodu na części i drukarka etykiet to już sprzęt, którego strona w przeglądarce często nie utrzyma. Bluetooth, lokalizacja w tle, praca w tle. Tych rzeczy strona nie obiecuje pewnie.
W przykładzie z bramami garaż podziemny obcina sieć, tabliczka napędu wymaga zdjęcia, a podpis administratora zamyka przegląd. Skaner przemysłowy i drukarka w aucie u części ekip nie występują. Do rozstrzygnięcia zostaje kolejka offline i zdjęcie w karcie: czy da się je utrzymać w stronie przypiętej do ekranu, czy trzeba cienkiej aplikacji terenowej, która mówi z tym samym panelem.
Kto wgrywa program na telefon i kto go aktualizuje
Aplikacja ze sklepu ma dystrybucję, której strona nie ma. Ktoś musi ją znaleźć, zainstalować, zalogować się, zgodzić na powiadomienia, potem wgrać poprawkę. W serwisie z kilkunastoma ekipami ta lista nie jest drobiazgiem.
Część ludzi jeździ na telefonie prywatnym. Inna część ma służbowy, który leży w schowku i ma stary system. Kierownik wysyła link do sklepu. Po tygodniu dwoje techników nadal zamyka dzień w komunikatorze, bo „jakaś aplikacja nie chciała się otworzyć”. Biuro ma wtedy dwa obiegi: ten z karty i ten z wątku. To gorsze niż sam komunikator, bo nikt nie wie, który jest obowiązujący.
Aktualizacja jest osobnym kosztem. Zmiana statusu w panelu webowym wchodzi po wgraniu na serwer. Ta sama zmiana w aplikacji ze sklepu czeka na recenzję, na to, aż telefon pobierze paczkę, i na to, aż technik w ogóle ją otworzy. W szczycie jesiennych przeglądów biuro nie chce czekać, aż sklep puści poprawkę pola w protokole. Chce, żeby ekipa rano widziała ten sam status co dyspozytor.
Strona przypięta do ekranu omija recenzję. Ma inną wadę: ktoś musi ten skrót zrobić, zapamiętać hasło, nie wyczyścić danych przeglądarki. Sesja wylogowuje w najgorszym momencie. Link ginie, gdy technik zmienia telefon. To są prawdziwe tarcia. Nadal tarcia jednego programu, nie dwóch sklepów i dwóch recenzji.
Jeżeli firma i tak rozdaje telefony służbowe i ktoś w biurze ogarnia ich listę, sklep przestaje być straszakiem. Wtedy telefon służbowy z jedną wgraną aplikacją jest kanałem, który da się utrzymać. Jeżeli każdy jeździ na swojej komórce, najpierw trzeba powiedzieć, kto odpowiada za instalację. Bez tej osoby natywna aplikacja wraca do komunikatora w ciągu sezonu.
Dwa programy, jeden status i pomylony kanał klienta
Koszt aplikacji ze sklepu rzadko kończy się na pierwszym ekranie. Biuro i tak potrzebuje panelu: umowy, faktury, grafik, magazyn. Ekipa potrzebuje karty w telefonie. To już dwa końce tego samego obiegu. Gdy oba mają osobny kod, każda zmiana statusu, pola w protokole albo cennika przeglądu idzie podwójnie.
Utrzymanie dwóch programów widać przy banalnej zmianie. Wspólnota chce na protokole inny układ podpisów. W panelu webowym to poprawka ekranu. W aplikacji ze sklepu to jeszcze recenzja i telefony, które nie pobrały wersji. Przez dwa tygodnie część ekip wysyła stary wzór, część nowy. Biuro składa dokumenty ręcznie. Wycena aplikacji puchnie nie od pomysłu na ikonę, tylko od tego, ile takich zmian firma zrobi w roku.
Osobny błąd to zmieszanie narzędzia ekipy z kanałem klienta. Właściciel chce jednej aplikacji: administrator zamawia przegląd, technik go zamyka, biuro wystawia fakturę. To są dwa produkty. Zamówienie przeglądu to krótka strona albo konto w portalu. Karta zlecenia z kolejką offline to narzędzie pracy. Sklep, w którym siedzą oba, puchnie od ról, uprawnień i ekranów, których nikt nie używa.
W serwisie z przykładu administrator wspólnoty nie potrzebuje aplikacji ze sklepu, żeby zgłosić, że brama nie domyka się na noc. Potrzebuje telefonu albo krótkiego formularza. Technik potrzebuje karty, która przeżyje garaż. Klient sieci hal może chcieć własny portal, nie ikonę. Gdy te trzy rzeczy spina się w jeden produkt „bo aplikacja”, firma płaci za sklep, którego nikt z nich nie otwiera tak, jak zakładano.
Stąd prosta miara. Ile osób w firmie ma utrzymać drugi kod i dwa sklepy przy każdej zmianie protokołu. Jeśli nikt — sklep jest ozdobą. Jeśli jest zespół i jest próg offline, którego web nie przejdzie, drugi program ma właściciela. Bez właściciela zostaje wątek w komunikatorze, tylko z dodatkowym logowaniem.
Zgubiony link, wylogowana sesja, powiadomienie, które nie dochodzi
Część oporu wobec strony w telefonie nie bierze się z garażu. Bierze się z tego, jak przeglądarka zachowuje się w kieszeni.
Technik dostaje link, otwiera kartę, zamyka przeglądarkę, wraca po dwóch godzinach i jest wylogowany. Albo ma trzy karty z trzema zleceniami i nie wie, która jest żywa. Albo system iPhone’a traktuje stronę jak kolejną zakładkę, a nie jak narzędzie. Ikona na ekranie, którą sam dodał, ginie po zmianie telefonu. W szczycie sezonu takie tarcie wraca do komunikatora, bo wątek po prostu działa.
Powiadomienie o nowym zleceniu albo o zmianie kolejności ma dotrzeć, gdy technik jest w aucie, nie gdy odświeży stronę w biurze. Strona w przeglądarce bywa tu słabsza, zwłaszcza na telefonach, które oszczędzają energię i usypiają karty. Aplikacja ze sklepu ma ten kanał uporządkowany, o ile ktoś w ogóle zgodził się na powiadomienia i ich nie wyciszył.
Da się to złagodzić bez sklepu. Dłuższa sesja. Skrót na ekranie zrobiony na służbowym telefonie, nie „jak ktoś zdąży”. Jedna otwarta karta zlecenia zamiast listy zakładek. Lista dnia, która działa po zaciągnięciu, nawet gdy sieć chwilowo siądzie. To nadal jeden program. Część tarcia znika, gdy telefon jest służbowy i ktoś w biurze ustawia skrót raz, a nie przy każdym nowym pracowniku od zera.
Zostaje jednak reszta: usypianie kart, niepewne powiadomienia, inna przeglądarka u każdego. Jeśli dyspozytor naprawdę przestawia ekipy w ciągu dnia i ta zmiana ma wejść w telefon w kilka minut, kanał push przestaje być ozdobą. Wtedy argument za aplikacją terenową jest organizacyjny, nie marketingowy.
Kontrargument: natywna aplikacja jest po prostu wygodniejsza
Technik szuka ikony, nie adresu strony. Aplikacja natywna jest szybsza, pewniejsza w garażu, lepiej bierze aparat i lokalizację. Właściciel, który widzi ikonę u konkurencji, słyszy, że bez sklepu firma wygląda na spóźnioną. Ten argument ma wagę, gdy karta zlecenia naprawdę pada w przeglądarce.
U części serwisów tak właśnie jest. Ekipa spędza dzień w halach i garażach. Protokół bez zdjęcia i podpisu nie ma wartości. Dyspozytor przestawia kolejność co godzinę. Telefony są służbowe, ktoś je wgrywa, ktoś zbiera, gdy człowiek odchodzi. Strona w przeglądarce zostaje wtedy obejściem: kartka, galeria, wątek. Bez sklepu karta zlecenia nie wraca do biura w jednym kawałku.
Pełna aplikacja ze sklepu na dwa systemy i tak rzadko jest najtańszą drogą. Biuro pracuje w panelu w przeglądarce. Klient zgłasza awarię telefonem albo krótkim formularzem. Cienka aplikacja terenowa — karta, zdjęcie, podpis, kolejka, powiadomienie — mówi z tym samym panelem. Reszta zostaje w przeglądarce. Dwa sklepy, dwa pełne programy i portal klienta w jednym zamówieniu to trzy produkty pod jedną fakturą.
Ograniczenia strony przypiętej do ekranu widać najszybciej na iPhonie: ciaśniejszy dostęp do powiadomień i pamięci, kapryśny skrót po aktualizacji systemu, pamięć offline mniej oczywista niż w aplikacji ze sklepu. Jeśli większość ekipy jeździ na iPhone’ach i kolejka w garażu jest codziennością, skrót na ekranie przestaje wystarczać. Zostaje cienka aplikacja albo zgoda, że w garażu obowiązuje kartka i dosłanie po wyjściu.
Domyślna strona w telefonie nie zastąpi skanera kodów na części, drukarki w aucie, lokalizacji w tle przez cały dzień ani recenzji, której wymaga sieć handlowa od dostawcy. Nie naprawi też firmy, w której nikt nie odpowiada za telefony. Aplikacja ze sklepu stanie wtedy obok komunikatora. Zanim biuro wybierze sklep, musi wskazać, kto wgrywa, kto aktualizuje i która karta jest prawdziwa.
Presja bywa prestiżowa. Właściciel chce ikony, bo konkurencja ją ma. Ekipa i tak zamyka dzień w wątku. Ikona bez kolejki offline i bez wspólnej karty nic nie zmieni w garażu. Firma utrzymuje wtedy trzecie miejsce, w którym zlecenie może zginąć.
Arkusz, strona w telefonie, skrót na ekranie albo cienka aplikacja terenowa
Trzy ekipy i przeglądy wpisywane wieczorem przez jedną osobę — arkusz i komunikator wystarczą, o ile nikt nie prowadzi drugiej listy w telefonie. Prosty protokół i zasięg na obiekcie załatwia strona w przeglądarce. Gotowy program dla serwisu bywa tańszy niż własny kod, gdy wizyta, część i faktura są standardowe. Gotowy program przestaje się spinać, gdy sieć hal chce własny wzór protokołu, a wspólnota — inny cykl przeglądów.
Własny panel ma uzasadnienie, gdy obieg jest nietypowy. Przegląd bramy, awaria napędu i ryczałt od obiektu w jednym dniu. Część w aucie i przy hali. Podpis administratora, którego nie ma na miejscu, i drugi wyjazd tylko po parafkę. Wtedy najpierw jedna karta zlecenia w przeglądarce, potem decyzja, czy kolejka offline wymaga aplikacji ze sklepu.
Kolejność, która zwykle mniej boli:
- Wspólna karta zlecenia w panelu, który dobrze działa na telefonie: adres, status, zdjęcie, podpis.
- Skrót na ekranie służbowego telefonu i sesja, która nie wylogowuje w garażu.
- Kolejka offline w tej samej stronie, jeśli da się ją utrzymać na telefonach ekipy.
- Cienka aplikacja terenowa ze sklepu dopiero wtedy, gdy kolejka, aparat albo powiadomienie regularnie padają.
- Osobny, krótki kanał dla administratora albo klienta sieci — nie ten sam sklep co narzędzie ekipy.
GESOFT w takich zleceniach najpierw rozpisuje obieg: kto zamyka wizytę, co musi przeżyć brak sieci, skąd bierze się zdjęcie tabliczki, jak faktura czeka na podpis. Dopiero z tego widać, czy wystarczy panel w przeglądarce, czy ekipa potrzebuje osobnej karty w telefonie. Czasem wynik jest skromny: jedna karta, skrót na ekranie, integracja z programem księgowym. Czasem kolejka offline nie utrzyma się w stronie i dochodzi cienka aplikacja terenowa, która mówi z tym samym panelem.
Ta rozmowa jest tańsza niż zamówienie „aplikacji do sklepu”, zanim ktoś spisze, co się dzieje na pochylni garażu. Natywna aplikacja opłaca się, gdy karta zlecenia pada bez sieci albo bez pewnego aparatu, i gdy ktoś w firmie utrzyma dystrybucję. Serwis z przykładu potrzebuje protokołu, który wraca z garażu w jednym kawałku.
Najczęściej zadawane pytania
- Czy strona przypięta do ekranu zastępuje aplikację ze sklepu?
- Często przy liście zleceń, statusie i zwykłym formularzu, o ile jest sieć i ktoś ustawi skrót na telefonie. Słabnie, gdy ekipa regularnie wypełnia protokół bez zasięgu, gdy aparat i podpis padają w przeglądarce, albo gdy większość jeździ na iPhone’ach i kolejka offline jest codziennością. Wtedy rozsądniejsza bywa cienka aplikacja terenowa, nie drugi pełny program.
- Czy każdy serwis terenowy potrzebuje aplikacji natywnej?
- Nie. Kilka ekip, prosty protokół i zasięg na obiekcie — wystarczy panel, który działa na telefonie, albo gotowy program. Aplikacja ze sklepu ma uzasadnienie, gdy garaż, hala albo teren obcina sieć, a zdjęcie i podpis muszą wrócić do tej samej karty, oraz gdy ktoś w firmie utrzyma instalację i aktualizacje.
- Czy klient i ekipa mogą korzystać z tej samej aplikacji?
- Zwykle to dwa produkty. Administrator wspólnoty potrzebuje zgłoszenia albo krótkiego formularza. Technik potrzebuje karty, która przeżyje brak sieci. Sklep, w którym siedzą oba, puchnie od ról i ekranów. Taniej jest dać klientowi stronę albo portal, a ekipie narzędzie pracy mówiące z tym samym panelem.
Powiązana usługa:
Dedykowane oprogramowanie dla firm
Opisz projekt