We only have one counter. Is an online queue still worth it?

The number of counters is not the point; how tightly customers are tied to the spot while waiting is. If customers always have to stand at the door and often leave because the wait is too long, then even with one counter, letting them take a number, wander nearby, and come back when their turn is close can clearly improve the experience and reduce walkaways. On the other hand, if there is hardly ever a wait, or waits are short, one ticket machine on site or even paper number slips may be enough. Record peak waiting conditions and how often customers leave for a while, then decide whether remote ticketing is worthwhile.

Can we use a LINE official account for ticketing and call notifications?

Yes, and for most local businesses in Taiwan, LINE is the notification channel customers resist least, since there is no extra app to download. A common setup is that customers tap a menu item in LINE to take a number, the system records which user it belongs to, and a push message goes out when their turn is near. Note that customers must add the account as a friend before they can receive push messages, so keep web ticketing and text messages as alternatives. Also understand in advance how push message volume is counted and billed: at peak times many reminders fire together, so consider notifying only at key moments rather than every time the line moves by one.

If we later want to add booking, do we have to rebuild the whole queue system?

Not necessarily; it comes down to the initial data design. If the queue system sets up service types, staff or counters, locations, and opening hours as independent settings, booking can later share those master records and simply add a "reserve a time slot in advance" flow. The worst case is hard-coding the numbering logic to a single location and a single counter, so every new scenario requires changing core code. If you already know booking may arrive within a year or two, tell the developer at the specification stage so both flows share the same customer records and check-in history, which is what lets a booked customer be slotted into the calling order at check-in.

Planning an Online Queue Ticketing System

Lunchtime on a weekend, the doorway is packed, the counter is taking payments while fielding “how many groups are ahead of us?”, and some customers give up and leave. That is the moment many businesses start evaluating an online queue and ticketing system. Whether it is a restaurant, a clinic, a repair counter, or a government service desk, the core problem is the same: waiting itself is hard to avoid, but what really sours the experience is that customers do not know how long they will wait and cannot step away.

What a queue and ticketing system solves is making the wait predictable, something you can leave, and free of missed numbers.

What follows covers how the system works, how walk-in and remote tickets coexist, notification options, missed-turn rules, how it differs from a booking system, and how to prepare for peak periods.

The basic components of a queue system

A complete queue and ticketing system usually includes these parts:

Ticketing: an on-site ticket machine, staff issuing numbers at the counter, or customers taking a number remotely on their phones.
Calling: the interface counter staff use to press “next,” which may be a tablet, a computer, or a physical button.
Display: the in-store number screen and voice announcements.
Notifications: reminders by text message, LINE (the dominant messaging app in Taiwan), or web push when a customer’s turn is close.
Admin back end: where service types, counters, and opening hours are set, and waiting and service records are reviewed.

A small business does not necessarily need every part. With one counter and customers waiting inside, ticketing and a number screen may be enough; when customers often need to wait elsewhere, remote ticketing and notifications become the core.

How walk-in numbers and remote tickets coexist

The hardest design problem in remote ticketing is that it shares one line with on-site ticketing. Handle it badly and walk-in customers feel someone cut in front of them, while remote customers feel they arrived and still had to wait.

There are three common ways to run them together:

One line, one numbering sequence: wherever the number was taken, people join the same line in the order they took it. It is the most intuitive and the fairest, but a remote customer may take a number from far away and find their turn already passed when they arrive.
Separate lines, interleaved calling: walk-in and remote tickets are numbered separately and called alternately at a configured ratio. This suits places with heavy remote volume that want to manage the sense of fairness on both sides, but the rules are harder to explain to customers.
Remote tickets limited by distance or time: remote ticketing opens only during business hours, or only when the on-site wait passes a certain length, so a wave of remote tickets cannot fill the line all at once.

Whichever you choose, the ticketing screen should clearly show “groups ahead of you” and “estimated wait,” and explain the rules. Customers will accept waiting; they will not accept not understanding.

Another thing to decide in advance is whether remote ticket holders must check in on arrival. If so, customers scan a code on site or tell the counter, and only then does the system mark them “arrived, ready to call.” If not, a number may be called when the customer has not even arrived. In most situations a check-in step is advisable, working together with the missed-turn rules below.

Notifications: when to remind, and through which channel

Notifications are where remote queuing earns its value, but they are also the easiest part to make too noisy or too late.

There should be at least two notification moments:

When the turn is close: for example, a reminder when only a few groups remain ahead, giving the customer time to walk back. How many groups ahead depends on your average service time and how far customers usually wander.
When the number is called: one more reminder at the moment of the actual call.

Each notification channel has trade-offs:

Live web updates: customers keep the page open to see progress, with no friend-adding or phone number needed, but they cannot see it once the phone locks.
LINE push messages: most customers already use it and delivery is reliable, provided they have added the official account as a friend; see the LINE Chatbot Development Guide.
Text messages: independent of any app with high delivery, suited to older customers or anyone who does not want to add a friend, but every message carries a sending cost.

A common combination in practice is live web updates as the main channel with LINE or text messages as backup, letting customers choose their reminder method when they take a number. When asking for a phone number or a friend add, explain what the data is for and use it only for this queue notification.

Missed-turn rules: exceptions the system must settle in advance

Missed turns are where queue systems most often trigger arguments on site. The rules should be set in advance, written on the ticketing screen, and enforced by the system, rather than left to counter staff to judge on the spot.

Use this decision table for missed-turn rules and pick according to your type of business:

Situation	Option	Suits
Not present when called	Hold for a few numbers, then expire automatically	Short service times, fast-moving line
Not present when called	Move to the end of the current line	Longer waits, wanting to keep the customer
Returns after missing the turn	Counter manually reinserts as the next number	Enough staff, modest customer volume
Remote ticket not checked in	Skip automatically when called, rejoin after check-in	Heavy remote ticket volume
Same person takes multiple tickets	Limit one active ticket per phone number	Concern about people hoarding numbers

At minimum the system should support: skip, hold, recall, cancel, and manual insertion with a recorded reason. Manual insertions must be logged, or there is no way to check what happened when a complaint comes in later.

Also consider the difference between “the service ends quickly once called” and “the customer has several things to handle once called.” When service times vary widely, wait estimates become very inaccurate. You can let the counter select a service type when calling so the system estimates by type, or simply split them into separate lines.

How a queue system differs from a booking system

The two are often confused, but they solve different problems:

A queue system handles customers who have already decided to come and want service now; its core is on-site order and live progress.
A booking system handles customers who reserved a time slot in advance; its core is slot capacity, rescheduling, and no-shows.

To decide which one you need, look at customer behavior. If most customers drop in on impulse or walk in while passing, a queue system fits better; if service takes a long time and staff or materials need preparing in advance, a booking system is more suitable. Slot design, no-show handling, and reminders for booking systems are covered fully in the Booking System Development Guide.

Many businesses end up needing both: booked customers have reserved slots and walk-ins queue on site. The key then is the rule for inserting booked customers into the calling order at check-in, for example giving priority to booked customers who check in within a window around their appointment time and moving latecomers into the regular line. That rule has to make sense to customers on both sides.

Peak load: the moment you need the system most is when it cannot fail

Queue system usage is highly concentrated. A weekday may be quiet, while a holiday, an event, or a launch day brings a flood of tickets and progress checks in a short time. That is exactly when the system can least afford a problem.

Before peak periods, confirm:

Ticketing has concurrency protection: when many people take numbers at once, no two people can get the same number and no numbers can be skipped.
Progress checks do not hit the database every time: when lots of customers keep refreshing the page, progress data should be cached or pushed as updates instead.
Notifications are queued for sending: when a large batch of reminders fires together, failed sends should be retried rather than lost.
There is an on-site fallback: if the network or system goes down, the counter needs paper numbers or an offline mode to take over, with a way to enter records once service is restored.
Load testing is done in advance: simulate peak traffic with realistic scenarios to find the bottlenecks. See the Traffic Spike and Load Testing Guide.

If you have several locations, also confirm that a peak at one location cannot drag down service at the others.

The requirements checklist to prepare first

Before talking with a developer, write down answers to these questions. The more specific the answers, the less likely the specification is to miss something:

What services do you offer? Do they need separate lines?
How many counters or staff are there? Will that number change at short notice?
Will remote ticketing be open? Under what conditions and during which hours?
Do remote ticket holders need to check in on arrival?
What are the missed-turn rules, and what text will appear on screen?
Which notification channels will you use, and how many groups ahead will the reminder go out?
Do booked customers need to be merged into the calling order?
Are there multiple locations? Should the back end show all of them together?
Which reports do you need, such as wait length by time of day, missed-turn rate, and volume served per counter?

For how to organize a requirements document, see How to Write Software Requirements.

Common mistakes

Ticketing without notifications: customers are still tied to the spot, and most of the value of remote ticketing is lost.
Leaving missed-turn rules to staff discretion: everyone handles it differently, a customer sees someone else reinserted while being told to take a new number, and the argument starts.
Hard-coding the estimated wait: service time shifts with the hour and staffing, so a fixed number soon becomes wrong and customers stop believing it.
No offline fallback: when the system drops, the floor descends into chaos.
Testing only on weekdays: running smoothly on a weekday does not mean it will hold up at peak.

Done well, a queue system makes customers feel “I know how long it will be, and I can go do something else first.” Done badly, it adds one more hassle on top of the wait.

If you are working out how remote tickets should coexist with the on-site line, how to build missed-turn rules into the system, or how to plan it alongside LINE or a booking system, tell NETVANA about your on-site situation. Software work is always quoted after a consultation: we first clarify your queue rules and peak scenarios, then propose a system scope and phasing. You can find what we offer in our software services overview.

Further reading: For services that need time slots reserved in advance, start with the Booking System Development Guide. To use LINE for ticketing and reminders, see the LINE Chatbot Development Guide. For testing ahead of peak periods, read the Traffic Spike and Load Testing Guide. If the counter also handles checkout, see the POS Retail System Development Guide. And to organize a specification without gaps, read How to Write Software Requirements.