Frequently asked questions

No. Visitors take a token at a kiosk, scan a QR code or open a link on their own phone, or get one at the counter. The phone page runs in the browser, so there is nothing to install.

On their phone, visitors see their token, how many people are ahead and an estimated wait in minutes, and they can cancel if their plans change. See the visitor journey.

Devices you choose. manageQ runs in Chrome or Edge, so there is no special hardware:

• Kiosk: any touch PC or tablet, plus a receipt printer if you want printed tickets (printing is silent, with a QR code on the ticket).
• Display: any TV or monitor with a small PC.
• Counters: any PC, laptop or tablet with a browser.
• Visitors: their own phones.

A launcher for Windows or Linux opens a kiosk or display in full screen, and can start it automatically when the PC starts. The server runs in the cloud or on your premises.

Customer screens (kiosk, phone page, ticket status page and feedback kiosk) and voice announcements work in 6 languages: English, Hindi, Telugu, Tamil, Arabic (right to left) and Russian. Each organisation chooses which of them to offer, and a display can show its labels in one language or two.

• Announcements use the voices installed on the display PC, so Hindi, Telugu or Tamil voices must be added in the operating system first.
• Your admins translate their own texts, such as service names, form labels and instructions.
• The admin console is in English, and the built-in assistant answers in English.

Either. It is the same application in both cases:

• Cloud: a Microsoft Azure reference set-up, served over HTTPS only (TLS 1.2 or newer), with platform secrets kept in Azure Key Vault.
• On-premises or private cloud: Docker, or a classic install on a Windows or Linux server, on your network and in your country.

Both use PostgreSQL 13 or newer. Upgrades are additive and applied when the server starts, with a documented way back. Read about security and deployment.

Yes. Bookings can reach manageQ in four ways:

• A scheduled pull from your system's HTTPS API (GET or POST; a key in a header, a bearer token or a user name and password), every 5–1440 min, for today plus 1 to 14 days ahead.
• A push from your system of up to 1,000 bookings per call, with a key for each source.
• A CSV or Excel import (up to 5 MB and 5,000 rows), with a preview before anything is saved.
• Staff entry, for bookings taken by phone.

manageQ can also send signed status updates back (checked in, served, no-show, cancelled, expired, transferred), retried automatically and with no names or contact details in them. See the integration options.

No. Bookings stay in your own appointment system, or staff enter them for phone bookings. manageQ brings them in and handles the visit itself.

On the day, visitors check in at the kiosk ("I have an appointment"), on their phone with the branch's QR code, or at the counter, using their booking reference and, when the source asks for it, a check such as the last 4 digits of their mobile number. Visitors who arrive on time are placed by their slot time; later arrivals join the queue like walk-ins, or are refused if the location's rules say so.

Yes. One installation can serve many organisations, kept apart on every request: an organisation's admins see only their own locations and data.

• Each organisation can have any number of locations, each with its own time zone, working hours, holidays and queue rules.
• Staff work only at the locations they are assigned to.
• Token numbers restart at 001 every day, per location and prefix.
• The Executive dashboard compares locations, and every number opens the tokens behind it.

Every token belongs to its location's business day. Tokens still open when the day ends are closed automatically, with no staff action:

• Waiting and on-hold tokens become Expired.
• Called tokens that were never started, and missed tokens, become No-show.
• A token still being served is completed, with its service time capped so it does not distort the averages.

Closing runs at the location's midnight, or after closing time if you prefer, and it catches up after a restart, so yesterday's tokens never block a counter. Visitor details are deleted as for a served token, and reports show Expired as its own status.

With limits you set for each kiosk and eQueue link, plus an automatic guard:

• Daily cap: 1–9999 tokens a day, with a warning on the dashboard from 80 % and an alert to admins when the cap is reached. Counter staff can still issue tokens.
• Open tokens per mobile number: 1–10, counted across the whole location (kiosks, eQueue links and counters together). Once a token is served, the visitor can take another.
• Kiosk protection: a walk-in kiosk that sends far more requests than a person could, such as a script using a copied link, is paused at once and the admins are alerted. They review what happened and re-enable it, usually with a new link.

Appointment check-ins are exempt from the limits unless a location changes that rule.