Cześć!
Poniżej znajduje się specyfikacja przygotowana z GPT.
Proszę w zgłoszeniu od razu podać podobne rozwiązanie, które już zrealizowaliście. Nie trzeba robić od zera.
1) Cel
Stworzenie prostego systemu elektronicznej kolejki dla sklepu stacjonarnego:
• klient przy wejściu wybiera dział (3–4 przyciski) na tablecie,
• otrzymuje numer,
• menedżerowie zaznaczają, kto dzisiaj pracuje,
• system rozdziela kolejkę pomiędzy pracujących menedżerów w wybranym dziale,
• menedżer naciska „Następny” i otrzymuje następnego klienta.
⸻
2) Role użytkowników
1. Klient (tylko ekran wyboru działu + wyświetlanie numeru)
2. Menedżer (widzi swoją kolejkę i wzywa następnego)
3. Administrator (tworzy działy, dodaje menedżerów, przypisuje menedżerów do działów)
⸻
3) Obowiązkowe funkcje
3.1 Ekran klienta (kiosk na tablecie)
• Główny ekran: 3–4 duże przyciski działów (np.: Sprzedaż / Wydanie / Serwis / Zwrot).
• Po naciśnięciu na dział:
• wyświetlany jest numer biletu (przykład: A-015 lub 015),
• tekst „Proszę czekać na wezwanie menedżera”.
• Automatyczny powrót na główny ekran po 10–15 sekundach.
• Żadne dane osobowe klient nie wprowadza.
3.2 Kolejki według działów
• Każdy dział ma swoją kolejkę.
• Numeracja:
• albo ogólna (001, 002, 003…),
• albo według działów (A001 dla Sprzedaży, B001 dla Serwisu itd.).
• Kolejka powinna być zachowana przy zamknięciu/ponownym uruchomieniu aplikacji.
3.3 Menedżerowie i status „na zmianie”
• W aplikacji powinna być strefa „Menedżer”.
• Menedżer wybiera siebie z listy i włącza status:
• „W pracy / Przyjmuję klientów”
• „Nie w pracy”
• Menedżer jest przypisany do konkretnego działu (lub może przełączać dział, jeśli administrator pozwoli).
3.4 Rozdzielanie kolejki między menedżerami działu
Wymaganie: system powinien „przekazywać” klientów między pracującymi menedżerami.
Logika rozdzielania (prosta i zrozumiała):
• Jeśli w dziale pracuje 1 menedżer → wszyscy klienci do niego.
• Jeśli pracuje 2+ menedżerów → rozdzielanie Round-robin (na zmianę):
• następny bilet przypisywany jest menedżerowi, który jest następny w kolejce (1 → 2 → 3 → 1 → 2…).
• Jeśli menedżer wyłączył „W pracy” → nowi klienci nie są mu przypisywani.
• Jeśli menedżer znowu się włączy → włącza się w round-robin od tego momentu.
3.5 Ekran menedżera
Menedżer powinien widzieć:
• „Następny klient” (przycisk)
• aktualny wywołany numer (np. A015)
• listę następnych 3–5 numerów (opcjonalnie, ale pożądane)
• liczbę oczekujących w jego dziale
Przyciski:
• Następny
• Zakończ (opcjonalnie, można połączyć z „Następny”)
• Pomiń (jeśli klienta nie ma) — bilet trafia na koniec kolejki lub jest oznaczany jako pominięty (w MVP można po prostu „na koniec”).
3.6 Ustawienia admina (minimum)
W aplikacji powinna być administracja (może być ukryta, po kodzie PIN):
• utworzyć/zmienić nazwy działów (3–4)
• dodać menedżerów
• przypisać menedżerów do działów
• zresetować kolejkę (na początku dnia)
⸻
4) Nie wchodzi w skład MVP (aby nie komplikować)
• drukowanie biletów
• tablica/telewizor
• SMS
• integracja z 1C/stroną
• analiza czasu oczekiwania (można później)
⸻
5) Platforma
Preferowane: tablet z Androidem (jako kiosk).
Opcja realizacji:
• 1 aplikacja, w której jest tryb „Klient” i „Menedżer/Administrator”
• lub aplikacja webowa: tablet przy wejściu = interfejs klienta, telefony/PC menedżerów = interfejs operatora
⸻
6) Kryteria akceptacji (proste i weryfikowalne)
1. Klient wybiera dział → otrzymuje numer → numer pojawia się w kolejce działu.
2. Menedżer włącza „W pracy” → otrzymuje klientów w kolejności (round-robin).
3. Jeśli menedżer wyłączył „W pracy” → system przestaje mu przypisywać klientów.
4. Menedżer naciska „Następny” → widzi następny numer, kolejka się przesuwa.
5. Po ponownym uruchomieniu aplikacji kolejka nie jest zerowana.
6. Administrator może ręcznie zresetować kolejki.
⸻
