Wyszukiwarka w aplikacji firmowej: jak znaleźć sprawę mimo niepełnych danych

Klient dzwoni w sprawie zamówienia. Nie ma numeru, pamięta tylko nazwę firmy i przybliżoną datę. Pracownik próbuje wyszukać sprawę, ale system wymaga dokładnego identyfikatora. Po kilku minutach znajduje ją w osobnym arkuszu, pod nazwą zapisaną nieco inaczej. Aplikacja przechowuje właściwe dane, lecz nie pomaga ich odnaleźć w sposób, którego wymaga rozmowa.

Wyszukiwarka w aplikacji firmowej powinna zaczynać się od takich sytuacji. Trzeba ustalić, czego ludzie szukają, jakie informacje znają na początku i po czym rozpoznają właściwy wynik. Dopiero potem warto wybrać sposób dopasowania, filtry oraz widok listy.

Przykłady opisują fikcyjny system obsługi zamówień i zgłoszeń. Inaczej będzie wyglądało wyszukiwanie urządzenia, dokumentu czy osoby. Zasady dostępu, sposób aktualizacji danych i oczekiwania dotyczące wyniku należy ustalić dla konkretnego procesu.

Zapytaj, co pracownik zna przed wyszukaniem

Poproście kilka osób o pokazanie ostatniej sytuacji, w której musiały odnaleźć sprawę. Czy znały numer? Czy miały adres e-mail, nazwę firmy, fragment opisu albo datę rozmowy? Zapiszcie kolejność poszukiwań oraz informacje, które pozwoliły potwierdzić wynik. To ważniejsze niż lista wszystkich pól zapisanych w bazie.

W fikcyjnym panelu pracownik może znać tylko początek nazwy klienta i miasto dostawy. System powinien umożliwić zawężenie listy bez ujawniania cudzych spraw. Jednocześnie wynik musi zawierać dość informacji, by rozróżnić dwa podobne rekordy. Samo wyświetlenie identycznych nazw firm nie wystarczy do podjęcia decyzji.

Zapytajcie także o zadania administracyjne. Kierownik może szukać wszystkich spraw bez przypisanego właściciela, a pracownik serwisu konkretnego urządzenia po numerze widocznym na etykiecie. To różne potrzeby, choć obie kończą się listą wyników. W dashboardzie operacyjnym opisujemy przejście od zbiorczej liczby do spraw wymagających działania.

Warto uwzględnić potoczne nazwy i skróty używane w firmie. Pracownik może mówić o „zwrocie”, podczas gdy system przechowuje status „reklamacja w ocenie”. Zanim dodacie synonimy, uzgodnijcie ich znaczenie z właścicielem procesu. Nie każde podobne słowo oznacza tę samą czynność.

Przy zbieraniu przykładów zapytajcie również, w którym momencie pracownik rezygnuje z wyszukiwania. Może przenosi się do innego systemu albo prosi koleżankę o numer sprawy. Takie obejście pokazuje koszt brakującej funkcji, nawet gdy nikt nie zgłasza błędu technicznego.

Wybierz pola i pokaż, czego dotyczy wynik

Wyszukiwanie może korzystać z numeru sprawy, nazwy klienta, adresu lub opisu. Nie oznacza to, że każda osoba powinna przeszukiwać wszystkie pola. Informacja wrażliwa może wymagać ograniczonego dostępu, a niektóre wartości są zbyt niejednoznaczne, by samodzielnie wskazać właściwy rekord.

Zaprojektujcie wynik tak, aby użytkownik mógł rozpoznać sprawę przed jej otwarciem. Przy zamówieniu pomocne mogą być numer, nazwa klienta, data i status, jeśli są dostępne dla danej roli. Nie umieszczajcie pełnej treści dokumentu tylko dlatego, że pojawiła się w dopasowaniu. Zakres listy musi uwzględniać tę samą kontrolę dostępu co szczegóły.

Warto odróżnić wynik dokładny od podobnego, kiedy interfejs pokazuje oba rodzaje dopasowania. Jeśli ktoś wpisze numer sprawy, powinien móc rozpoznać, czy system znalazł identyczny numer, czy jedynie zbliżoną wartość. Decyzja o otwarciu rekordu należy do osoby uprawnionej; wyszukiwarka nie powinna po cichu wybierać pierwszego wyniku jako prawidłowego.

Dla danych pobieranych z kilku systemów ustalcie, które źródło odpowiada za nazwę, status i identyfikator. Gdy rekordy nie są jeszcze uzgodnione, lista wyników powinna wskazać ich pochodzenie lub przekazać rozbieżność do wyjaśnienia. Pomocny jest artykuł o źródłach danych w integracji.

Literówka i odmiana to osobne problemy

Pracownik może pomylić jedną literę w nazwie, wpisać fragment słowa albo użyć innej formy gramatycznej. System może potrzebować różnych metod dopasowania dla każdego przypadku. Nie ma podstaw, by obiecać, że dowolna wyszukiwarka automatycznie poradzi sobie z polską odmianą i wszystkimi nazwami własnymi. Trzeba sprawdzić konkretną konfigurację na przykładach.

Dokumentacja PostgreSQL opisuje wyszukiwanie pełnotekstowe oraz osobny mechanizm porównywania podobieństwa tekstu oparty na fragmentach znaków. To możliwości konkretnej bazy, a nie gotowa recepta na każdą wyszukiwarkę. Przy wyborze rozwiązania trzeba sprawdzić język, rodzaj danych, wydajność i sposób obsługi uprawnień w danym systemie.

Dopasowanie podobnych nazw może zwrócić więcej wyników niż oczekiwano. Dlatego warto pokazać kontekst i pozwolić użytkownikowi zawęzić listę. Zbyt agresywna reguła może z kolei połączyć niepowiązane rekordy albo ukryć dokładny wynik. Test powinien zawierać również przypadki, w których podobne zapytanie nie powinno prowadzić do tej samej sprawy.

Numery i nazwy wymagają często innych zasad. W numerze zamówienia pojedyncza cyfra może wskazywać inny rekord, podczas gdy brak polskiego znaku w nazwie firmy może być zwykłym sposobem wpisania tekstu. Dla każdego pola ustalcie oczekiwane zachowanie oraz sposób pokazania niepewnego dopasowania.

Filtry powinny pomagać, a nie ukrywać wyniki

Filtry mogą zawężać listę do oddziału, statusu, okresu lub rodzaju sprawy. Użytkownik powinien widzieć, które warunki są aktywne, oraz móc je łatwo usunąć. W przeciwnym razie brak wyniku może oznaczać jedynie zapomniany filtr z poprzedniej pracy. Komunikat powinien pomagać odróżnić tę sytuację od rzeczywistego braku dopasowania.

Uzgodnijcie, czy filtry pozostają po powrocie do listy oraz co dzieje się po przełączeniu organizacji lub roli. Zachowanie, które jest wygodne w jednym procesie, może być mylące w innym. Ważne, by użytkownik wiedział, jaki zakres danych właśnie ogląda i czy ustawienia pochodzą z jego poprzedniej sesji.

Jeśli lista ma wiele stron, sposób sortowania powinien być czytelny i spójny. Przy dużej liczbie wyników użytkownik potrzebuje wiedzieć, dlaczego konkretna sprawa pojawiła się wysoko i jak zmienić kolejność. Nie zawsze trzeba ujawniać techniczną formułę oceny; często wystarczy zrozumiały wybór, na przykład według daty lub trafności.

W aplikacji dla kilku oddziałów filtr lokalizacji nie powinien zastępować uprawnienia. Możliwość wyboru oddziału na ekranie jest wygodą, ale system nadal musi sprawdzić, które dane osoba może zobaczyć. O rozdzieleniu wspólnych zasad i lokalnych potrzeb piszemy przy systemie dla wielu oddziałów.

Brak wyników to początek następnego kroku

Zamiast samego „brak wyników” pokażcie, jakie warunki zostały zastosowane i co użytkownik może zrobić. Może usunąć filtr, sprawdzić numer albo użyć innego pola. Jeśli system nie znalazł niczego, bo dane nie zostały jeszcze zsynchronizowane, nie powinien udawać, że sprawa na pewno nie istnieje.

Przy problemie technicznym rozróżnijcie niedostępność wyszukiwania od pustego wyniku. Pracownik powinien wiedzieć, czy może zmienić zapytanie, czy musi poczekać lub skontaktować się z pomocą. Komunikat o błędzie nie powinien ujawniać szczegółów technicznych, które nie pomagają odbiorcy wykonać zadania.

Jeśli wyniki są aktualizowane z opóźnieniem, ustalcie sposób informowania o stanie danych oraz procedurę dla spraw, które muszą być odnalezione od razu. Nie każda aplikacja ma te same możliwości odświeżania. Przed obietnicą konkretnego czasu sprawdźcie architekturę, źródła oraz scenariusze błędów.

Dla systemu wykorzystującego dokumenty i asystenta AI istotne są dodatkowo uprawnienia do źródeł użytych w odpowiedzi. Ten temat omawiamy osobno w artykule o dostępie do dokumentów w systemie RAG. Wyszukiwanie rekordu i odpowiedź wygenerowana na podstawie dokumentów są różnymi zadaniami, choć oba wymagają kontroli dostępu.

Dane muszą trafić do wyszukiwarki

Przed wyborem mechanizmu ustalcie, skąd pochodzą rekordy oraz jak zmiana w systemie źródłowym staje się widoczna w wynikach. W niektórych rozwiązaniach wyszukiwanie odczytuje dane bezpośrednio, w innych korzysta z osobnego indeksu. Ten drugi wariant wymaga sprawdzania, czy nowe i poprawione rekordy rzeczywiście do niego dotarły.

Przy usunięciu rekordu lub odebraniu dostępu potrzebna jest również decyzja, jak szybko zmiana ma zostać uwzględniona. Nie wystarczy założyć, że lista wyników sama odświeży wszystkie informacje. Oprócz aktualizacji danych trzeba sprawdzać uprawnienia podczas udostępniania wyniku i szczegółów.

Jeśli źródło chwilowo nie odpowiada, użytkownik powinien wiedzieć, jakiego zakresu dotyczy ograniczenie. System może dysponować starszą listą, ale projekt musi określić, czy wolno ją pokazać i jak oznaczyć jej aktualność. W sprawie wymagającej natychmiastowej decyzji wiek danych może mieć większe znaczenie niż wygoda szybkiego wyniku.

Po odnalezieniu sprawy pracownik może potrzebować wyjaśnić, dlaczego jej status się zmienił. O projektowaniu takiego widoku piszemy w artykule o historii zmian i decyzji w aplikacji.

Sprawdź ranking na różnych przykładach

Kolejność wyników może uwzględniać zgodność tekstu, datę lub inne właściwości rekordu. Zanim wybierzecie regułę, zapytajcie, jaki rezultat powinien znaleźć się na początku dla najczęstszych zadań. Osoba wpisująca pełny numer prawdopodobnie oczekuje czegoś innego niż osoba przeglądająca wszystkie otwarte sprawy klienta.

Przygotujcie także zapytania, dla których istnieje kilka poprawnych odpowiedzi. Jeśli dwa oddziały tego samego klienta mają podobne nazwy, interfejs powinien pomóc je odróżnić, a ranking nie powinien zastępować decyzji pracownika. Sprawdźcie również, co dzieje się po zmianie nazwy lub połączeniu rekordów w systemie źródłowym.

Zespół może oceniać trafność na zestawie przykładów, ale powinien zapisać jego zakres. Kilkanaście zapytań z jednego działu nie opisuje całej pracy firmy. Po uruchomieniu warto przeglądać anonimowe lub odpowiednio ograniczone sygnały o problemach i dodawać nowe przypadki do testów, zgodnie z zasadami ochrony danych.

Uwzględnij pracę na małym ekranie

Pracownik w terenie może wpisywać tylko część numeru na telefonie. Sprawdźcie, czy pole wyszukiwania jest widoczne, a wynik daje się rozpoznać bez poziomego przewijania. Jeżeli filtry ukrywają się w osobnym panelu, użytkownik nadal powinien widzieć, że są aktywne.

Dostępność dotyczy również obsługi klawiaturą i czytelnych nazw elementów. Otwieranie podpowiedzi, wybór wyniku oraz zamknięcie listy powinny być sprawdzane z użyciem technologii właściwych dla użytkowników. Nie wystarczy, że interfejs dobrze wygląda na jednym urządzeniu projektanta.

Testuj zapytania, które naprawdę padają

Zbierzcie przykłady wyszukiwań od pracowników, usuwając z nich niepotrzebne dane osobowe. Przy każdym zapiszcie oczekiwany rezultat: dokładny rekord, kilka możliwych spraw albo informację, że wynik nie powinien być dostępny. Dodajcie literówki, skróty, podobne nazwy i aktywne filtry.

Przetestujcie również dwa konta o różnych uprawnieniach. To samo zapytanie nie musi zwrócić identycznej listy, jeżeli zakres dostępu jest inny. Sprawdźcie liczbę wyników, podpowiedzi oraz możliwość otwarcia szczegółów. Komunikat nie powinien ujawniać istnienia niedostępnej sprawy tylko dlatego, że pasuje ona do wpisanego numeru.

Przy próbie z użytkownikami obserwujcie, czy potrafią rozpoznać właściwy wynik i wrócić do listy bez utraty potrzebnego kontekstu. W artykule o testowaniu prototypu z pracownikami opisujemy przygotowanie takich zadań. Następnie zapiszcie kryteria w planie odbioru aplikacji.

Jeśli chcesz poprawić znajdowanie spraw w firmie, opisz w briefie przykładowe zapytanie, oczekiwany wynik i miejsce, w którym dziś pojawia się problem. Możemy omówić zakres oprogramowania na zamówienie oraz sposób testowania. Napisz do Archifutura, korzystając z fikcyjnych danych zamiast informacji klientów.