Wstęp
Ludzie korzystają z aplikacji bankowości mobilnej codziennie, czasami godzinami. Korzystają ze swoich kont bankowych, płacą rachunki, przelewają pieniądze między kontami i robią zakupy. Aby zbudować zaufanie klientów do swojego produktu, musisz zapewnić im solidne doświadczenie użytkownika od samego początku. Historia transakcji jest jednym z najważniejszych elementów budowania tego zaufania; może ona wpłynąć na decyzję klienta o pozostawieniu lub zamknięciu konta u Ciebie.
Kiedy użytkownicy logują się do swojej aplikacji bankowej, zazwyczaj mają natychmiastowe pytania dotyczące swoich kont, takie jak:
- Czy moja wypłata została wpłacona?
- Dlaczego mam debet na koncie lub mam mniej pieniędzy, niż myślałem?
- Czy pieniądze za tę ostatnią transakcję zostaną pobrane z mojego konta?
- Czy mogę otrzymać kopię rachunku z restauracji, którą odwiedziłem trzy miesiące temu?
- Jak mogę zakwestionować opłatę na moim koncie, której nie rozpoznaję?
Jeśli zaprojektujesz doskonałą historię transakcji, więcej osób będzie korzystać z Twojego produktu bez konieczności kontaktowania się z obsługą klienta; jeśli nie zaprojektujesz doskonałej historii transakcji, spowodujesz zamieszanie, niepotrzebne połączenia/zgłoszenia do obsługi klienta i stres u swoich klientów.
Dla firm założycielskich, menedżerów produktów lub instytucji finansowych planujących rozwój mobilnej aplikacji bankowej, historia transakcji to nie tylko zwykły ekran; to integralna część doświadczenia użytkownika. Wpływa ona na UX, jakość danych, wydajność, standardy zgodności i obsługę klienta (które wszystkie są ze sobą powiązane).
W Appricotsoft naszym celem jest tworzenie oprogramowania, które jest proste i funkcjonalne, z którego zespół jest dumny. Historia transakcji również wpisuje się w ten schemat i musi być zaprojektowana tak, aby była technicznie dokładna, ale jednocześnie łatwa w dostępie i obsłudze dla użytkownika w świecie rzeczywistym.
Znaczenie historii transakcji
Historia transakcji to obszar, w którym użytkownik może zobaczyć rzeczywiste wyniki swojej aktywności finansowej (wszystkie dokonane płatności, otrzymane przelewy, otrzymane zwroty, przetworzone płatności abonamentowe, pobrane pieniądze z bankomatu (lub karty debetowej) oraz nieudane płatności, które nie zostały rozliczone). Są to przykłady transakcji, które staną się częścią repozytorium pamięci finansowej użytkownika.
Możliwość udostępnienia użytkownikowi przejrzystej historii transakcji będzie dla niego pomocna na wiele sposobów, w tym:
- Aby dokładnie zobaczyć, gdzie podziały się ich pieniądze w danym okresie czasu.
- Aby szybko identyfikować wszelkie oszukańcze działania na ich kontach.
- Aby śledzić swoje wydatki i nawyki budżetowe.
- Aby wygenerować raport, będą musieli przygotować zeznania podatkowe na potrzeby zwrotu podatku.
- Aby pobrać paragony jako dowód zapłaty.
- Możliwość wszczęcia sporu lub zgłoszenia problemu do obsługi klienta bez konieczności opuszczania aplikacji bankowości mobilnej.
Aplikacja bankowa lub FinTech również odczuje spadek poziomu obsługi klienta dzięki przejrzystej historii transakcji w aplikacji mobilnej. Jeśli użytkownicy będą mogli wyszukiwać, filtrować, eksportować i sprawdzać status swoich transakcji w produkcie, liczba zapytań będzie mniejsza.
Dlatego tak ważne jest, aby historia transakcji była dostarczana na wczesnym etapie strategii produktu i nie należy traktować jej jako ostatniej rzeczy, którą należy zrobić w ramach zaległych projektów.
Oceniając potencjalnych partnerów do rozwoju aplikacji bankowości mobilnej, należy upewnić się, że rozumieją oni zarówno doświadczenie użytkownika, jak i złożoność systemów zaplecza obsługujących przetwarzanie informacji o transakcjach. Udostępnienie interfejsu użytkownika prezentującego informacje o transakcjach w formie listy znacznie różni się od udostępnienia użytkownikowi historii transakcji.
Zacznij od jasno skategoryzowanych transakcji
Po skategoryzowaniu transakcji historia transakcji użytkownika zmienia się z surowych danych źródłowych w sformatowany i zrozumiały szereg transakcji.
Bez kategorii użytkownicy widzą długą listę sprzedawców, przelewów pieniężnych, transakcji kartami i nazw sprzedawców, nie mając pojęcia, co one oznaczają. Dzięki kategoriom użytkownik może łatwo sprawdzić, ile pieniędzy wydał na artykuły spożywcze, transport, rachunki za media, restauracje, prenumeraty, dochody, oszczędności i opłaty.
Ważne jest wdrożenie dobrych procesów kategoryzacji, które umożliwią:
- Kategorie domyślne oparte na sprzedawcy, metodzie płatności lub informacjach o transakcji.
- Użytkownik ma możliwość ręcznej zmiany kategorii transakcji.
- Użytkownicy mają możliwość tworzenia niestandardowych kategorii, gdyż niektórzy będą potrzebować unikalnej kategoryzacji.
- Użycie tej samej ikony/obrazów dla typów kategorii.
- Stosowanie tych samych nazw dla kategorii typów transakcji.
- W przypadku powtarzających się zakupów/subskrypcji obsługa jest podobna, a użytkownik może zdefiniować opcje dotyczące częstotliwości i kwoty.
- Wyraźne rozróżnienie między wydatkami osobistymi, przelewami pieniężnymi, opłatami, zwrotami i dochodami.
Na przykład transakcja kartą w sklepie spożywczym nie powinna być wyświetlana z nazwą operatora płatności. Użytkownik chciałby zobaczyć nazwę sklepu spożywczego, datę transakcji, całkowitą kwotę transakcji, kategorię transakcji oraz status transakcji (zakończona).
Kategoryzacja transakcji ułatwi korzystanie z dodatkowych funkcji, takich jak budżetowanie, analiza wydatków, alerty i spersonalizowany wgląd w finanse poszczególnych użytkowników. Nawet jeśli Twój Minimalny Produkt Funkcjonalny (MVP) nie obejmuje zaawansowanego zarządzania pieniędzmi, niezwykle ważne jest, aby opracować kategorie w sposób, który umożliwi dodawanie funkcji do produktu w przyszłości.
W tworzeniu niestandardowych aplikacji mobilnych jest to kluczowy obszar, w którym wstępne przemyślenie produktu staje się kluczowe dla sukcesu aplikacji. Naszym celem nie jest jedynie dostarczenie narzędzia do prezentacji danych; chcemy również od samego początku zbudować fundament, który w przyszłości pozwoli na skalowanie i dostarczanie analiz finansowych.
Dzięki funkcjom wyszukiwania i filtrowania użytkownicy mogą łatwo znaleźć informacje o swoich transakcjach
Gdy użytkownicy nie mogą znaleźć tego, czego szukają, mogą czuć frustrację z powodu listy transakcji. Dlatego projektowanie funkcji wyszukiwania i filtrowania musi opierać się na rzeczywistych pytaniach zadawanych przez użytkowników, a nie tylko na polach bazy danych.
Przykłady przydatnych opcji wyszukiwania obejmują:
- Nazwa sprzedawcy
- Kwota transakcji
- Kategoria transakcji
- Zakres dat transakcji
- Numer karty kredytowej lub konta transakcyjnego
- Typ transakcji
- Status transakcji (oczekująca, zaksięgowana, nieudana, cofnięta lub zwrócona)
- Metoda płatności transakcji
- Unikalny numer referencyjny lub notatka powiązana z transakcją
Filtry mogą być uciążliwe w użyciu na urządzeniach mobilnych, dlatego należy je zaprojektować tak, aby użytkownik nie musiał klikać przez pięć różnych opcji, aby znaleźć restaurację zakupioną w zeszłym miesiącu.
Przykład efektywnego przepływu może wyglądać następująco:
- Użytkownik uzyskuje dostęp do historii transakcji za pośrednictwem witryny/aplikacji bankowości internetowej.
- Użytkownik wyszukuje Ubera lub stosuje filtr transportu.
- Użytkownik wybiera zakres dat transakcji (ostatnie 90 dni).
- Użytkownik klika transakcję, aby wyświetlić szczegóły, potwierdzenie i opcje pomocy.
Dla firm i użytkowników usług bankowości premium wyszukiwanie i filtrowanie stają się o wiele ważniejsze. Użytkownicy będą chcieli oddzielić transakcje osobiste od transakcji biznesowych, zakupy dokonane kartami kredytowymi od płatności przelewami bankowymi oraz transakcje krajowe od międzynarodowych.
Wreszcie, wyszukiwanie powinno uwzględniać błędy ortograficzne lub nieprecyzyjne dane wprowadzane przez użytkownika. Na przykład użytkownik może wyszukać McDonald's zamiast McDonald's lub szukać subskrypcji, nie znając nazwy firmy powiązanej z subskrypcją. Zmniejszając tarcie poprzez pozytywne doświadczenia użytkownika i rozumiejąc, że użytkownicy mogą popełniać błędy, użytkownicy będą mogli łatwo znaleźć historię swoich transakcji.
Transakcje oczekujące a transakcje zaksięgowane – jak wyjaśnić status
Jednym z głównych źródeł nieporozumień w przypadku aplikacji bankowości mobilnej (MBA) jest różnica między transakcjami oczekującymi i zaksięgowanymi.
Transakcje oczekujące: Transakcja oczekująca to transakcja autoryzowana, która nie została jeszcze rozliczona. Transakcje zaksięgowane: Transakcja zaksięgowana (zwana również “transakcją sfinalizowaną”) to transakcja, która została rozliczona i zarejestrowana na Twoim koncie. Różnica ta wpływa na dostępność środków na Twoim koncie, ostateczną kwotę transakcji, sprzedawcę, który ją przetworzył, oraz ewentualne opóźnienia w możliwości otrzymania zwrotu.
Przeciętny użytkownik nie potrzebuje za każdym razem wyjaśnień technicznych, ale potrzebuje jasności, gdy sprawdza status swoich transakcji (oczekujących lub zaksięgowanych).
Dobra historia transakcji powinna:
- Oczekujące transakcje należy wyraźnie oznaczyć jako ‘Oczekujące’.’
- Wyjaśnij, że kwota oczekującej transakcji może ulec zmianie przed jej zaksięgowaniem
- Podaj informacje o tym, kiedy oczekuje się zaksięgowania oczekującej transakcji (jeśli ma to zastosowanie)
- Oddzielaj oczekujące i zaksięgowane transakcje, aby zmniejszyć zamieszanie
- Pokaż wstrzymania autoryzacyjne jako coś innego niż zwykłe zakupy
- Płynna aktualizacja transakcji w celu odzwierciedlenia zmiany statusu ze statusu oczekującego na status zaksięgowany.
Na przykład, jeśli użytkownik uda się do hotelu, na stację benzynową, do wypożyczalni samochodów lub restauracji i na jego karcie kredytowej zostanie nałożona blokada na poczet przyszłego zakupu, a MBA nie wyjaśni, dlaczego blokada została nałożona, użytkownik odniesie wrażenie, że został obciążony nieprawidłowo lub obciążony za dużą kwotą.
Prosty tekst pomocy zapobiegnie wysyłaniu zgłoszeń do pomocy technicznej:
“Oczekująca – Ta kwota jest rezerwowana, ale nie została jeszcze sfinalizowana. Ostateczna kwota może ulec zmianie”.”
To stwierdzenie jest niezwykle ważne dla każdej firmy rozwijającej program MBA, ponieważ jasna komunikacja między bankiem a użytkownikiem buduje zaufanie w zastraszającym tempie. Użytkownicy, widząc, jak ich pieniądze znikają bez wyjaśnienia, bardzo szybko się denerwują.
Szczegóły transakcji: Pokaż wystarczająco dużo, nie za dużo
Strona Szczegóły transakcji to główne źródło, na którym użytkownicy mogą znaleźć informacje dotyczące swoich transakcji i działań, jakie mogą podjąć.
Ta strona może zawierać:
- Nazwa sprzedawcy.
- Kwota transakcji w dolarach.
- Data i godzina transakcji.
- Aktualny status transakcji.
- Rodzaj kategorii przypisanej do transakcji.
- Rodzaj konta (rachunek bieżący/oszczędnościowy, karta debetowa/kredytowa), za pośrednictwem którego została zrealizowana transakcja.
- Lokalizacja sprzedawcy (jeśli sprzedawca dysponuje tą informacją).
- Sposób zapłaty za transakcję (np. za pomocą karty kredytowej).
- Kurs wymiany (jeśli ma zastosowanie w transakcjach międzynarodowych).
- Opłaty związane z transakcją.
- Załącznik z potwierdzeniem transakcji.
- Numer referencyjny.
- Dostępne opcje wsparcia lub możliwości zakwestionowania transakcji.
Najważniejsze informacje powinny być wyświetlane jako pierwsze: kwota w dolarach, nazwa sprzedawcy, data i godzina oraz aktualny status transakcji. Dodatkowe szczegóły dotyczące aspektów technicznych transakcji znajdują się niżej na ekranie.
Ze względów bezpieczeństwa należy unikać wyświetlania zbędnych identyfikatorów wewnętrznych. Tylko identyfikatory wewnętrzne niezbędne lub pomocne w przypadku zgłoszenia problemu powinny być wyświetlane w formacie umożliwiającym kopiowanie i wklejanie, aby użytkownicy mogli je łatwo skopiować i wkleić.
Strona Szczegóły transakcji może również zawierać działania, które można wykonać w kontekście:
- Pobierz paragon
- Dodaj notatkę
- Zmień kategorię
- Podziel transakcję
- Zgłoś problem
- Powtórz transfer
- Skontaktuj się z pomocą techniczną
Dzięki tej funkcjonalności Historia transakcji może być wykorzystywana jako narzędzie wspomagające użytkownika w samodzielnym wykonywaniu czynności obsługowych.
Przenośne dane finansowe
Użytkownicy czasami muszą uzyskać dostęp do historii transakcji poza aplikacją. Dane mogą być potrzebne do różnych celów, takich jak:
- Deklaracje podatkowe
- Księgowość
- Wnioski o kredyt hipoteczny
- Zwrot kosztów
- Dokumenty prawne
- Budżetowanie osobiste
Opcje eksportowe powinny być łatwe do znalezienia i odpowiednio zabezpieczone przed nieautoryzowanym dostępem.
Oto najpopularniejsze formaty eksportu danych finansowych:
- Oświadczenia PDF
- Pliki CSV
- Pliki zgodne z programem Excel
- Formaty OFX/QIF (dla oprogramowania księgowego) w oparciu o rynek
Aby stworzyć dla użytkowników efektywne rozwiązanie eksportowe, muszą oni mieć następujące opcje:
- Konto
- Zakres dat
- Format pliku
- Typ transakcji
- Kategoria (jeśli dotyczy)
Bezpieczeństwo jest istotne podczas eksportowania danych finansowych. Zapewnienie bezpieczeństwa tego procesu często wymaga ponownego uwierzytelnienia, zwłaszcza gdy eksportowane dane zawierają poufne informacje. Wytyczne NIST dotyczące tożsamości cyfrowej (Digital Identity Guidance) zawierają wytyczne dotyczące prawidłowego uwierzytelniania i zarządzania sesjami w odniesieniu do produktów finansowych.
Z punktu widzenia doświadczenia użytkownika należy zadbać o to, aby mógł on łatwo przewidzieć wynik swojego żądania eksportu, identyfikując typ otrzymanego pliku, ramy czasowe, w jakich się on znajduje, a także miejsce, w którym zostanie dostarczony lub zapisany po zakończeniu eksportu.
Upewnij się, że używasz opisowych etykiet plików, takich jak “Eksportuj transakcje jako plik CSV” lub “Pobierz wyciąg PDF”, zamiast stosować niejednoznaczny język, taki jak “Pobierz dane”.
Dokumenty rejestrowe: łącz ludzi i zakupy
Paragony są ważnym narzędziem umożliwiającym śledzenie zachowań zakupowych.
W przypadku osób fizycznych mogą one zapewnić użytkownikowi szczegółową dokumentację zakupów, wszelkich zwrotów lub wymian dokonanych w związku z tymi zakupami, dokumentację gwarancyjną oraz dokumenty zwrotu kosztów. Pomagają również właścicielom firm utrzymać porządek, zapewniając cyfrowy rejestr danych transakcyjnych, który ułatwi i przyspieszy efektywne zarządzanie firmą.
Aplikacja zapewniająca użytkownikom miejsce do przechowywania paragonów powinna zawierać następujące funkcje:
- Funkcja przesyłania zdjęć
- Funkcja przesyłania plików PDF
- Opcja e-mail umożliwiająca wysyłanie paragonów bezpośrednio do aplikacji
- Bezpośrednia integracja z wewnętrzną bazą danych paragonów sprzedawcy
- Proces ekstrakcji danych z optycznego rozpoznawania znaków (OCR)
- Proces dopasowywania paragonów
- Możliwość notatek paragonowych
Aby zmaksymalizować komfort użytkownika, proces dodawania paragonów za transakcje powinien być intuicyjny:
a. Użytkownik uzyskuje dostęp do transakcji i wybiera opcję “Dodaj paragon”.”
b. Użytkownik przesyła zeskanowaną kopię paragonu lub robi zdjęcie paragonu za pomocą aparatu w urządzeniu
c. Paragon zostanie dołączony do transakcji, a aplikacja potwierdzi przesłanie paragonu
Aby zapewnić użytkownikom długoterminową wartość, wszystkie paragony powinny być przechowywane w postaci rekordów z możliwością wyszukiwania i eksportu. Na przykład, użytkownicy mogą chcieć wygenerować raport ze wszystkich transakcji związanych z podróżami w danym miesiącu.
Programiści muszą podejmować przemyślane decyzje dotyczące przechowywania, procedur przechowywania plików, ich bezpieczeństwa, zarządzania uprawnieniami dostępu do plików oraz zasad retencji plików przed opracowaniem aplikacji, aby użytkownicy mogli bezpiecznie przechowywać informacje (takie jak dane osobowe lub firmowe) i uzyskiwać do nich dostęp w razie potrzeby. Ponadto programiści muszą traktować szyfrowanie jako istotny element procesu projektowania aplikacji.
Współpraca z wykwalifikowaną firmą zajmującą się tworzeniem oprogramowania FinTech lub tworzeniem aplikacji mobilnych pomoże uniknąć przeróbek związanych z rozwojem funkcjonalności paragonów.
Przejrzyste i spokojne zgłaszanie problemów – przepływy sporów
Kiedy użytkownik zauważy transakcję na swoim koncie, może poczuć się zaniepokojony i zdezorientowany, co może jeszcze bardziej utrudnić proces zgłaszania sporu.
Prosty i skuteczny proces rozstrzygania sporów rozpocznie się na ekranie szczegółów transakcji, dzięki czemu użytkownik nie będzie musiał przeszukiwać centrum pomocy w celu zgłoszenia sporu.
Najczęstsze przyczyny sporów to:
- Ta transakcja jest mi nieznana
- Zostałem obciążony dwukrotnie
- Pobrana kwota jest nieprawidłowa
- Nie otrzymałem produktu lub usługi, za którą zapłaciłem
- Anulowałem swoją subskrypcję
- Otrzymałem zwrot pieniędzy, ale nie widzę go na swoim koncie
- Zgubiłem kartę lub została mi skradziona
Użytkownik powinien mieć dostęp do szczegółowego opisu procesu zgłaszania sporu:
- Potwierdź spór
- Wybierz typ problemu
- Odpowiedz na istotne pytania dotyczące sporu
- Dołącz wszelką dokumentację pomocniczą (jeśli jest to konieczne)
- Prześlij recenzję
- Otrzymaj numer sprawy i określ dalsze kroki
Biuro Ochrony Konsumentów ds. Usług Finansowych stwierdza, że proces rozstrzygania sporów finansowych zazwyczaj przebiega w sposób uporządkowany, począwszy od otrzymania przez Spółkę skargi konsumenta, udzielenia przez Spółkę odpowiedzi na tę skargę, a następnie zapoznania się z tą odpowiedzią przez konsumenta.
Dla użytkowników najważniejsze jest zaufanie do procesu rozstrzygania sporów, dlatego też użytkownicy muszą wiedzieć:
- Czy mój spór został zgłoszony?
- Co będzie dalej?
- Ile czasu to zajmie?
- Czy będę otrzymywać aktualizacje?
- Czy moja karta jest bezpieczna?
- Czy mogę zablokować swoją kartę?
W przypadku banków i firm fintech przepływy sporów muszą być również powiązane z operacyjnymi przepływami pracy: zespołami wsparcia, zgodnością z przepisami, analizą oszustw, systemami obciążeń zwrotnych, powiadomieniami, dziennikami audytów i komunikacją z klientami.
Dobre doświadczenie w rozstrzyganiu sporów może zmienić stresującą sytuację w moment budowania zaufania.
Wskazówki dotyczące wydajności długich historii transakcji
Historia transakcji może się szybko sumować.
Wielu użytkowników dokonuje tysięcy transakcji na wielu kontach, kartach, w różnych latach, walutach i u różnych sprzedawców. Gdy aplikacja ładuje się zbyt długo, zawiesza się lub nie wyszukuje, użytkownicy całkowicie rezygnują z jej używania.
Wydajność powinna być częścią architektury, a nie dodawana później w formie poprawki.
Oto kilka przydatnych sposobów na poprawę wydajności:
1. Zachowaj ostrożność przy dzieleniu stron na strony lub korzystaj z nieskończonego ładowania.
Zamiast ładować historię transakcji ze wszystkich lat naraz, najpierw załaduj najnowsze transakcje, a następnie, w razie potrzeby, ładuj starsze transakcje.
2. Buforuj ostatnie transakcje.
Większość użytkowników częściej analizuje swoją ostatnią aktywność i transakcje niż stare transakcje. Buforowanie ostatnich transakcji znacznie zwiększy odczuwalną przez użytkownika szybkość działania aplikacji.
3. Oddzielenie danych listy transakcji od danych szczegółowych transakcji.
Lista transakcji wymaga jedynie podsumowania informacji o transakcji. Ładowanie większej ilości danych (szczegółowych informacji, paragonów, metadanych używanych do reklamacji) najlepiej wykonać po otwarciu konkretnej transakcji przez użytkownika.
4. Zoptymalizuj indeksy wyszukiwania.
Funkcja wyszukiwania w aplikacji nie powinna sprawiać trudności w znalezieniu tego, czego szukasz. Indeksowanie w zapleczu aplikacji może znacznie skrócić czas wyszukiwania według nazwy sprzedawcy, daty, kategorii, kwoty i/lub numeru referencyjnego.
5. Używaj jasnych stanów ładowania.
Użycie szkieletowych ekranów, wskaźników postępu i pustych stanów pozwoli użytkownikowi zorientować się, co dzieje się podczas ładowania danych.
6. Radź sobie z brakiem połączenia z siecią i słabą jakością połączenia.
Aplikacja bankowa powinna płynnie przechodzić w tryb awaryjny. Użytkownicy powinni nadal móc przeglądać ostatnio zapisane w pamięci podręcznej transakcje, otrzymując jednocześnie wyraźne informacje o braku połączenia (lub załadowania) danych z powodu braku połączenia sieciowego.
7. Unikaj błędów interfejsu użytkownika
Długie listy na urządzeniach mobilnych wymagają wydajnego renderowania. Użyj technik wirtualizacji, aby aplikacja nie renderowała tysięcy wierszy jednocześnie.
8. Monitoruj rzeczywistą wydajność
Śledź czas ładowania, czas reakcji wyszukiwarki, wskaźniki błędów, opóźnienia API i raporty o awariach. Wydajność powinna być mierzona na bieżąco, a nie na podstawie przewidywań.
Dla Firma zajmująca się tworzeniem aplikacji React Native lub międzyplatformowe firma zajmująca się tworzeniem aplikacji, Historia transakcji to dobry test jakości inżynieryjnej. Lista może wyglądać prosto w prototypie, ale wydajność produkcji zależy od architektury, interfejsów API zaplecza, buforowania, zarządzania stanem i kontroli jakości.
Zagadnienia bezpieczeństwa i prywatności
Historia transakcji zawiera poufne informacje o zachowaniach finansowych. Oznacza to, że funkcja ta musi być zaprojektowana z uwzględnieniem silnych zasad bezpieczeństwa i prywatności.
Ważne elementy sterujące obejmują:
- Uwierzytelnianie i ponowne uwierzytelnianie w przypadku działań poufnych.
- Bezpieczne przechowywanie buforowanych danych transakcji.
- Szyfrowanie w ruchu i w stanie spoczynku.
- Dostęp oparty na rolach dla zespołów administracyjnych i wsparcia.
- Rejestry audytów służące do obsługi sporów i dostępu do danych.
- Staranne obchodzenie się z eksportem i odbiorem.
- Minimalizacja danych w analityce.
- Wyraźna zgoda na opcjonalne funkcje, takie jak skanowanie paragonów czy personalizacja.
UX powinien również zapewnić użytkownikom poczucie bezpieczeństwa. Na przykład, podczas eksportowania wyciągu, aplikacja może wymagać potwierdzenia biometrycznego lub ponownego wprowadzenia kodu dostępu. Podczas dołączania paragonów, aplikacja może wyjaśnić, jak plik jest przechowywany.
Bezpieczeństwo nie powinno być postrzegane jako przypadkowe tarcie. Powinno pojawiać się w momentach, gdy użytkownicy zdają sobie sprawę z ryzyka.
Testowanie aplikacji bankowych i zapewnienie jakości bezpieczeństwa
Aby skutecznie ocenić funkcjonalność historii transakcji po uruchomieniu.
Do wskaźników produktu/operacyjnych zalicza się:
- Czas ładowania ekranu historii transakcji
- Procent wyszukiwań wykonanych za pomocą funkcji wyszukiwania
- Procent użytych filtrów
- Liczba wykonanych wyszukiwań, które zwróciły zero wyników
- Procent eksportowanych historii transakcji
- Liczba paragonów dołączonych do historii transakcji
- Liczba rozpoczętych sporów
- Liczba zakończonych sporów
- Liczba zgłoszeń pomocy technicznej dotyczących niejasności dotyczących transakcji
- Procent błędów podczas korzystania z interfejsów API transakcji
- Procent uszkodzonych wyświetlaczy podczas przeglądania historii transakcji
- Satysfakcja klienta po zgłoszeniu sporu
Monitorowanie tych wskaźników pozwoli Twoim zespołom udoskonalić funkcję po jej uruchomieniu. Na przykład, jeśli większość użytkowników wyszukuje sprzedawcę i nie otrzymuje żadnych wyników, oznacza to, że konieczne jest opracowanie jakiejś formy normalizacji dla sprzedawców. Jeśli kilka osób rozpoczyna spór, ale rezygnuje w połowie, może to oznaczać, że strona sporu jest zbyt skomplikowana.
Tutaj również idealnie wpisuje się Unison Framework firmy Appricotsoft. Unison to framework dostarczania rozwiązań opartych na sztucznej inteligencji, który zapewnia przewidywalne i transparentne rezultaty dzięki cotygodniowym demonstracjom, pojedynczemu źródłu rzetelnych informacji, jasnym kryteriom akceptacji, zarządzaniu ryzykiem, kontroli jakości (QA) i gotowości do wydania w ramach przepływu pracy.
Jeśli chodzi o historię transakcji, Unison umożliwia nam również wczesne dostosowywanie działań użytkowników, definiowanie kryteriów akceptacji i weryfikowanie przypadków skrajnych, a jednocześnie zapewnianie użytkownikom końcowym demonstracji działających projektów na żywo, zanim konieczne staną się kosztowne przeróbki spowodowane drobnymi nieporozumieniami.
Błędy, których należy unikać już dziś
Historia transakcji może faktycznie wprowadzić w zakłopotanie nawet najlepiej radzące sobie zespoły (być może da się ją utworzyć na podstawie poprzednich kontaktów służbowych, które zakończyły się niepowodzeniem).
Poniżej przedstawiamy zarys potencjalnych błędów, jakie mogą pojawić się w historii transakcji:
- Wyświetlanie historii transakcji jako zwykłej listy transakcji
- Brak rozróżnienia między transakcjami płatnymi i niezapłaconymi
- Nieużywanie łatwych do zidentyfikowania nazw transakcji
- Tworzenie zbyt płaskiego filtra
- Nie mając świadomości, że będziesz musiał eksportować
- Nie biorąc pod uwagę bezpiecznego przechowywania przesłanych paragonów
- Utworzenie ogólnego obszaru zasobów wsparcia, a nie ustrukturyzowanej metody radzenia sobie ze sporami i/lub innymi problemami
- Nie nadążanie za wynikami żadnego długiego okresu historycznego
- Brak dostępnych i czytelnych szablonów mobilnych
- Śledzenie analiz pod warunkiem, że nie naruszasz prywatności nikogo.
Dobre doświadczenia z historią transakcji są spokojne, dlatego przejrzystość jest kluczem do tego, aby każdy użytkownik mógł łatwo i szybko znaleźć lub uzyskać odpowiedzi na pytania z pewnością!
Często zadawane pytania
Jakie typy historii transakcji udostępniają aplikacje bankowe i czym różnią się one od historii udostępnianych przez aplikacje niebankowe?
Transakcje w aplikacji bankowej mogą mieć kluczowe znaczenie dla zaufania użytkowników do banku. Historia transakcji umożliwia użytkownikowi sprawdzenie salda, ustalenie, czy wystąpiła nieautoryzowana (oszukańcza) transakcja, udowodnienie dokonania płatności oraz zarządzanie sporami. Dokładność, przejrzystość, bezpieczeństwo i wydajność są ważniejsze w aplikacji bankowej niż w przypadku standardowego źródła aktywności.
Czy transakcje oczekujące i zaksięgowane będą prezentowane w tym samym widoku?
Transakcje oczekujące i zaksięgowane mogą być prezentowane razem, ale ważne jest, aby transakcje oczekujące były odpowiednio oznaczone jako oczekujące. Aplikacja powinna również wyjaśniać, że kwota oczekująca może ulec zmianie i że użytkownik nie powinien zakładać, że opłata oczekująca jest opłatą ostateczną, dopóki transakcja nie zostanie zaksięgowana.
Czy użytkownicy muszą mieć możliwość eksportowania transakcji z aplikacji bankowości mobilnej?
Tak. Wielu użytkowników musi eksportować transakcje na potrzeby księgowości, podatków, zwrotów kosztów, wniosków kredytowych i budżetowania osobistego. Chociaż eksportowanie transakcji może nie być najczęstszym powodem korzystania z aplikacji bankowości mobilnej, to gdy użytkownik tego potrzebuje, staje się to niezwykle istotne.
Czy możliwość przechwytywania paragonów powinna być uwzględniona w MVP aplikacji bankowej?
To zależy od grupy docelowej. Dla użytkowników bankowości detalicznej możliwość rejestrowania paragonów może nie być funkcją, którą trzeba dodać dopiero po wdrożeniu MVP. Dla użytkowników bankowości biznesowej, zarządzania wydatkami, freelancerów i zaawansowanych produktów fintech, stworzenie możliwości rejestrowania paragonów w ramach MVP może być niezwykle cenne.
Co mogą zrobić banki, aby zmniejszyć liczbę zgłoszeń do obsługi klienta dotyczących transakcji?
Podanie czytelnych nazw i kategorii sprzedawców, etykiet oczekujących, szczegółów transakcji, historii z możliwością przeszukiwania oraz instrukcji ułatwiających składanie reklamacji w związku z transakcjami może zmniejszyć liczbę zgłoszeń do pomocy technicznej dotyczących transakcji.
Podejście firmy Appricotsoft do usprawnienia historii transakcji w aplikacjach bankowości mobilnej.
W Appricotsoft podchodzimy do historii transakcji bardziej z perspektywy doświadczenia niż kwestii technicznych, ponieważ odnosi się ona do naszych użytkowników końcowych.
Aby to osiągnąć, zaczynamy od lepszego zrozumienia funkcjonowania wszystkich firm, w tym ich modelu biznesowego, użytkowników, kont i procesów przetwarzania płatności, a także wszelkich wymagań dotyczących integracji, zgodności i wsparcia. Następnie, opierając doświadczenie użytkownika na rzeczywistych pytaniach użytkowników, będziemy budować relację z transakcji.
Oto, w jaki sposób zazwyczaj dodajemy wartość:
1. Mapowanie ścieżki użytkownika
Określimy, co użytkownik musi zrobić, uzyskując dostęp do historii transakcji, w tym: wyświetlić/sortować/przejrzeć ostatnie wydatki, wyszukać starsze transakcje, utworzyć i/lub pobrać dowód zakupu, załączyć paragony, zgłosić podejrzaną aktywność i wyeksportować dane transakcji.
2. Utwórz kryteria akceptacji
Zanim rozpoczniemy faktyczne tworzenie aplikacji, tworzymy formalny dokument kryteriów akceptacji oparty na takich kwestiach jak: stany transakcji, typy filtrów transakcji, puste stany transakcji, sposób ładowania danych, eksportowanie danych transakcji do innych formatów, dołączanie potwierdzeń i kwestionowanie transakcji.
3. Projektowanie z myślą o zaufaniu
Zaufanie buduje się poprzez przejrzystość, dlatego zapewniamy czytelne etykiety, intuicyjne zegary statusu (czyli jaki jest status transakcji), uspokajające komunikaty o błędach i jasne kroki, jakie należy podjąć w przypadku wystąpienia błędów.
4. Rozwój zorientowany na wydajność
Struktura bazy danych dotycząca problemów z przechowywaniem historii transakcji na urządzeniu mobilnym znacznie różni się od tej na innych platformach (np. komputerach stacjonarnych). Na przykład, długie historie transakcji wymagają bardziej odpornego projektu API, pamięci podręcznej, stronicowania i struktury renderowania mobilnego, aby zapewnić lepsze wrażenia użytkownika w aplikacji mobilnej.
5. Walidacja przed uruchomieniem
Zapewnienie jakości (QA) i testowanie to dwa kluczowe elementy każdego pomyślnie opracowanego procesu transakcji finansowych. Przed uruchomieniem weryfikujemy i testujemy wiele “granicznych” scenariuszy transakcyjnych, z którymi klienci mogą się spotkać po zakończeniu transakcji – na przykład zwroty pieniędzy, żądania cofnięcia transakcji, odrzucenia transakcji z powodu niewystarczających środków, duplikaty transakcji i bardzo obszerne historie transakcji.
6. Ciągłe doskonalenie doświadczenia.
Dzięki analizom, wnioskom ze wsparcia i cotygodniowej widoczności dostaw zespoły mogą stale udoskonalać tę funkcję w oparciu o rzeczywiste zachowania użytkowników.
Wartości Appricotsoft – uczciwość, odpowiedzialność, jakość, poczucie odpowiedzialności i ciekawość – kształtują sposób, w jaki współpracujemy z klientami z branży fintech i bankowości. Naszym celem jest tworzenie oprogramowania, które działa sprawnie, jest przejrzyste i wspiera rzeczywiste rezultaty biznesowe.
Wniosek
Historia transakcji ma kluczowe znaczenie przy tworzeniu aplikacji bankowości mobilnej.
Pomaga użytkownikom zarządzać ich finansami, umożliwiając im szybkie wyszukiwanie informacji, pobieranie dokumentów, dołączanie paragonów i zgłaszanie problemów. Ponadto zmniejsza presję ze strony wsparcia bankowego i fintechowego, buduje zaufanie konsumentów i tworzy bardziej stabilne doświadczenie cyfrowe.
Bankowość mobilna odniesie korzyści z tych najważniejszych funkcji historii transakcji.
- Jasno skategoryzowane.
- Potężne możliwości wyszukiwania i filtrowania.
- Transparentne statusy oczekujące i opublikowane.
- Bezpieczny eksport.
- Zarządzanie paragonami.
- Kierowany proces rozstrzygania sporów.
- Wysoka wydajność w przypadku długich historii.
- Przemyślane bezpieczeństwo i prywatność.
Jeśli tworzysz produkt bankowy, taki jak portfel, aplikację płatniczą lub platformę fintech, nie powinieneś traktować historii transakcji jako mało istotnej funkcji. Jest to jeden z najważniejszych obszarów, w którym użytkownik ocenia, czy aplikacja jest godna zaufania.
W Appricotsoft współpracujemy z założycielami firm i organizacjami finansowymi, aby przekształcić złożone procesy bankowe w proste i korzystne rozwiązania mobilne. Niezależnie od tego, czy potrzebujesz spersonalizowanej aplikacji mobilnej, integracji usług bramki płatniczej, integracji bankowości stacjonarnej, czy też kompleksowego zespołu dostarczającego produkty, który wesprze Twoją firmę, pomożemy Ci stworzyć aplikację bankowości mobilnej, w którą użytkownicy uwierzą.
