10 Criteria to Consider When Choosing a Queue Management System

A queue management system is an operational tool that organises customer flow at branches and service points. Chosen well, it turns waiting times into something you can measure; chosen badly, it becomes extra work for your staff. The ten criteria below summarise the questions worth asking before you decide.

Start with your own criteria

Reading the list from top to bottom as an equally weighted checklist is misleading. A single branch with five counters and a multi-branch operation with forty counters do not share the same problems. Answer three questions before you decide: which measure do you want to improve today, who will report on it, and what result will you look at to call the system a success? Without those answers, criteria lists alone will not let you compare options.

1. The ticketing experience (kiosk)

This is where customers first meet the process. Touchscreen responsiveness, how many steps it takes to select a service, and whether text is large enough to read all matter. Can a ticket be issued with a single tap on one screen, or does the customer navigate three menus? The kiosk hardware itself is a separate assessment; we collected what to look at when choosing kiosk hardware in a separate article.

Touch technology is a decision point in itself: capacitive (PCAP) screens respond quickly and crisply to a bare finger but cannot be used with gloves, while resistive screens work with gloves and a stylus at the cost of image clarity. In busy or dusty environments, surface durability and how easily the glass can be cleaned deserve their own question. Without protection against accidental double taps, phantom tickets accumulate in the queue and distort your reports.

2. Screen and announcement management

Screens in the waiting area should show the queue number, which counter to approach and how many people are ahead. Adjustable announcement volume and support for multiple languages matter in mixed-customer environments.

These screens stay on all day, and consumer televisions are not built for that duty cycle: static images can burn in and failures arrive early, which is why commercial-grade displays deserve separate evaluation. On audio announcements, the queue number and the unit name must be pronounced correctly; if synthetic speech is used, it should be configurable whether numbers are read digit by digit or as a whole.

3. Queue logic

Not everyone joins the same queue. Can priority customers (disabled, elderly, by appointment), different service groups and counter competencies each be defined separately? If the rules are not configurable, operations will start working around the system within weeks.

The distribution rule matters just as much. Feeding counters in strict rotation looks fair, but queues swell whenever service times differ. Load-aware distribution depends on measuring real service times accurately. You should also define upfront how competent counters overflow into another queue when one queue runs empty, and how an appointment customer affects the walk-in flow.

4. Reporting and measurement

The answer to "did it work?" lives in the data. Can you report average wait time, average service time, abandonment rate and per-counter load? Being able to export the report makes management reviews much easier. How to read these metrics, and the limits of measuring abandonment, are covered in detail in our article on measuring waiting time.

Agree on definitions before reading any report: waiting time is the interval between issuing the ticket and calling it, while service time is the interval between the call and closing the transaction. Reports that blur the two mislead. Abandonment rate is the most commonly misread metric; the system can only see customers who were called but did not appear, and measuring those who left without ever being called requires separate counting. So look at the distribution rather than the average: a long queue at peak hour disappears inside the daily mean.

5. Integration capability

A queue system never runs alone. If you need to exchange data with HR, ERP, CRM or contact-centre systems, does the vendor have ready-made integrations, or is every integration custom development? This directly affects total cost.

The existence of an integration is not enough; ask about its maturity. Is the API documented and versioned, which operations does it expose, and does it publish events or require continuous polling? If staff sign-in cannot use your corporate directory (LDAP or Active Directory), you gain a second user-management system to maintain.

6. Multi-branch structure

If you operate more than one location, you need to see queue data from every branch in a single panel. Without central reporting you end up collecting reports branch by branch.

Central reporting and central management are different capabilities: seeing the report is one thing, changing which screen, user and queue rule applies in which branch from a single place is another. The second critical scenario is how a branch behaves when the link to head office drops — can it keep issuing and calling tickets locally, or does the branch stop entirely?

7. Installation and network requirements

Installation must fit your existing network. Cloud-based or on-premise? If the internet drops, does the system keep running, or does queueing stop completely?

The first question behind that is where the queue data lives. If it lives only in the cloud, a lost internet connection makes the branch inoperable; architectures that keep working on a local device and synchronise once the link returns reduce that risk. Beyond that, work out long-distance screen runs, uninterruptible power for kiosks and screens, network cabling and an IP plan in advance — these are added late and they inflate the budget.

8. Data responsibility

The system processes customer data. What is collected, where it is stored and how long it is retained should all be explicit. Ask your vendor for this in writing — a verbal assurance is not enough.

A ticket number may look anonymous on its own, but where customers are called by name — at outpatient clinics and registration desks, for example — personal data is processed. If a survey module is involved, free-text answers may contain special-category data. Ask your vendor in writing for the categories of data processed, the retention period, the deletion method and the country where servers are located; these points belong in the contract or in a data processing agreement.

9. Service and support

When a queue system fails, the service point cannot operate. Is the service response time, spare-parts availability and remote support access defined in the contract?

The escalation chain for a failure should be known in advance: is remote intervention possible, under what conditions does an on-site visit apply, who holds critical spare parts, and has the vendor published how long each software version will be supported? If these points are not written down, every failure turns into a negotiation and downtime gets longer.

10. Total cost of ownership

The licence fee is not the only cost. Once you add hardware, installation, training, annual maintenance and the per-counter or per-kiosk cost of future expansion, the real picture emerges. One-off purchase or subscription?

The licensing model interacts directly with scale: is it priced per counter, per branch or per user? A flat per-branch model pays off as you add counters, while a per-counter model can come out cheaper at a site with few counters. Consumables, display lifetime and spare parts also belong in the picture — and they rarely appear in the first quotation.

15 questions to ask your supplier

• Which touch technology do the kiosk screens use, and does it work with gloves?
• If the internet drops, does queueing continue?
• Is the API documented and versioned, and does it publish events or require polling?
• Can staff sign in with your corporate directory (LDAP/Active Directory)?
• Can priority rules and counter competencies be changed from the screen?
• How is abandonment rate calculated, and on what data?
• Can reports be exported as raw data?
• What does a branch do when the link to head office drops?
• What is the software support lifetime and update policy?
• Are critical spare parts held in stock, and what is the lead time?
• What data is processed, where is it stored, and how long is it kept?
• Is a data processing agreement and a deletion method provided?
• What is the licence priced per, and what does adding a counter cost?
• What consumables and maintenance items are involved?
• How are pilot installation and return conditions defined for a single branch?

Pilot: write the acceptance criteria first

A pilot at a single branch is the cheapest insurance for your decision — provided the criteria are written down first. Settle three things before the pilot starts: which metrics will be measured, which threshold counts as success, and who decides whether to roll out once it ends.

Example measures: average waiting time, abandonment rate, transactions per counter and average service time per ticket. The pilot period should cover a normal week and a peak period such as month end, not a single busy day; otherwise the system only looks good on quiet days.

Start the pilot by measuring the current situation. Without reference data you cannot prove an improvement, and the review at the end rests on impressions rather than evidence. Accept upfront that staff may work around the system in the first days after installation — which is why you should measure usage rate as well.

Define in the contract what happens if the pilot fails: return of hardware, handover of data and the conditions for reverting to your previous flow. That clause may not suit the vendor, but it is the most realistic protection the project has.

What must be in writing before you sign

Choosing is a technical exercise; the contract is what protects the outcome. The following points need a written counterpart in the quotation and the contract:

• Scope: how many counters, kiosks and screens, and which licence edition
• Integration scope, and what is explicitly out of scope
• Delivery and go-live schedule
• Training scope
• Warranty and maintenance scope
• Data processing, retention and deletion commitments
• Conditions for rolling out after the pilot

Verbal information does not outweigh a written quotation. Replacing a vendor is the most expensive scenario of all, so asking a few extra questions at the start is far cheaper.

Three common mistakes

• Looking only at hardware. Software flexibility matters more than hardware quality.
• Leaving reporting until later. Define your measurement requirements upfront.
• Skipping the pilot. Rolling out to every location without a measured trial at one branch is a risk.

Frequently Asked Questions

Is a kiosk essential, or does the system work without one?

A kiosk is not mandatory; a ticket can also be issued by staff at the counter. A kiosk lets customers handle ticketing themselves and reduces the load at the counter during busy periods. Without a kiosk there is also no timestamp for the moment a ticket was issued, which weakens waiting-time measurement.

From how many branches does central management become necessary?

There is no fixed number; what matters is the number of branches together with whether branches will change their own rules. In a single branch, central management is usually unnecessary. Across multiple branches you need to manage branches, users and devices from one place and to see queue data in a consolidated view.

Does queueing continue if the internet drops?

That depends on the deployment architecture and belongs in the contract. If queue data is held only in the cloud, losing the connection makes the branch inoperable. Architectures that keep working on a local device and synchronise once the link returns keep the interruption invisible to customers.

Can reporting be added later?

Reporting can be added later, but what is missing is the historical data. If measurement requirements are not defined upfront, the system's behaviour in its first months is not recorded and cannot be compared against. Which metrics will be kept, and under which definition, should therefore be settled before installation.

Conclusion

Weight the criteria against your own operation: a single branch with five counters and a multi-branch structure with forty counters do not have the same needs. The right system reduces your staff's workload rather than adding to it.

To see which product matches your requirement, read our product selection guide, or explore our solutions for sector-specific setups.