Hello!
Below is the technical specification created with GPT.
Please indicate in your application a similar solution that you have already done. There is no need to create from scratch.
1) Goal
Create a simple electronic queue system for an offline store:
• the client selects a department (3–4 buttons) on the tablet at the entrance,
• receives a number,
• managers mark who is working today,
• the system distributes the queue among the working managers in the selected department,
• the manager clicks "Next" and receives the next client.
⸻
2) User roles
1. Client (only department selection screen + number display)
2. Manager (sees their queue and calls the next one)
3. Administrator (creates departments, adds managers, assigns managers to departments)
⸻
3) Mandatory functions
3.1 Client screen (kiosk on the tablet)
• Main screen: 3–4 large department buttons (for example: Sales / Issuance / Service / Returns).
• After clicking on the department:
• the ticket number is displayed (example: A-015 or 015),
• text “Please wait for the manager to call you.”
• Auto-return to the main screen after 10–15 seconds.
• No personal data is entered by the client.
3.2 Queues by departments
• Each department has its own queue.
• Numbering:
• either common (001, 002, 003…),
• or by departments (A001 for Sales, B001 for Service, etc.).
• The queue must be saved when the application is closed/restarted.
3.3 Managers and “on duty” status
• The application must have a “Manager” area.
• The manager selects themselves from the list and activates the status:
• “On duty / Accepting clients”
• “Off duty”
• The manager is assigned to a specific department (or can switch departments if the admin allows).
3.4 Queue distribution among department managers
Requirement: the system must “pass” clients between the working managers.
Distribution logic (simple and clear):
• If 1 manager is working in the department → all clients go to them.
• If 2+ managers are working → Round-robin distribution:
• the next ticket is assigned to the manager who is next in line (1 → 2 → 3 → 1 → 2…).
• If the manager turns off “On duty” → new clients are not assigned to them.
• If the manager turns back on → they join the round-robin from that moment.
3.5 Manager screen
The manager should see:
• “Next client” (button)
• the current called number (for example A015)
• a list of the next 3–5 numbers (optional, but desirable)
• the number of clients waiting in their department
Buttons:
• Next
• Complete (optional, can be combined with “Next”)
• Skip (if the client is not present) — the ticket goes to the end of the queue or is marked as skipped (in MVP it can simply go “to the end”).
3.6 Admin settings (minimum)
The application must have an admin panel (can be hidden, via PIN code):
• create/rename departments (3–4)
• add managers
• assign managers to departments
• reset the queue (at the beginning of the day)
⸻
4) Not included in MVP (to avoid complications)
• printing tickets
• display/television
• SMS
• integration with 1C/website
• waiting time analytics (can be done later)
⸻
5) Platform
Preferred: Android tablet (as a kiosk).
Implementation option:
• 1 application, which has “Client” and “Manager/Admin” modes
• or web application: tablet at the entrance = client interface, phones/PCs of managers = operator interface
⸻
6) Acceptance criteria (simple and verifiable)
1. Client selects a department → receives a number → the number appears in the department queue.
2. Manager turns on “On duty” → receives clients in order (round-robin).
3. If the manager turns off “On duty” → the system stops assigning clients to them.
4. Manager clicks “Next” → sees the next number, the queue moves.
5. After restarting the application, the queue is not reset.
6. Admin can manually reset the queues.
⸻
